Re: 2.6.22-rc1-mm1: evm BUG when reading sysfs file

[Joseph Fannin]

On Fri, May 25, 2007 at 10:28:22PM -0400, Reiner Sailer wrote:
> On Tue, 22 May 2007 03:25:48 -0400
> [EMAIL PROTECTED] (Joseph Fannin) wrote:
>

> > I've been getting this since 2.6.21-rc7-mm1:

> > [2.379310] BUG: unable to handle kernel paging request at virtual 
> > address 4400d340
> > [2.379491]  printing eip:
> > [2.379573] c021c978
> > [2.379656] *pdpt = 0353c001
> > [2.379739] *pde = 
> > [2.379824] Oops:  [#1]
> > [2.379906] PREEMPT SMP
> > [2.380059] Modules linked in: thermal processor dm_mod
> > [2.380288] CPU:0
> > [2.380289] EIP:0060:[]Not tainted VLI
> > [2.380291] EFLAGS: 00010297   (2.6.22-rc1-mm1 #2)
> > [2.380547] EIP is at vsnprintf+0x448/0x5d0
> > [2.380633] eax: 4400d340   ebx: c348f034   ecx: 4400d340   edx: fffe
> > [2.380721] esi: c03e0100   edi: 4400d340   ebp: c357ecc0   esp: c357ec68
> > [2.380810] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
> > [2.380898] Process udevtrigger (pid: 686, ti=c357e000 task=c1876df0 
> > task.ti=c357e000)
> > [2.380987] Stack: c348f014 0fec c03e1c60 c03e3cec c357eccc c0499b88 
> > c357ece0 c0282513
> > [2.381428]c348f014 0fec 3cb70fcb c348f034   
> >  
> > [2.381867] fffe c03e017c c357ed18 0034 c0494a20 
> > c357ece0 c021cb9f
> > [2.382305] Call Trace:
> > [2.382470]  [] sprintf+0x1f/0x30
> > [2.382594]  [] show_uevent+0xed/0x130
> > [2.382720]  [] dev_attr_show+0x23/0x30
> > [2.382843]  [] sysfs_read_file+0x97/0x140
> > [2.382968]  [] vfs_read+0xaf/0x180
> > [2.383096]  [] kernel_read+0x3a/0x50
> > [2.383221]  [] evm_calc_hash+0x11c/0x240
> > [2.383347]  [] evm_file_free+0xb9/0x330
> > [2.383470]  [] __fput+0xba/0x180
> > [2.383593]  [] fput+0x22/0x40
> > [2.383715]  [] filp_close+0x47/0x70
> > [2.383839]  [] sys_close+0x69/0xc0
> > [2.383965]  [] syscall_call+0x7/0xb
> > [2.384092]  [] 0xb7ebd0a7
> > [2.384212]  ===
> > [2.384295] INFO: lockdep is turned off.
> > [2.384379] Code: 21 fd ff ff c6 03 25 e9 19 fd ff ff 8d 4f 04 b8
> > 3b a2 3d c0 8b 55 e4 89 4d 08 8b 3f 81 ff ff 0f 00 00 0f 46 f8 89 f9
> > 89 c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 89 c6 8b 45 e0
> > f6 45
> > [2.386787] EIP: [] vsnprintf+0x448/0x5d0 SS:ESP
> > 0068:c357ec68

>
> Joseph,
>
> thank you for posting this problem. I cannot reconstruct it on my machine.
>
> Could you tell us which kernel configuration you used (drivers/char/tpm
> and security settings) ?
> Does it disappear when IMA is disabled in the kernel config?

I've found that disabling CONFIG_SYSFS_DEPRECATED makes the
BUG message go away; maybe that's what you're missing?

I've also attached my .config -- but it has lots of stuff turned
on, so it may be faster to try flipping CONFIG_SYSFS_DEPRECATED on a
slimmer config, if you'd like.

Disabling IMA doesn't change the message; it's still there.

Thanks!
--
Joseph Fannin
[EMAIL PROTECTED]

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

Re: [PATCH] x86: fix oprofile double free (was Re: Multiple free during oprofile unload)

[Andi Kleen]

> And, in this case we're in luck.  It's not released in any -stable tree
> yet (it's queued for the next release).  So there's plenty of time to
> fix it up before next -stable release.
> 
> Something like below should fix it.

I already got a similar patch, but not tested yet.

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

Re: [PATCH, RFT, v4] sata_mv: convert to new EH

[dean gaudet]

On Fri, 25 May 2007, Jeff Garzik wrote:

> Already uncovered and fixed a few bugs in v3.
> 
> Here's v4 of the sata_mv new-EH patch.

you asked for test results with 2.6.21.3 ... that seems to boot fine,
and i've tested reading from the disks only and it seems to be working
fine.  ditto for 2.6.22-rc3.

but 2.6.22-rc3 + your v4 patch fails... i'll send you the serial console
outputs offline.

-dean




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 v2.6.22-rc3

[Jan Engelhardt]

On May 25 2007 20:21, Linus Torvalds wrote:
>
>It's Friday evening, and the US is preparing for a long three-day weekend, 
>often considered the official start of summer here. 
>
>So what's a pasty white nerd to do?

Doing a commit like c420bc9f09a0926b708c3edb27eacba434a4f4ba on Makefile
line 5... reminds me strongly of [1][2]

[1] http://lkml.org/lkml/2006/5/25/138
[2] http://lkml.org/lkml/2006/5/25/152

>So stop worrying about those dangerous ultraviolet rays, and instead get 
>your Vitamin D in the form God (and the pharmaceutical industry) intended: 
>small easily swallowed pills. Beaches are overrated anyway, the sand gets 
>into the laptop fan and soon it won't work.

So use a fanless box :)




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: reg: modules make in Ubuntu

[Tej Parkash]

On 5/26/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:

On Sat, May 26, 2007 at 01:28:56AM -0400, Tej Parkash wrote:
> make[1]: Entering directory `/usr/src/linux-headers-2.6.20-15-generic'
>  CHK include/linux/version.h
>  CHK include/linux/utsrelease.h
> make[2]: *** No rule to make target `arch/i386/kernel/msr.c', needed
> by `arch/i386/kernel/msr.o'.  Stop.
> make[1]: *** [arch/i386/kernel] Error 2
> make[1]: Leaving directory `/usr/src/linux-headers-2.6.20-15-generic'
> make: *** [all] Error 2
>
> what the hack is this. no kernel version is having this file in this
> particular location as asked in error. then why this error is coming
> in this kernel version.
Looks like you are trying to build a kernel but have only headers
judging from the directoryname.

yaa u r correct
but i am wondering like how those file can be missed from the required
location. if they are so important to build the module.. even if it is
missed is there any other procedure to build the module
i am trying it on other kernel version.



Could you please prove a bit more context if you need additional help.
Like (but not limited to):
-> Actual commandline
-> Any own kbuild/Makefiles
-> .config

Sam


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

Re: [Bridge] [BUG] Dropping fragmented IP packets within VLAN frames on bridge

[Patrick McHardy]

Adam Osuchowski wrote:
> Stephen Hemminger wrote:
> 
>>It would be better to account for the tag in the length check.
>>Something like
>>  if (skb->protocol == htons(ETH_P_IP) &&
>>  skb->len > skb->dev->mtu - (IS_VLAN_IP(skb) ? VLAN_HLEN : 0) &&
>>  !skb_is_gso(skb))
>>  return ip_fragment ...
> 
> 
> It isn't good solution because one of IS_VLAN_IP() necessary condition is
> 
> skb->protocol == htons(ETH_P_8021Q)
> 
> which is, of course, mutually exclusive with
> 
> skb->protocol == htons(ETH_P_IP)
> 
> from br_nf_dev_queue_xmit(). IMHO, one should check length of ETH_P_IP
> and ETH_P_8021Q frames separately:
> 
> if (((skb->protocol == htons(ETH_P_IP) && skb->len > skb->dev->mtu) ||
> (IS_VLAN_IP(skb) && skb->len > skb->dev->mtu - VLAN_HLEN)) &&
>   !skb_is_gso(skb))
>   return ip_fragment ...


net/8021q ignores the VLAN header overhead, so we should probably do the
same here for consistency. Using IS_VLAN_IP (and IS_PPPOE_IP for current
-rc) looks fine, additionally we should probably also check for
skb->nfct != NULL to make sure that at least without connection tracking
the bridge doesn't perform fragmentation.

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

Re: SMBIOS 2.5 support?

[Andi Kleen]

Daniel Yeisley <[EMAIL PROTECTED]> writes:

> Does anyone know if the kernel has any issues running on a platform that
> provides SMBIOS v2.5?

Should not.

-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 1/7] ps3: Preallocate bootmem memory for the PS3 FLASH ROM storage driver

[Geert Uytterhoeven]

On Sat, 26 May 2007, Benjamin Herrenschmidt wrote:
> On Fri, 2007-05-25 at 10:36 +0200, [EMAIL PROTECTED] wrote:
> > -#if defined(CONFIG_FB_PS3) || defined(CONFIG_FB_PS3_MODULE)
> > +#if defined(CONFIG_FB_PS3) || defined(CONFIG_FB_PS3_MODULE) || \
> > +defined(CONFIG_PS3_FLASH_MODULE) ||
> > defined(CONFIG_PS3_FLASH_MODULE)
> 
> As I said multiple times, imho, #ifdef CONFIG_xxx_MODULE in the kernel
> is always a bug.
> 
> You should always be able to build the module out of tree afteward and
> use it on a kernel that didn't have the CONFIG_xxx_MODULE set imho.

I know.

Do you know another way to allocate an aligned chunk of 256 KiB of physically
contiguous memory, possibly a long time after boot up?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622  B-1935 Zaventem, Belgium
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 6/7] ps3: ROM Storage Driver

[Geert Uytterhoeven]

On Sat, 26 May 2007, Benjamin Herrenschmidt wrote:
> On Fri, 2007-05-25 at 13:24 +0200, Olaf Hering wrote:
> > On Fri, May 25, [EMAIL PROTECTED] wrote:
> > 
> > > +++ b/drivers/scsi/ps3rom.c
> > 
> > > + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
> > 
> > linux/highmem.h is not included to get the kmap_* prototypes.
> 
> Beside, I don't see the point of using kmap on ppc64...

So what should I use instead?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622  B-1935 Zaventem, Belgium
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 4/7] ps3: Storage Driver Probing

[Geert Uytterhoeven]

On Sat, 26 May 2007, Benjamin Herrenschmidt wrote:
> On Fri, 2007-05-25 at 18:18 +0200, Arnd Bergmann wrote:
> > > +static u64 ps3stor_wait_for_completion(u64 devid, u64 tag,
> > > +unsigned int timeout)
> > > +{
> > > + unsigned int retries = 0;
> > > + u64 res = -1, status;
> > > +
> > > + for (retries = 0; retries < timeout; retries++) {
> > > + res =
> > lv1_storage_check_async_status(NOTIFICATION_DEVID, tag,
> > > +  &status);
> > > + if (!res)
> > > + break;
> > > + set_current_state(TASK_INTERRUPTIBLE);
> > > + schedule_timeout(1);
> > > + }
> > 
> > Any reason not to use msleep(1) instead of the schedule_timeout? 
> 
> Both look equally ugly though... do you really have to poll ?

The special notification device (NOTIFICATION_DEVID = -1) is not in the
repository and AFAIK it doesn't have an interrupt attached to it.
Note that this is used during probing only.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622  B-1935 Zaventem, Belgium
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

software suspend doesn't work with 2.6.22-rc3

[Maximilian Engelhardt]

Hello,

When I try software suspend on my laptop it always returns to my running 
system after some time.
This is what's logged by the kernel:

swsusp: Basic memory bitmaps created
Stopping tasks ... 
Stopping kernel threads timed out after 20 seconds (1 tasks refusing to 
freeze):
 cryptd
Restarting tasks ... done.
swsusp: Basic memory bitmaps freed

I have no idea what's the problem, but if you tell me what I should do I can 
create debugging information and/or test patches.

I have my config attached, the kernel is 2.6.22-rc3

Maxi
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.22-rc3
# Sat May 26 10:07:12 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_PARAVIRT is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUMM=y
# CONFIG_MCORE2 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_MODEL=4
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_

Re: [RFC] LZO de/compression support - take 3

[Pavel Machek]

Hi!

> Perhaps you have opinion of maintaining diffability with 
> original LZO
> code which differs from mine. Since the code is now just 
> ~500 lines it
> should be fair enough to have major overhauls for sake 
> of clean
> KernelStyle(tm) code. It shouldn't be that hard to 
> verify this small
> code for bugs that might have crept in during porting 
> work. As regard
> to keeping up with future LZO versions, hm that will 
> be hard - but
> I don't think algorithm itself will change and 
> optimizations can
> always be done separately in this fork.
> 
> >
> >> I'd agree with the proposed renaming.  In fact I'd 
> >suggest that the unsafe
> >> APIs just be removed - it's hard to imagine a 
> >situation in which they're OK
> >> to be used in the kernel.
> >
> >The compressed cache code might be one exception since 
> >it does the
> >compression itself and shouldn't get corrupted. If it 
> >does get
> >corrupted, you have bigger problems.
> >
> 
> Yes. Compressed Caching is one of cases where compressed 
> data cannot
> get magically corrupted. Hence, there is no need to go 
> for the 'safe'
> version. There might be other such cases too, so 
> removing 'unsafe'
> version is not good.

What is the performance difference between safe and unsafe version?

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

Re: [RFC PATCH] file as directory

[Pavel Machek]

Hi!

> > As for unlink...  How do you deal with having that thing
> > mounted, mounting something _under_ it (so that vfsmount would be kept
> > busy) and then unlinking that sucker?
> 
> Yeah, that's a good point.  Current patch doesn't deal with that.
> Simplest solution could be to disallow submounting these.  Don't think
> it makes much sense anyway.

Hmmm, cd foo.tgz/bar/baz.tgz/xyzzy makes sense, and it is implemented
as a submount, no?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)

[Pavel Machek]

Hi!

> > > #1, This is why periodic checks are a good thing; it catches problems
> > > that could stay hidden and result in data loss sooner rather later.
> > 
> > Actually, I see something funny with periodic checks here. It claims
> > 'filesystem check on next boot' for >10 boots now.
> > 
> > It is sharp zaurus machine, and the filesystem tends to _never_ be
> > unmounted correctly (broken scripts), so I get journal replay each
> > time.
> 
> The Sharp Zaurus is a PDA which is almost always running on battery,
> right?   You need to add to /etc/e2fsck.conf:

Right. Could we get more helpful message here? 'Filesystem check on
next boot on AC power'? Or maybe keep counting, and when we reach 2x
mount-count-limit, force a fsck, battery power or not?

> [options]
>   defer_check_on_battery = false

I guess openembedded people should make this default on zauruses...

> power.  But for a PDA running a flash drive which is almost always
> running on battery you'll want to change the default using
> e2fsck.conf.

I'll just remember to do it manually, I guess. 

But here's what I've got:

[EMAIL PROTECTED]:/home/pavel# fsck.ext2 -f /dev/hda3
e2fsck 1.38 (30-Jun-2005)
Pass 1: Checking inodes, blocks, and sizes
Inode 371989 has illegal block(s).  Clear? yes

Illegal block #2 (134217728) in inode 371989.  CLEARED.
Pass 2: Checking directory structure

i_file_acl for inode 371988 (/home/root/misc/zaurus/smail) is 131072,
should be zero.
Clear? yes

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -339972 +471044
Fix? yes

Free blocks count wrong for group #10 (13882, counted=13883).
Fix? yes

...kernel 2.6.16-preempt (on zaurus). Filesystem should have been clean -- I was
using it till crash for half a year, but that's what journal is for,
right? ...But I guess this is almost impossible to debug?

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

Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)

[Maximilian Engelhardt]

On Saturday 26 May 2007, Michael Buesch wrote:
> On Friday 25 May 2007 21:40, Uwe Bugla wrote:
> > Am Freitag, 25. Mai 2007 20:48 schrieben Sie:
> > > On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote:
> > > > Perhaps someone reading this could try to reproduce that problem on
> > > > his machine.
> > > > Now who of the readers owes a Broadcom 4401 NIC and can please try to
> > > > test kernel 2.6.22-rc2-mm1?
> > > >
> > > > Those NICs have been used very very often as onboard controllers,
> > > > especially on ASUS boards.
> > >
> > > I've been using 2.6.22-rc2 for some time and now I compiled 2.6.22-rc2-
> > > mm1 and both work fine with the BCM4401 in my laptop.
> > >
> > > Maxi
> >
> > Hello Maxi,
> >
> > That may be true for your Laptop, but it unfortunately isn't true for my
> > ASUS mainboard onboard controller.
> >
> > Unfortunately I cannot confirm this:
> >
> > My broadcom 4401 driver is not part of a notebook, but instead part of an
> > ASUS P4PE mainboard.
> >
> > At my second attempt I went the conventional path (i. e. ignoring the
> > fact that
> > "Broadcom 4400 ethernet support appears twice in section "Network device
> > support":
> >
> > Whether you leave out "EISA, VLB, PCI and on board controllers" or not it
> > simply appears twice in kernel config! This is bug number 1.
>
> No it is NOT a bug.
> It simply shows again that you don't know how b44, ssb or anything related
> works.
>
> Would you _please_ take a look at the code, before calling features bugs.
> And yes, this IS a feature. It is a feature to get b44 running on an
> OpenWRT embedded device. These devices don't have a PCI bus. So b44 MUST
> NOT depend on "EISA, VLB, PCI and on board controllers".
> "Broadcom 4400 PCI device support" does depend on "EISA, VLB, PCI and on
> board controllers".
>
> Everything is correct.
> Bug number 1 is solved.
> qed
>
> > This time I do get a "good" interrupt: IRQ 21 for the the device.
> >
> > BUT:
> >
> > Trying to ping another machine fails saying:
> >
> > "destination host unreachable"
> >
> >
> > That means, Although the interrupt is fine now, the device is still not
> > functionable.
>
> And it's completely impossible that you did a mistake when configuring
> the device? Typo in the IP? Typo in the gateway or DNS entries?
> Try it again, please.
> And please try with current wireless-dev tree.
>
> And I simply do not get it why you suddenly get a good IRQ number, like
> everybody else does, without fixing The Bug (tm).

I did run my 2.6.22-rc2-mm1 kernel a bit longer and noticed that I was wrong 
in my first mail. The driver does work with my 4401 and network traffic seem 
to get out and in fine, but it has huge performance problems. If I do some 
pings and traceroutes I sometimes get response times of only a few ms but I 
also get times of a few seconds. Also trying to play games is totally 
impossible. This doesn't happen with 2.6.22-rc2 and 2.6.22-rc3.

Maxi


signature.asc
Description: This is a digitally signed message part.

Re: software suspend doesn't work with 2.6.22-rc3

[Nigel Cunningham]

Hi.

On Sat, 2007-05-26 at 11:28 +0200, Maximilian Engelhardt wrote:
> Hello,
> 
> When I try software suspend on my laptop it always returns to my running 
> system after some time.
> This is what's logged by the kernel:
> 
> swsusp: Basic memory bitmaps created
> Stopping tasks ... 
> Stopping kernel threads timed out after 20 seconds (1 tasks refusing to 
> freeze):
>  cryptd
> Restarting tasks ... done.
> swsusp: Basic memory bitmaps freed
> 
> I have no idea what's the problem, but if you tell me what I should do I can 
> create debugging information and/or test patches.

Could you try this patch, please? It should help.

Herbert, is this right? If cryptd is going to be used for block devs,
the task should probably be PF_NOFREEZE (or whatever it is today)
instead.

Regards,

Nigel

 crypto/cryptd.c |1 +
 include/linux/freezer.h |3 +++
 kernel/power/process.c  |2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)
diff -ruNp 991-fix-cryptd.patch-old/crypto/cryptd.c 
991-fix-cryptd.patch-new/crypto/cryptd.c
--- 991-fix-cryptd.patch-old/crypto/cryptd.c2007-05-19 18:16:47.0 
+1000
+++ 991-fix-cryptd.patch-new/crypto/cryptd.c2007-05-26 19:45:42.0 
+1000
@@ -341,6 +341,7 @@ static int cryptd_thread(void *data)
 
mutex_unlock(&state->mutex);
 
+   try_to_freeze();
schedule();
} while (!stop);
 



signature.asc
Description: This is a digitally signed message part

[PATCH] ieee1394: eth1394: bring back a parent device

[Stefan Richter]

I will submit this for 2.6.22-rc and 2.6.21.y if nobody objects.

Date: Mon, 21 May 2007 01:05:41 +0200
From: Stefan Richter <[EMAIL PROTECTED]>
Subject: ieee1394: eth1394: bring back a parent device

This adds a real parent device to eth1394's ethX device like in Linux
2.6.20 and older.  However, due to unfinished conversion of the ieee1394
away from class_device, we now refer to the FireWire controller's PCI
device as the parent, not to the ieee1394 driver's fw-host device.

Having a real parent device instead of a virtual one allows udev scripts
to distinguish eth1394 interfaces from networking bridges, bondings and
the likes.

Fixes a regression since 2.6.21:
https://bugs.gentoo.org/show_bug.cgi?id=177199

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
 drivers/ieee1394/eth1394.c |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

Index: linux-2.6.22-rc2/drivers/ieee1394/eth1394.c
===
--- linux-2.6.22-rc2.orig/drivers/ieee1394/eth1394.c
+++ linux-2.6.22-rc2/drivers/ieee1394/eth1394.c
@@ -599,10 +599,9 @@ static void ether1394_add_host(struct hp
}
 
SET_MODULE_OWNER(dev);
-#if 0
-   /* FIXME - Is this the correct parent device anyway? */
-   SET_NETDEV_DEV(dev, &host->device);
-#endif
+
+   /* This used to be &host->device in Linux 2.6.20 and before. */
+   SET_NETDEV_DEV(dev, host->device.parent);
 
priv = netdev_priv(dev);
INIT_LIST_HEAD(&priv->ip_node_list);

-- 
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] mm: swap prefetch increase aggressiveness and tunability

[Con Kolivas]

Swap prefetch is currently too lax in prefetching with extended idle periods
unused. Increase its aggressiveness and tunability.

Make it possible for swap_prefetch to be set to a high value ignoring load
and prefetching regardless.

Add tunables to modify the swap prefetch delay and sleep period on the
fly, and decrease both periods to 1 and 5 seconds respectively.
Extended periods did not decrease the impact any further but greatly
diminished the rate ram was prefetched.

Remove the prefetch_watermark that left free ram unused. The impact of using
the free ram with prefetched pages being put on the tail end of the inactive
list would be minimal and potentially very beneficial, yet testing the
pagestate adds unnecessary expense.

Put kprefetchd to sleep if the low watermarks are hit instead of delaying it.

Increase the maxcount as the lazy removal of swapped entries means we can
easily have many stale entries and not enough entries for good swap prefetch.

Do not delay prefetch in cond_resched() returning positive. That was
pointless and frequently put kprefetchd to sleep for no reason.

Update comments and documentation.

Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>

---
 Documentation/sysctl/vm.txt   |   33 +++-
 include/linux/swap-prefetch.h |3 
 kernel/sysctl.c   |   16 
 mm/swap_prefetch.c|  164 +-
 4 files changed, 117 insertions(+), 99 deletions(-)

Index: linux-2.6.22-rc2-mm1/include/linux/swap-prefetch.h
===
--- linux-2.6.22-rc2-mm1.orig/include/linux/swap-prefetch.h 2007-05-26 
18:52:52.0 +1000
+++ linux-2.6.22-rc2-mm1/include/linux/swap-prefetch.h  2007-05-26 
18:53:53.0 +1000
@@ -4,6 +4,9 @@
 #ifdef CONFIG_SWAP_PREFETCH
 /* mm/swap_prefetch.c */
 extern int swap_prefetch;
+extern int swap_prefetch_delay;
+extern int swap_prefetch_sleep;
+
 struct swapped_entry {
swp_entry_t swp_entry;  /* The actual swap entry */
struct list_headswapped_list;   /* Linked list of entries */
Index: linux-2.6.22-rc2-mm1/kernel/sysctl.c
===
--- linux-2.6.22-rc2-mm1.orig/kernel/sysctl.c   2007-05-26 18:52:52.0 
+1000
+++ linux-2.6.22-rc2-mm1/kernel/sysctl.c2007-05-26 18:53:53.0 
+1000
@@ -978,6 +978,22 @@ static ctl_table vm_table[] = {
.mode   = 0644,
.proc_handler   = &proc_dointvec,
},
+   {
+   .ctl_name   = CTL_UNNUMBERED,
+   .procname   = "swap_prefetch_delay",
+   .data   = &swap_prefetch_delay,
+   .maxlen = sizeof(swap_prefetch_delay),
+   .mode   = 0644,
+   .proc_handler   = &proc_dointvec,
+   },
+   {
+   .ctl_name   = CTL_UNNUMBERED,
+   .procname   = "swap_prefetch_sleep",
+   .data   = &swap_prefetch_sleep,
+   .maxlen = sizeof(swap_prefetch_sleep),
+   .mode   = 0644,
+   .proc_handler   = &proc_dointvec,
+   },
 #endif
{ .ctl_name = 0 }
 };
Index: linux-2.6.22-rc2-mm1/mm/swap_prefetch.c
===
--- linux-2.6.22-rc2-mm1.orig/mm/swap_prefetch.c2007-05-26 
18:52:52.0 +1000
+++ linux-2.6.22-rc2-mm1/mm/swap_prefetch.c 2007-05-26 18:57:17.0 
+1000
@@ -1,7 +1,7 @@
 /*
  * linux/mm/swap_prefetch.c
  *
- * Copyright (C) 2005-2006 Con Kolivas
+ * Copyright (C) 2005-2007 Con Kolivas
  *
  * Written by Con Kolivas <[EMAIL PROTECTED]>
  *
@@ -23,15 +23,22 @@
 #include 
 
 /*
- * Time to delay prefetching if vm is busy or prefetching unsuccessful. There
- * needs to be at least this duration of idle time meaning in practice it can
- * be much longer
+ * sysctls:
+ * swap_prefetch:  0. Disable swap prefetching
+ * 1. Prefetch only when idle and not with laptop_mode
+ * 2. Prefetch when idle and with laptop_mode
+ * 3. Prefetch at all times.
+ * swap_prefetch_delay:Number of seconds to delay prefetching when 
system
+ * is not idle.
+ * swap_prefetch_sleep:Number of seconds to put kprefetchd to sleep 
when
+ * unable to prefetch.
  */
-#define PREFETCH_DELAY (HZ * 5)
-#define DISABLED_PREFETCH_DELAY(HZ * 60)
-
-/* sysctl - enable/disable swap prefetching */
 int swap_prefetch __read_mostly = 1;
+int swap_prefetch_delay __read_mostly = 1;
+int swap_prefetch_sleep __read_mostly = 5;
+
+#define PREFETCH_DELAY (HZ * swap_prefetch_delay)
+#define PREFETCH_SLEEP ((HZ * swap_prefetch_sleep) ? : 1)
 
 struct swapped_root {
unsigned long   busy;   /* vm busy */
@@ -73,7 +80,7 @@ static inline int prefe

Re: Extending boot protocol & bzImage for paravirt_ops

[Rusty Russell]

On Fri, 2007-05-25 at 10:46 -0600, Eric W. Biederman wrote:
> Most of that though is just packaging.  The meat of the issue
> is how do we upgrade the bootloader data.  Do the changes
> below sound like everything we need?
> 
>  Field name:  loadflags
>  Type:modify (obligatory)
>  Offset/size: 0x211/1
>  Protocol:2.00+
>  
>This field is a bitmask.
>  
>Bit 0 (read):  LOADED_HIGH
>   - If 0, the protected-mode code is loaded at 0x1.
>   - If 1, the protected-mode code is loaded at 0x10.
> 
> +  Bit 6 (write): KEEP_SEGMENTS
> + Protocol: 2.07+
> + - if 0, reload the segment registers in the 32bit entry point.
> + - if 1, do not reload the segment registers in the 32bit entry point.
> + Assume that %cs %ds %ss %es are all set to flat segments with
> + a base of 0 (or the equivalent for their environment).

You also want to skip the cli: perhaps a separate flag for this is
appropriate though.

Rest looks fine from an lguest POV.  We don't need the platform data
field either, since we use the first hypercall to get that).

Cheers,
Rusty.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] LZO de/compression support - take 3

[Michael-Luke Jones]

On 25 May 2007, at 11:42, Pavel Machek wrote:

What is the performance difference between safe and unsafe version?


On 24 May 2007, at 23:26, Richard Purdie wrote:
For my minilzo kernel patch, the safe version showed a 7.2%  
performance

hit.


The conclusion seemed to be that we should drop the 'unsafe' version  
on this basis.


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

Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.

[Tejun Heo]

Hello, Neil Brown.

Please cc me on blkdev barriers and, if you haven't yet, reading
Documentation/block/barrier.txt can be helpful too.

Neil Brown wrote:
[--snip--]
> 1/ SAFE.  With a SAFE device, there is no write-behind cache, or if
>   there is it is non-volatile.  Once a write completes it is 
>   completely safe.  Such a device does not require barriers
>   or ->issue_flush_fn, and can respond to them either by a
> no-op or with -EOPNOTSUPP (the former is preferred).
> 
> 2/ FLUSHABLE.
>   A FLUSHABLE device may have a volatile write-behind cache.
>   This cache can be flushed with a call to blkdev_issue_flush.
> It may not support barrier requests.
> 
> 3/ BARRIER.
> A BARRIER device supports both blkdev_issue_flush and
>   BIO_RW_BARRIER.  Either may be used to synchronise any
> write-behind cache to non-volatile storage (media).
> 
> Handling of SAFE and FLUSHABLE devices is essentially the same and can
> work on a BARRIER device.  The BARRIER device has the option of more
> efficient handling.

Actually, all above three are handled by blkdev flush code.

> How does a filesystem use this?
> ===
> 
[--snip--]
> 2/ Set the BIO_RW_BARRIER bit in the write request for the commit
> block.
>(This is more efficient on BARRIER).

This really should be enough.

> HOW DO MD or DM USE THIS
> 
> 
> 1/ striping devices.
>  This includes md/raid0 md/linear dm-linear dm-stripe and probably
>  others. 
> 
>These devices can easily support blkdev_issue_flush by simply
>calling blkdev_issue_flush on all component devices.
> 
>These devices would find it very hard to support BIO_RW_BARRIER.
>Doing this would require keeping track of all in-flight requests
>(which some, possibly all, of the above don't) and then:
>  When a BIO_RW_BARRIER request arrives:
> wait for all pending writes to complete
> call blkdev_issue_flush on all devices
> issue the barrier write to the target device(s)
>as BIO_RW_BARRIER,
> if that is -EOPNOTSUP, re-issue, wait, flush.

Hmm... What do you think about introducing zero-length BIO_RW_BARRIER
for this case?

> 2/ Mirror devices.  This includes md/raid1 and dm-raid1.
> 
>These device can trivially implement blkdev_issue_flush much like
>the striping devices, and can support BIO_RW_BARRIER to some
>extent.
>md/raid1 currently tries.  I'm not sure about dm-raid1.
> 
>md/raid1 determines if the underlying devices can handle
>BIO_RW_BARRIER.  If any cannot, it rejects such requests (EOPNOTSUP)
>itself.
>If all underlying devices do appear to support barriers, md/raid1
>will pass a barrier-write down to all devices.
>The difficulty comes if it fails on one device, but not all
>devices.  In this case it is not clear what to do.  Failing the
>request is a lie, because some data has been written (possible too
>early).  Succeeding the request (after re-submitting the failed
>requests) is also a lie as the barrier wasn't really honoured.
>md/raid1 currently takes the latter approach, but will only do it
>once - after that it fails all barrier requests.
> 
>Hopefully this is unlikely to happen.  What device would work
>correctly with barriers once, and then not the next time?
>The answer is md/raid1.  If you remove a failed device and add a
>new device that doesn't support barriers, md/raid1 will notice and
>stop supporting barriers.
>If md/raid1 can change from supporting barrier to not, then maybe
>some other device could too?
> 
>I'm not sure what to do about this - maybe just ignore it...

That sounds good.  :-)

> 3/ Other modules
> 
>Other md and dm modules (raid5, mpath, crypt) do not add anything
>interesting to the above.  Either handling BIO_RW_BARRIER is
>trivial, or extremely difficult.
> 
> HOW DO LOW LEVEL DEVICES HANDLE THIS
> 
> 
> This is part of the picture that I haven't explored greatly.  My
> feeling is that most if not all devices support blkdev_issue_flush
> properly, and support barriers reasonably well providing that the
> hardware does.
> There in an exception I recently found though.
> For devices that don't support QUEUE_ORDERED_TAG (i.e. commands sent to
> the controller can be tagged as barriers), SCSI will use the
> SYNCHRONIZE_CACHE command to flush the cache after the barrier
> request (a bit like the filesystem calling blkdev_issue_flush, but at
> a lower level). However it does this without setting the SYNC_NV bit.
> This means that a device with a non-volatile cache will be required --
> needlessly -- to flush that cache to media.

Yeah, it probably needs updating but some devices might react badly too.

> So: some questions to help encourage response:
> 
>  - Is the above substantial correct?  Totally correct?

Re: [RFC] LZO de/compression support - take 4

[Richard Purdie]

Hi Nitin,

On Fri, 2007-05-25 at 18:27 +0530, Nitin Gupta wrote:
> On 5/25/07, Richard Purdie <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote:
> > > Richard, can you please provide perf. results for this patch also?
> > > Also, can you please mail back latest version of your LZO patch? In
> > > meantime, I will try to include benchmarking support to the
> > > 'compress-test' module.
> >
> > This version is 15% slower at decompression and about equal on
> > compression.
> >
> 
> If you don't mind, can you please try patch attached now? I have now
> also rolled back that cpu_to_le16() change as Satyam suggested. I see
> no other reason for this perf. loss as I made no other change!
> 
> Also, can you please verify if you are comparing your _safe_ version
> with this patch? This patch does not include unsafe version and the
> safe one is simply called lzo1x_decompress().

I've been looking at my benchmark figures and I think I've found why the
figures for my version were different to yours. Its not your code which
is at fault, its the way it was hooked into the benchmarking program.
The compiler was inlining some parts which it shouldn't have been
allowed to do, sorry :-/.

With that issue corrected, decompression is the same speed however
compression is showing about a 9% performance loss compared to my kernel
patch.

I did some diffs of the assembler outputted by our two versions (mine
matches minilzo). For decompression the output is effectively identical.
For compression, there are significant differences. If I add a noinline
attribute to lzo1x_compress_worker, that removes a lot of them (and
boosts speed a bit) but there are still differences. Ideally, I'd like
to understand why.

Regards,

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: BUG in 2.6.22-rc2-mm1: Parts of Alsa sound architecture broken

[Jan Engelhardt]

On May 25 2007 10:28, Andrew Morton wrote:
>> 
>> > snd: Unknown symbol unregister_sound_special
>> > snd: Unknown symbol register_sound_special_device
>> > snd: Unknown symbol sound_class
>> 
>> Uwe, could you try to revert this patch?
>> use-menuconfig-objects-ii-sound.patch
>
>I think that patch has rotted.  Too many underlying changes and the
>handling of HAS_IOMEM (at least) appears to have been broken (by my
>fixups).
>
>I'll drop it.
>
>If/when Jan resends it, pleze consider it promptly and don't leave
>me trying to maintain the thing while you guys are madly changing other
>stuff underneath it?


Here they are...



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/

[PATCH 01/04] Use menuconfig objects 3 - sound

[Jan Engelhardt]

CONFIG_SOUND, CONFIG_SND, CONFIG_SOUND_PRIME, ...:
Change Kconfig objects from "menu, config" into "menuconfig" so
that the user can disable the whole feature without having to
enter the menu first.

CONFIG_SND_*_DRIVERS:
Make a "menuconfig" out of the Kconfig objects "menu, ..., endmenu",
so that the user can disable all the options in that menu at once
instead of having to disable each option separately.

Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>

---
 sound/Kconfig  |   12 +---
 sound/aoa/soundbus/Kconfig |1 -
 sound/oss/dmasound/Kconfig |6 +++---
 3 files changed, 8 insertions(+), 11 deletions(-)

Index: linux-2.6.22-rc3/sound/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/Kconfig
+++ linux-2.6.22-rc3/sound/Kconfig
@@ -1,11 +1,9 @@
 # sound/Config.in
 #
 
-menu "Sound"
-   depends on HAS_IOMEM
-
-config SOUND
+menuconfig SOUND
tristate "Sound card support"
+   depends on HAS_IOMEM
help
  If you have a sound card in your computer, i.e. if it can say more
  than an occasional beep, say Y.  Be sure to have all the information
@@ -33,6 +31,8 @@ config SOUND
  Kernel patches and supporting utilities to do that are in the pcsp
  package, available at .
 
+if SOUND
+
 source "sound/oss/dmasound/Kconfig"
 
 if !M68K
@@ -42,7 +42,6 @@ menu "Advanced Linux Sound Architecture"
 
 config SND
tristate "Advanced Linux Sound Architecture"
-   depends on SOUND
help
  Say 'Y' or 'M' to enable ALSA (Advanced Linux Sound Architecture),
  the new base sound system.
@@ -86,7 +85,6 @@ menu "Open Sound System"
 
 config SOUND_PRIME
tristate "Open Sound System (DEPRECATED)"
-   depends on SOUND
help
  Say 'Y' or 'M' to enable Open Sound System drivers.
 
@@ -104,4 +102,4 @@ config AC97_BUS
  sound although they're sharing the AC97 bus. Concerned drivers
  should "select" this.
 
-endmenu
+endif # SOUND
Index: linux-2.6.22-rc3/sound/aoa/soundbus/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/aoa/soundbus/Kconfig
+++ linux-2.6.22-rc3/sound/aoa/soundbus/Kconfig
@@ -1,6 +1,5 @@
 config SND_AOA_SOUNDBUS
tristate "Apple Soundbus support"
-   depends on SOUND
select SND_PCM
---help---
This option enables the generic driver for the soundbus
Index: linux-2.6.22-rc3/sound/oss/dmasound/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/oss/dmasound/Kconfig
+++ linux-2.6.22-rc3/sound/oss/dmasound/Kconfig
@@ -1,6 +1,6 @@
 config DMASOUND_ATARI
tristate "Atari DMA sound support"
-   depends on ATARI && SOUND
+   depends on ATARI
select DMASOUND
help
  If you want to use the internal audio of your Atari in Linux, answer
@@ -14,7 +14,7 @@ config DMASOUND_ATARI
 
 config DMASOUND_PAULA
tristate "Amiga DMA sound support"
-   depends on (AMIGA || APUS) && SOUND
+   depends on AMIGA || APUS
select DMASOUND
help
  If you want to use the internal audio of your Amiga in Linux, answer
@@ -28,7 +28,7 @@ config DMASOUND_PAULA
 
 config DMASOUND_Q40
tristate "Q40 sound support"
-   depends on Q40 && SOUND
+   depends on Q40
select DMASOUND
help
  If you want to use the internal audio of your Q40 in Linux, answer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 02/04] Use menuconfig objects 3 - sound/alsa

[Jan Engelhardt]

CONFIG_SOUND, CONFIG_SND, CONFIG_SOUND_PRIME, ...:
Change Kconfig objects from "menu, config" into "menuconfig" so
that the user can disable the whole feature without having to
enter the menu first.

CONFIG_SND_*_DRIVERS:
Make a "menuconfig" out of the Kconfig objects "menu, ..., endmenu",
so that the user can disable all the options in that menu at once
instead of having to disable each option separately.

Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>

---
 sound/Kconfig |   10 
 sound/aoa/Kconfig |1 
 sound/arm/Kconfig |6 ++---
 sound/core/Kconfig|   18 ++-
 sound/drivers/Kconfig |8 +-
 sound/isa/Kconfig |   36 +-
 sound/mips/Kconfig|2 -
 sound/parisc/Kconfig  |1 
 sound/pci/Kconfig |   60 ++
 sound/pcmcia/Kconfig  |4 +--
 sound/ppc/Kconfig |6 ++---
 sound/soc/Kconfig |1 
 sound/sparc/Kconfig   |5 +---
 sound/usb/Kconfig |6 ++---
 14 files changed, 34 insertions(+), 130 deletions(-)

Index: linux-2.6.22-rc3/sound/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/Kconfig
+++ linux-2.6.22-rc3/sound/Kconfig
@@ -37,17 +37,17 @@ source "sound/oss/dmasound/Kconfig"
 
 if !M68K
 
-menu "Advanced Linux Sound Architecture"
-   depends on SOUND!=n
-
-config SND
+menuconfig SND
tristate "Advanced Linux Sound Architecture"
+   depends on SOUND!=n
help
  Say 'Y' or 'M' to enable ALSA (Advanced Linux Sound Architecture),
  the new base sound system.
 
  For more information, see 
 
+if SND
+
 source "sound/core/Kconfig"
 
 source "sound/drivers/Kconfig"
@@ -78,7 +78,7 @@ source "sound/parisc/Kconfig"
 
 source "sound/soc/Kconfig"
 
-endmenu
+endif # SND
 
 menu "Open Sound System"
depends on SOUND!=n
Index: linux-2.6.22-rc3/sound/aoa/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/aoa/Kconfig
+++ linux-2.6.22-rc3/sound/aoa/Kconfig
@@ -3,7 +3,6 @@ menu "Apple Onboard Audio driver"
 
 config SND_AOA
tristate "Apple Onboard Audio driver"
-   depends on SND
select SND_PCM
---help---
This option enables the new driver for the various
Index: linux-2.6.22-rc3/sound/arm/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/arm/Kconfig
+++ linux-2.6.22-rc3/sound/arm/Kconfig
@@ -5,7 +5,7 @@ menu "ALSA ARM devices"
 
 config SND_SA11XX_UDA1341
tristate "SA11xx UDA1341TS driver (iPaq H3600)"
-   depends on ARCH_SA1100 && SND && L3
+   depends on ARCH_SA1100 && L3
select SND_PCM
help
  Say Y here if you have a Compaq iPaq H3x00 handheld computer
@@ -16,7 +16,7 @@ config SND_SA11XX_UDA1341
 
 config SND_ARMAACI
tristate "ARM PrimeCell PL041 AC Link support"
-   depends on SND && ARM_AMBA
+   depends on ARM_AMBA
select SND_PCM
select SND_AC97_CODEC
 
@@ -26,7 +26,7 @@ config SND_PXA2XX_PCM
 
 config SND_PXA2XX_AC97
tristate "AC97 driver for the Intel PXA2xx chip"
-   depends on ARCH_PXA && SND
+   depends on ARCH_PXA
select SND_PXA2XX_PCM
select SND_AC97_CODEC
help
Index: linux-2.6.22-rc3/sound/core/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/core/Kconfig
+++ linux-2.6.22-rc3/sound/core/Kconfig
@@ -1,24 +1,19 @@
 # ALSA soundcard-configuration
 config SND_TIMER
tristate
-   depends on SND
 
 config SND_PCM
tristate
select SND_TIMER
-   depends on SND
 
 config SND_HWDEP
tristate
-   depends on SND
 
 config SND_RAWMIDI
tristate
-   depends on SND
 
 config SND_SEQUENCER
tristate "Sequencer support"
-   depends on SND
select SND_TIMER
help
  Say Y or M to enable MIDI sequencer and router support.  This
@@ -44,11 +39,9 @@ config SND_SEQ_DUMMY
 
 config SND_OSSEMUL
bool
-   depends on SND
 
 config SND_MIXER_OSS
tristate "OSS Mixer API"
-   depends on SND
select SND_OSSEMUL
help
  To enable OSS mixer API emulation (/dev/mixer*), say Y here
@@ -61,7 +54,6 @@ config SND_MIXER_OSS
 
 config SND_PCM_OSS
tristate "OSS PCM (digital audio) API"
-   depends on SND
select SND_OSSEMUL
select SND_PCM
help
@@ -84,7 +76,7 @@ config SND_PCM_OSS_PLUGINS
 
 config SND_SEQUENCER_OSS
bool "OSS Sequencer API"
-   depends on SND && SND_SEQUENCER
+   depends on SND_SEQUENCER
select SND_OSSEMUL
help
  Say Y here to enable OSS sequencer emulation (both
@@ -98,7 +90,7 @@ config SND_SEQUENCER_OSS
 
 config SND_RTCTIMER
tristate "RTC Timer support"
-   depends on SND && RTC
+   depends o

[PATCH 03/04] Use menuconfig objects 3 - sound/alsa/more

[Jan Engelhardt]

CONFIG_SOUND, CONFIG_SND, CONFIG_SOUND_PRIME, ...:
Change Kconfig objects from "menu, config" into "menuconfig" so
that the user can disable the whole feature without having to
enter the menu first.

CONFIG_SND_*_DRIVERS:
Make a "menuconfig" out of the Kconfig objects "menu, ..., endmenu",
so that the user can disable all the options in that menu at once
instead of having to disable each option separately.

Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>

---
 sound/aoa/Kconfig |   10 +-
 sound/aoa/codecs/Kconfig  |4 
 sound/aoa/fabrics/Kconfig |1 -
 sound/arm/Kconfig |   11 ---
 sound/drivers/Kconfig |2 --
 sound/isa/Kconfig |   25 +++--
 sound/mips/Kconfig|   12 
 sound/parisc/Kconfig  |   12 +---
 sound/pci/Kconfig |   11 ---
 sound/pcmcia/Kconfig  |   14 +-
 sound/ppc/Kconfig |   11 ---
 sound/soc/Kconfig |9 -
 sound/soc/at91/Kconfig|2 +-
 sound/soc/codecs/Kconfig  |5 -
 sound/soc/pxa/Kconfig |2 +-
 sound/soc/s3c24xx/Kconfig |2 +-
 sound/sparc/Kconfig   |   12 +---
 sound/usb/Kconfig |   16 +---
 18 files changed, 95 insertions(+), 66 deletions(-)

Index: linux-2.6.22-rc3/sound/aoa/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/aoa/Kconfig
+++ linux-2.6.22-rc3/sound/aoa/Kconfig
@@ -1,17 +1,17 @@
-menu "Apple Onboard Audio driver"
-   depends on SND!=n && PPC_PMAC
-
-config SND_AOA
+menuconfig SND_AOA
tristate "Apple Onboard Audio driver"
+   depends on PPC_PMAC
select SND_PCM
---help---
This option enables the new driver for the various
Apple Onboard Audio components.
 
+if SND_AOA
+
 source "sound/aoa/fabrics/Kconfig"
 
 source "sound/aoa/codecs/Kconfig"
 
 source "sound/aoa/soundbus/Kconfig"
 
-endmenu
+endif # SND_AOA
Index: linux-2.6.22-rc3/sound/aoa/codecs/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/aoa/codecs/Kconfig
+++ linux-2.6.22-rc3/sound/aoa/codecs/Kconfig
@@ -1,6 +1,5 @@
 config SND_AOA_ONYX
tristate "support Onyx chip"
-   depends on SND_AOA
select I2C
select I2C_POWERMAC
---help---
@@ -10,7 +9,6 @@ config SND_AOA_ONYX
 
 #config SND_AOA_TOPAZ
 #  tristate "support Topaz chips"
-#  depends on SND_AOA
 #  ---help---
 #  This option enables support for the Topaz (CS84xx)
 #  codec chips found in the latest Apple machines,
@@ -19,7 +17,6 @@ config SND_AOA_ONYX
 
 config SND_AOA_TAS
tristate "support TAS chips"
-   depends on SND_AOA
select I2C
select I2C_POWERMAC
---help---
@@ -29,7 +26,6 @@ config SND_AOA_TAS
 
 config SND_AOA_TOONIE
tristate "support Toonie chip"
-   depends on SND_AOA
---help---
This option enables support for the toonie codec
found in the Mac Mini. If you have a Mac Mini and
Index: linux-2.6.22-rc3/sound/aoa/fabrics/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/aoa/fabrics/Kconfig
+++ linux-2.6.22-rc3/sound/aoa/fabrics/Kconfig
@@ -1,6 +1,5 @@
 config SND_AOA_FABRIC_LAYOUT
tristate "layout-id fabric"
-   depends on SND_AOA
select SND_AOA_SOUNDBUS
select SND_AOA_SOUNDBUS_I2S
---help---
Index: linux-2.6.22-rc3/sound/arm/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/arm/Kconfig
+++ linux-2.6.22-rc3/sound/arm/Kconfig
@@ -1,7 +1,12 @@
 # ALSA ARM drivers
 
-menu "ALSA ARM devices"
-   depends on SND!=n && ARM
+menuconfig SND_ARM_DRIVERS
+   bool "ALSA ARM devices"
+   depends on ARM
+   ---help---
+ Select this option if you want to select ARM specific sound drivers.
+
+if SND_ARM_DRIVERS
 
 config SND_SA11XX_UDA1341
tristate "SA11xx UDA1341TS driver (iPaq H3600)"
@@ -33,4 +38,4 @@ config SND_PXA2XX_AC97
  Say Y or M if you want to support any AC97 codec attached to
  the PXA2xx AC97 interface.
 
-endmenu
+endif # SND_ARM_DRIVERS
Index: linux-2.6.22-rc3/sound/drivers/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/drivers/Kconfig
+++ linux-2.6.22-rc3/sound/drivers/Kconfig
@@ -1,8 +1,6 @@
 # ALSA generic drivers
 
 menu "Generic devices"
-   depends on SND!=n
-
 
 config SND_MPU401_UART
 tristate
Index: linux-2.6.22-rc3/sound/isa/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/isa/Kconfig
+++ linux-2.6.22-rc3/sound/isa/Kconfig
@@ -1,7 +1,12 @@
 # ALSA ISA drivers
 
-menu "ISA devices"
-   depends on SND!=n && ISA && ISA_DMA_API
+menuconfig SND_ISA_DRIVERS
+   bool "ISA devices"
+   depends on ISA &&

[PATCH 04/04] Use menuconfig objects 3 - sound/oss

[Jan Engelhardt]

CONFIG_SOUND, CONFIG_SND, CONFIG_SOUND_PRIME, ...:
Change Kconfig objects from "menu, config" into "menuconfig" so
that the user can disable the whole feature without having to
enter the menu first.

CONFIG_SND_*_DRIVERS:
Make a "menuconfig" out of the Kconfig objects "menu, ..., endmenu",
so that the user can disable all the options in that menu at once
instead of having to disable each option separately.

Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>

---
 sound/Kconfig |   11 +--
 sound/oss/Kconfig |   39 +++
 2 files changed, 24 insertions(+), 26 deletions(-)

Index: linux-2.6.22-rc3/sound/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/Kconfig
+++ linux-2.6.22-rc3/sound/Kconfig
@@ -80,19 +80,18 @@ source "sound/soc/Kconfig"
 
 endif # SND
 
-menu "Open Sound System"
-   depends on SOUND!=n
-
-config SOUND_PRIME
+menuconfig SOUND_PRIME
tristate "Open Sound System (DEPRECATED)"
help
  Say 'Y' or 'M' to enable Open Sound System drivers.
 
+if SOUND_PRIME
+
 source "sound/oss/Kconfig"
 
-endmenu
+endif # SOUND_PRIME
 
-endif
+endif # !M68K
 
 config AC97_BUS
tristate
Index: linux-2.6.22-rc3/sound/oss/Kconfig
===
--- linux-2.6.22-rc3.orig/sound/oss/Kconfig
+++ linux-2.6.22-rc3/sound/oss/Kconfig
@@ -7,7 +7,6 @@
 
 config OSS_OBSOLETE
bool "Obsolete OSS drivers"
-   depends on SOUND_PRIME
help
  This option enables support for obsolete OSS drivers that
  are scheduled for removal in the near future.
@@ -20,7 +19,7 @@ config OSS_OBSOLETE
 
 config SOUND_BT878
tristate "BT878 audio dma"
-   depends on SOUND_PRIME && PCI && OSS_OBSOLETE
+   depends on PCI && OSS_OBSOLETE
---help---
  Audio DMA support for bt878 based grabber boards.  As you might have
  already noticed, bt878 is listed with two functions in /proc/pci.
@@ -36,7 +35,7 @@ config SOUND_BT878
 
 config SOUND_BCM_CS4297A
tristate "Crystal Sound CS4297a (for Swarm)"
-   depends on SOUND_PRIME && SIBYTE_SWARM
+   depends on SIBYTE_SWARM
help
  The BCM91250A has a Crystal CS4297a on synchronous serial
  port B (in addition to the DB-9 serial port).  Say Y or M
@@ -46,14 +45,14 @@ config SOUND_BCM_CS4297A
 
 config SOUND_ICH
tristate "Intel ICH (i8xx) audio support"
-   depends on SOUND_PRIME && PCI && OSS_OBSOLETE
+   depends on PCI && OSS_OBSOLETE
help
  Support for integral audio in Intel's I/O Controller Hub (ICH)
  chipset, as used on the 810/820/840 motherboards.
 
 config SOUND_VWSND
tristate "SGI Visual Workstation Sound"
-   depends on SOUND_PRIME && X86_VISWS
+   depends on X86_VISWS
help
  Say Y or M if you have an SGI Visual Workstation and you want to be
  able to use its on-board audio.  Read
@@ -62,14 +61,14 @@ config SOUND_VWSND
 
 config SOUND_HAL2
tristate "SGI HAL2 sound (EXPERIMENTAL)"
-   depends on SOUND_PRIME && SGI_IP22 && EXPERIMENTAL
+   depends on SGI_IP22 && EXPERIMENTAL
help
  Say Y or M if you have an SGI Indy or Indigo2 system and want to be 
able to
  use its on-board A2 audio system.
 
 config SOUND_VRC5477
tristate "NEC Vrc5477 AC97 sound"
-   depends on SOUND_PRIME && DDB5477
+   depends on DDB5477
help
  Say Y here to enable sound support for the NEC Vrc5477 chip, an
  integrated, multi-function controller chip for MIPS CPUs.  Works
@@ -78,11 +77,11 @@ config SOUND_VRC5477
 config SOUND_AU1550_AC97
tristate "Au1550/Au1200 AC97 Sound"
select SND_AC97_CODEC
-   depends on SOUND_PRIME && (SOC_AU1550 || SOC_AU1200)
+   depends on SOC_AU1550 || SOC_AU1200
 
 config SOUND_TRIDENT
tristate "Trident 4DWave DX/NX, SiS 7018 or ALi 5451 PCI Audio Core"
-   depends on SOUND_PRIME && PCI
+   depends on PCI
---help---
  Say Y or M if you have a PCI sound card utilizing the Trident
  4DWave-DX/NX chipset or your mother board chipset has SiS 7018
@@ -123,7 +122,7 @@ config SOUND_TRIDENT
 
 config SOUND_MSNDCLAS
tristate "Support for Turtle Beach MultiSound Classic, Tahiti, Monterey"
-   depends on SOUND_PRIME && (m || !STANDALONE)
+   depends on m || !STANDALONE
help
  Say M here if you have a Turtle Beach MultiSound Classic, Tahiti or
  Monterey (not for the Pinnacle or Fiji).
@@ -134,7 +133,7 @@ config SOUND_MSNDCLAS
  at .
 
 comment "Compiled-in MSND Classic support requires firmware during 
compilation."
-   depends on SOUND_PRIME && SOUND_MSNDCLAS=y
+   depends on SOUND_MSNDCLAS=y
 
 config MSNDCLAS_HAVE_BOOT
bool
@@ -187,7 +186,7 @@ config MSNDCLAS_IO
 
 config SOUND_MSNDPIN

Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)

[Uwe Bugla]

Am Samstag, 26. Mai 2007 07:00 schrieben Sie:
> On Friday 25 May 2007 21:40, Uwe Bugla wrote:
> > Am Freitag, 25. Mai 2007 20:48 schrieben Sie:
> > > On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote:
> > > > Perhaps someone reading this could try to reproduce that problem on
> > > > his machine.
> > > > Now who of the readers owes a Broadcom 4401 NIC and can please try to
> > > > test kernel 2.6.22-rc2-mm1?
> > > >
> > > > Those NICs have been used very very often as onboard controllers,
> > > > especially on ASUS boards.
> > >
> > > I've been using 2.6.22-rc2 for some time and now I compiled 2.6.22-rc2-
> > > mm1 and both work fine with the BCM4401 in my laptop.
> > >
> > > Maxi
> >
> > Hello Maxi,
> >
> > That may be true for your Laptop, but it unfortunately isn't true for my
> > ASUS mainboard onboard controller.
> >
> > Unfortunately I cannot confirm this:
> >
> > My broadcom 4401 driver is not part of a notebook, but instead part of an
> > ASUS P4PE mainboard.
> >
> > At my second attempt I went the conventional path (i. e. ignoring the
> > fact that
> > "Broadcom 4400 ethernet support appears twice in section "Network device
> > support":
> >
> > Whether you leave out "EISA, VLB, PCI and on board controllers" or not it
> > simply appears twice in kernel config! This is bug number 1.
>
> No it is NOT a bug.
> It simply shows again that you don't know how b44, ssb or anything related
> works.
>
> Would you _please_ take a look at the code, before calling features bugs.
> And yes, this IS a feature. It is a feature to get b44 running on an
> OpenWRT embedded device. These devices don't have a PCI bus. So b44 MUST
> NOT depend on "EISA, VLB, PCI and on board controllers".

Thanks for the descriptive lesson! But this explanation is displaced HERE.
It should be part of the Kconfig text instead, as the b44 running on an 
OpenWRT embedded device simply does not show up in Kernel configuration of 
2.6.21.2 and earlier kernels.
In so far there is a bug that I would call superficial and incomplete 
explanation of b44 features in Kconfig!

Just two or three explaining sentences at the appropriate place would do well 
instead of singing this aria again an again:

"It simply shows again that you don't know how b44, ssb or anything related 
works."

It's NOT MY task to be omnicient. Above that, the b44 modules have never been 
documented at all. So how can you expect me and others to know about the 
latest features of version 2? Very strange behaviour of yours ) :

> "Broadcom 4400 PCI device support" does depend on "EISA, VLB, PCI and on
> board controllers".

Thanks, now I know. But the dependencies chaos plus the PCI disfunctionality 
stays unfortunately!

>
> Everything is correct.
> Bug number 1 is solved.

NO! See above please and DO NOT IGNORE!

> qed
>
> > This time I do get a "good" interrupt: IRQ 21 for the the device.
> >
> > BUT:
> >
> > Trying to ping another machine fails saying:
> >
> > "destination host unreachable"
> >
> >
> > That means, Although the interrupt is fine now, the device is still not
> > functionable.
>
> And it's completely impossible that you did a mistake when configuring
> the device? Typo in the IP? Typo in the gateway or DNS entries?

Yes! This sort of mistakes is completely impossible, as I use to work with 
aliases rather than IP adresses. The machine I tried to ping (i. e. my 
router) is called Jerry (as a reminiscence to Mr. "Captan Trips" from 
Grateful Dead), and thus "ping jerry" returned the following:

"destination host unreachable"

Above that, I state for the second time now that I reverted your patches in 
2.6.22-rc2-mm1 with the effect that everything worked perfectly!
Maxi said something at least similar. So how many proofs do you need, Mister 
Buesch, to finally pick up patchworking now?? 

So, the ball has been in your court for two days now, and you simply keep on 
hesitating to take action now. Instead you are playing a 
nonsense "I-am-not-responsible-and-you-don't-know-Ping-Pong game"
ignoring every hint, criticism that you are offered.
REAL GREAT!

> Try it again, please.

NO!

> And please try with current wireless-dev tree.

A. I do not know where to download that wireless-dev tree.
B. I do not know how to implement it into mm or mainline
C. I have given enough sophisticated proof that your stuff in mm-tree is 
highly incomplete / buggy.

>
> And I simply do not get it why you suddenly get a good IRQ number, like
> everybody else does, without fixing The Bug (tm).

That consequence I already explained:
But it's a pleasure for me to repeat it once more:

When you are saying Y to "EISA, VLB, PCI and on board controllers"

you simply do get not only completely different interrupts for the b4401 
device, but you get also completely different module dependencies.

If the module dependencies are correct the IRQ number is also correct,
If the module dependencies are broken the IRQ number is also broken.

It's as easy as that simply!

In other words, UTMOST CLE

Re: BUG in 2.6.22-rc2-mm1: Parts of Alsa sound architecture broken

[Jan Engelhardt]

On May 25 2007 23:33, Takashi Iwai wrote:
>
>Yeah, I'll check it again if reposted.  Jan, could you split ALSA
>portins at the next time?

How much split? This time, I made four out of it.

>This will make testing and merging much
>easier for me...
>
>But, above all, I'm not convinced much by that patch, especially
>because it introduces new kconfigs just for menuconfig.
>For example, CONFIG_SND_PCI_DRIVERS doesn't appear in any Makefiles.

Neither is/was CONFIG_DVB IIRC. The world does not stop turning just
because there are now extra options. If you want the functionality
of menuconfigs without introducing some variable to store their state,
well, I think that's going to be a bigger kconf patch. (Just think of
compatibility of the .config format.)


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: software suspend doesn't work with 2.6.22-rc3

[Herbert Xu]

On Sat, May 26, 2007 at 07:53:53PM +1000, Nigel Cunningham wrote:
> 
> Herbert, is this right? If cryptd is going to be used for block devs,
> the task should probably be PF_NOFREEZE (or whatever it is today)
> instead.

Probably.  However, I don't think this is responsible for the reported
problem because the code to use cryptd in dm-crypt hasn't been merged
yet :)

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: software suspend doesn't work with 2.6.22-rc3

[Nigel Cunningham]

Hi.

On Sat, 2007-05-26 at 21:08 +1000, Herbert Xu wrote:
> On Sat, May 26, 2007 at 07:53:53PM +1000, Nigel Cunningham wrote:
> > 
> > Herbert, is this right? If cryptd is going to be used for block devs,
> > the task should probably be PF_NOFREEZE (or whatever it is today)
> > instead.
> 
> Probably.  However, I don't think this is responsible for the reported
> problem because the code to use cryptd in dm-crypt hasn't been merged
> yet :)

You have the cryptd Kconfig option in (at least in rc3) - presumably
Maximillian has been too keen and turned it on before you were ready :)
It does make sense for it to be the problem. Without PF_NOFREEZE set,
the refrigerator code will try to get it to enter the freezer, and
without the try_to_freeze(), it will just loop and freezing will fail.

Regards,

Nigel


signature.asc
Description: This is a digitally signed message part

Re: [RFC] LZO de/compression support - take 3

[Nitin Gupta]

Hi Pavel,

Just did some benchmarking; results below.

On 5/25/07, Pavel Machek <[EMAIL PROTECTED]> wrote:


What is the performance difference between safe and unsafe version?



File size: 256K
- Following as tests for original test code - not any kernel port of this.
- Test with each block size repeated 5 times - taken avg. of these 5 runs.
- Same file used for each test.
- Used lzotest utility (included with LZO 2.02) for testing.

Blocksize   Comp*   DU* DS* Speed%
4   59.356  211.526 195.260 7.689
8   54.623  202.712 188.369 7.075
16  50.342  196.482 183.988 6.358
32  47.499  189.800 177.455 6.504
64  44.148  178.724 167.201 6.447
128 42.125  170.229 159.257 6.445
256 41.830  155.035 146.115 5.753

* All speeds in MB/sec
Comp = LZO1X-1
DU = Decompress (unsafe)
DS = Decompress (safe)
Speed% = ((DU-DS)/DU)*100

I have yet to see how the kernel ports compare against this original version.

Cheers,
Nitin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] LZO de/compression support - take 4

[Nitin Gupta]

Hi Richard,

On 5/26/07, Richard Purdie <[EMAIL PROTECTED]> wrote:


I've been looking at my benchmark figures and I think I've found why the
figures for my version were different to yours. Its not your code which
is at fault, its the way it was hooked into the benchmarking program.
The compiler was inlining some parts which it shouldn't have been
allowed to do, sorry :-/.

With that issue corrected, decompression is the same speed however
compression is showing about a 9% performance loss compared to my kernel
patch.

I did some diffs of the assembler outputted by our two versions (mine
matches minilzo). For decompression the output is effectively identical.
For compression, there are significant differences. If I add a noinline
attribute to lzo1x_compress_worker, that removes a lot of them (and
boosts speed a bit) but there are still differences. Ideally, I'd like
to understand why.



I will look more closely into compression code to see why you are
getting this perf. difference here.

Thanks for your tests.

- Nitin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] LZO de/compression support - take 3

[Nitin Gupta]

Hi Bret,

On 5/25/07, Bret Towe <[EMAIL PROTECTED]> wrote:


[  237.556167] LZO compress successful: orig_size=17448, comp_size=8183
[  253.320760] LZO decompress successful: decomp_size=17448

2221c586e3eb869af7f4333d4f56b441b9aa8414  test-input
2e6c96b687274b629308b29835cebd3af989e0c7  output

ppc however seems bust
the computer is a g4 mini



Can you please test the 'take 4' version on ppc?
Just one line change: Please replace call to lzo1x_decompress_safe()
to lzo1x_decompress() in compress-test module.

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

[Andreas Gruenbacher]

On Saturday 26 May 2007 07:20, Kyle Moffett wrote:
> On May 24, 2007, at 14:58:41, Casey Schaufler wrote:
> > On Fedora zcat, gzip and gunzip are all links to the same file.  I  
> > can imagine (although it is a bit of a stretch) allowing a set of  
> > users access to gunzip but not gzip (or the other way around).
> 
> That is a COMPLETE straw-man argument.  I can override your "check"  
> with this absolutely trivial perl code:
> 
> exec { "/usr/bin/gunzip" } "gzip", "-9", "some/file/to.gz";

The above Perl code executes /usr/bin/gunzip and sets argv[0] to "gzip", so 
this confirms that the value of argv[0] is arbitrary. Well great, we already 
knew.

> Pathname-based checks are pretty fundamentally insecure.

Please don't mix apples and pears. Some utilities change their behavior based 
on argv[0], which indeed is not secure. It doesn't have to be for those 
utilities' needs. This is different from pathname-based access control, which 
is based on the pathname of the binary actually being executed.

AppArmor does not look at argv[0] for anything, and doing so would be insane. 
So please don't jump to the wrong conclusions.

You can have application-level argv[0] checks in the binary that is hardlinked 
to /bin/gzip, /bin/gunzip, /bin/zcat. At the same time, the kernel knows 
which of these three versions it is executing, so from that point of view, 
they could be as well be separate copies, and different policy can be defined 
for each one of them. (This is ignoring the fact that for small utilities 
like gzip, profile inheritance is usually more useful than defining separate 
profiles.)

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

Re: software suspend doesn't work with 2.6.22-rc3

[Herbert Xu]

On Sat, May 26, 2007 at 09:14:00PM +1000, Nigel Cunningham wrote:
> 
> You have the cryptd Kconfig option in (at least in rc3) - presumably
> Maximillian has been too keen and turned it on before you were ready :)
> It does make sense for it to be the problem. Without PF_NOFREEZE set,
> the refrigerator code will try to get it to enter the freezer, and
> without the try_to_freeze(), it will just loop and freezing will fail.

OK that makes sense.  I'll apply your patch.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: fix section mismatch warnings in mtrr

[Indan Zupancic]

On Mon, May 21, 2007 17:11, Sam Ravnborg wrote:
> On Mon, May 21, 2007 at 02:52:39PM +0100, Jeremy Fitzhardinge wrote:
>> Sam Ravnborg wrote:
>> > There was another patch that removed the __init marker to _fix_ section 
>> > mismatch errors.
>> > I have lost the actual mail but I asked the submitter to send me a copy of
>> > the configuration so I could take a closer look.
>> > Obviously it was the wrong fix to remove the _init marker.
>>
>> Hm, I think there were two overlapping patches to address the problem.
>> One removed the __init markers, and was a bit of a hack.  Mine
>> restructured all the functions so that it was all done properly (ie,
>> init called init; cpuinit called cpuinit).  Looks like both got applied.
>
> OK, then all is good.

Did the patches reach 2.6.22-rc3 yet?

If they did, then the following warnings might need fixing:

WARNING: arch/i386/kernel/built-in.o(.text+0x84bc): Section mismatch: reference 
to
.init.text:amd_init_mtrr (between 'mtrr_bp_init' and 'mtrr_attrib_to_str')
WARNING: arch/i386/kernel/built-in.o(.text+0x84c1): Section mismatch: reference 
to
.init.text:cyrix_init_mtrr (between 'mtrr_bp_init' and 'mtrr_attrib_to_str')
WARNING: arch/i386/kernel/built-in.o(.text+0x84c6): Section mismatch: reference 
to
.init.text:centaur_init_mtrr (between 'mtrr_bp_init' and 'mtrr_attrib_to_str')
WARNING: arch/i386/kernel/built-in.o(.text+0x92d8): Section mismatch: reference 
to .init.text:
(between 'get_mtrr_state' and 'generic_get_mtrr')
WARNING: arch/i386/kernel/built-in.o(.text+0x92ef): Section mismatch: reference 
to .init.text:
(between 'get_mtrr_state' and 'generic_get_mtrr')
WARNING: arch/i386/kernel/built-in.o(.text+0x9313): Section mismatch: reference 
to .init.text:
(between 'get_mtrr_state' and 'generic_get_mtrr')

Config attached.

Greetings,

Indan


config.gz
Description: application/gzip

Re: Pass struct vfsmount to the inode_create LSM hook

[Tetsuo Handa]

Hello.

Andreas Gruenbacher wrote:
> > exec { "/usr/bin/gunzip" } "gzip", "-9", "some/file/to.gz";
> The above Perl code executes /usr/bin/gunzip and sets argv[0] to "gzip", so 
> this confirms that the value of argv[0] is arbitrary. Well great, we already 
> knew.

> AppArmor does not look at argv[0] for anything, and doing so would be insane. 
> So please don't jump to the wrong conclusions.
I agree that argv[0] checking is different from pathname-based access control
or label-based access control, but I want to say argv[0] checking is still 
needed.

If you don't check argv[0], an attacker can request everything like

exec { "/bin/ls" } "/sbin/busybox", "cat", "/etc/shadow";
exec { "/bin/ls" } "/sbin/busybox", "rm", "/etc/shadow";

if /bin/ls and /bin/cat and /bin/rm are hardlinks of /sbin/busybox (e.g. 
embedded systems).

Therefore, TOMOYO Linux checks the combination of filename and argv[0] passed 
to execve().

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

[Andreas Gruenbacher]

On Friday 25 May 2007 21:06, Casey Schaufler wrote:
> --- Jeremy Maitin-Shepard <[EMAIL PROTECTED]> wrote:
> > ...
> > Well, my point was exactly that App Armor doesn't (as far as I know) do
> > anything to enforce the argv[0] convention,
>
> Sounds like an opportunity for improvement then.

Jeez, what argv[0] convention are you both talking about? argv[0] is not 
guaranteed to have any association with the name of the executable. Feel free 
to have any discussion about argv[0] you want, but *please* keep it away from 
AppArmor, which really has nothing to do with it.

It would be nice if you could stop calling argv[0] checks ``name-based access 
control'': from the point of view of the kernel no access control is 
involved, and even application-level argv[0] based access control makes no 
sense whatsoever.

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

Oops with prism54 in 2.6.22-rc3

[Maximilian Engelhardt]

Hello,

when using the prism54 driver including in the 2.6.22-rc3 kernel I get this 
Oops when putting the card into monitor mode:

BUG: unable to handle kernel NULL pointer dereference at virtual address 
01d8
 printing eip:
c0500608
*pde = 
Oops: 0002 [#1]
PREEMPT 
Modules linked in: fuse
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010046   (2.6.22-rc3 #2)
EIP is at netif_rx+0x48/0xc0
eax:    ebx: c18fdbc0   ecx: c087991c   edx: c0879910
esi: 0246   edi: f7c68010   ebp: f7fe0ba0   esp: c07bbef0
ds: 007b   es: 007b   fs:   gs:   ss: 0068
Process swapper (pid: 0, ti=c07ba000 task=c075a280 task.ti=c07ba000)
Stack: f7ec  c03d2b8f c07bbf24 0082 f7c68024 f7fe0800 c18fdbc0 
   0070 0046 0286 0286 0008 0007 0032dcd5  
   f7fe0ba0 0002 f7fe0800 c03d913d   f7f4d2c0  
Call Trace:
 [] islpci_eth_receive+0x12f/0x590
 [] islpci_interrupt+0x1cd/0x280
 [] handle_IRQ_event+0x25/0x50
 [] handle_fasteoi_irq+0x5c/0xe0
 [] do_IRQ+0x4a/0x80
 [] common_interrupt+0x23/0x28
 [] default_idle+0x2a/0x40
 [] cpu_idle+0x43/0x80
 [] start_kernel+0x21a/0x260
 [] unknown_bootoption+0x0/0x260
 ===
Code: c7 43 0c 00 00 00 00 c7 43 10 00 00 00 00 9c 5e fa ff 05 bc 9c 87 c0 a1 
0c 99 87 c0 3b 05 c0 4a 7b c0 77 30 85 c0 74 43 8b 43 14  80 d8 01 00 00 
a1 08 99 87 c0 ff 05 0c 99 87 c0 c7 03 04 99 
EIP: [] netif_rx+0x48/0xc0 SS:ESP 0068:c07bbef0
Kernel panic - not syncing: Fatal exception in interrupt

After this the system is frozen. Using kernel 2.6.21 everything works fine, I 
can capture packets in monitor mode and do not get any Oops.

Maxi


signature.asc
Description: This is a digitally signed message part.

Re: software suspend doesn't work with 2.6.22-rc3

[Maximilian Engelhardt]

On Saturday 26 May 2007, Nigel Cunningham wrote:
> Hi.
>
> On Sat, 2007-05-26 at 11:28 +0200, Maximilian Engelhardt wrote:
> > Hello,
> >
> > When I try software suspend on my laptop it always returns to my running
> > system after some time.
> > This is what's logged by the kernel:
> >
> > swsusp: Basic memory bitmaps created
> > Stopping tasks ...
> > Stopping kernel threads timed out after 20 seconds (1 tasks refusing to
> > freeze):
> >  cryptd
> > Restarting tasks ... done.
> > swsusp: Basic memory bitmaps freed
> >
> > I have no idea what's the problem, but if you tell me what I should do I
> > can create debugging information and/or test patches.
>
> Could you try this patch, please? It should help.
>
> Herbert, is this right? If cryptd is going to be used for block devs,
> the task should probably be PF_NOFREEZE (or whatever it is today)
> instead.
>
> Regards,
>
> Nigel
>
>  crypto/cryptd.c |1 +
>  include/linux/freezer.h |3 +++
>  kernel/power/process.c  |2 +-
>  3 files changed, 5 insertions(+), 1 deletion(-)
> diff -ruNp 991-fix-cryptd.patch-old/crypto/cryptd.c
> 991-fix-cryptd.patch-new/crypto/cryptd.c ---
> 991-fix-cryptd.patch-old/crypto/cryptd.c  2007-05-19 18:16:47.0
> +1000 +++ 991-fix-cryptd.patch-new/crypto/cryptd.c2007-05-26
> 19:45:42.0 +1000 @@ -341,6 +341,7 @@ static int cryptd_thread(void
> *data)
>
>   mutex_unlock(&state->mutex);
>
> + try_to_freeze();
>   schedule();
>   } while (!stop);

I tried your patch, but when I apply it my kernel doesn't compile any more. I 
get these warnings/errors:

[...]
  CC  crypto/cryptd.o
crypto/cryptd.c: In function ‘cryptd_thread’:
crypto/cryptd.c:344: warning: implicit declaration of function ‘try_to_freeze’
[...]
  LD  init/built-in.o
  LD  .tmp_vmlinux1
crypto/built-in.o: In function `cryptd_thread':
cryptd.c:(.text+0xd7f5): undefined reference to `try_to_freeze'
make: *** [.tmp_vmlinux1] Error 1

Maxi


signature.asc
Description: This is a digitally signed message part.

epoll,threading

[Arunachalam]

Hello all,

I want to know in detail about , what the events (epoll or /dev/poll or
select ) achieve in contrast to  thread per client.

i can have a thread per client and use send and recv system call directly
right? Why do i go for these event mechanisms?

Please help me to understand this.


Thanks in advance,
Arunachalam
-- 
View this message in context: 
http://www.nabble.com/epoll%2Cthreading-tf3820388.html#a10815949
Sent from the linux-kernel mailing list archive at Nabble.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: epoll,threading

[Ingo Oeser]

Hi Arunachalam,

On Saturday 26 May 2007, Arunachalam wrote:
> I want to know in detail about , what the events (epoll or /dev/poll or
> select ) achieve in contrast to  thread per client.
> 
> i can have a thread per client and use send and recv system call directly
> right? Why do i go for these event mechanisms?

Try 30.000 clients or more on a x86 32bit box. 
That will show you the difference quite nicely :-)

More seriously: Thread per client scales only to a certain amount of clients
per RAM. If you like to scale beyond that to like to minimize your 
state 
per client. If you have a thread then you have a task structure as 
unswappable memory in kernel, a per-thread stack, which is reducing 
your virtual memory per process (you have only around 3GB of virtual 
memory per process in Linux x86 32bit).

So one uses a process or thread pool to scale beyond that. 
Pool size is typically related to the amount of CPU cores in the system.

Regards

Ingo Oeser

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: [2/3] 2.6.22-rc2: known regressions v2

[Matt Sealey]

Chris Newport wrote:
> 
> Sorry, I did not make myself clear.
> 
> Linus Torvalds wrote:
> 
>> On Fri, 25 May 2007, Chris Newport wrote:
>>  
>>
>>> Maybe we should take a hint from Solaris.
>>>   
>>
>> No. Solaris is shit. They make their decisions based on "we control
>> the hardware" kind of setup.
>>  
>>
> Not really a Solaris feature. This is a feature of the  Openboot  PROM
> which is also used by several other vendors.
> The Openboot PROM knows how to write to disk. The same should
> apply on Apple hardware and others which use the openboot
> convention.

It doesn't, though. It is not part of any specification of Open Firmware
that you MUST be able to write to any exposed disk. In fact, I know of
one firmware implementation (ours) where we don't allow it. Apart from
being a bitch to implement safely (i.e. for people's data) it is also
quite a security problem to allow the firmware interface to write to
the disk. You can't make the differentiation between "at the firmware
console" and "inside a booted OS" unfortunately.

The 'solution' in Solaris is actually that the filesystem and disk
write handling is done by the OS bootloader and not the PROM. All
the PROM knows how to do is read off the bootloader (in a special
partition in a special filesystem format) and execute it after
probing the hardware and providing the device tree. The first stage
boot loader then knows how to read UFS filesystems so it can grab
the kernel and load kernel modules, and write back a kernel dump
if it needs to.

That, and Linux drops OF support like a lead weight very early in boot.
About all you can rely on is the device tree listing all your disks
present, and even then, Linux will redetect all of these with native
drivers and give them new names anyway. In fact, Solaris does the
same (but it is better about associating the device tree entries
than Linux)

-- 
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 - 97% wait time on IDE operations

[Tommy Vercetti]

Hi folks, 

I was trying to get answer to my question around, but no one knows.
I do have DMA turned on, etc, yet - on extensive harddrive operations wait 
time is 90+% , which means that machine is waiting, rather than doing 
something meanwhile. (I guess). 
Can someone describe to me , in more detail why is that happening, and what 
steps should I consider to avoid it ? I couldn't find any answers that would 
have help me on net.

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

[Alan Cox]

> As such, AA can detect whether you did exec("gzip") or exec("gunzip")
> and apply the policy relevant to the program. It could apply different

That's not actually useful for programs which link the same binary to
multiple names because if you don't consider argv[0] as well I can run
/usr/bin/gzip passing argv[0] of "gunzip" and get one set of policies and
the other set of behaviour.

And then we have user added hardlinks of course.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] MIPS: Transform old-style macros to newer "__noreturn" standard.

[Robert P. J. Day]

On Fri, 25 May 2007, H. Peter Anvin wrote:

> Robert P. J. Day wrote:
> >
> >
> >   f() __attribute__((noreturn)) ;
> >
> > you get:
> >
> >   warning: data definition has no type or storage class
> >
> > but gcc doesn't complain if you declare it thusly:
> >
> >   __attribute__((noreturn)) f() ;
> >
> > that strikes me as a flaw in gcc, no?
> >
>
> Doesn't matter.  gcc accepts "void __attribute__((noreturn)) f();", and
> thus, one can define:
>
> #define __noreturn void __attribute__((noreturn))
>
> ... and declare functions as:
>
> __noreturn f();
>
> ... which is the syntactially sane way of doing it.

i've thought about this and, while i philosophically agree with you,
i'm not going down that road for a couple reasons.

first, there is the fact that there is already a macro definition for
__noreturn in include/linux/compiler-gcc.h:

#define __noreturn  __attribute__((noreturn))

second, and more importantly, defining __noreturn as you suggest is
now mixing two fundamental pieces of information.  "void" is a return
type, plain and simple.  an attribute, OTOH, as i read it, is more of
a suggestion to the compiler to allow better checking of your code
and, based on future compilers, it may not even be meaningful.

all of the short forms for attributes defined in compiler-gcc.h are
exactly that -- short forms.  by adding in a return type, you're
fundamentally changing the way that short cut can be used.

yes, i *know* that __noreturn makes the return type irrelevant.  but
even the gcc manual doesn't try to take that extra step:


A few standard library functions, such as abort and exit, cannot
return. GCC knows this automatically. Some programs define their own
functions that never return. You can declare them noreturn to tell the
compiler this fact. For example,



void fatal () __attribute__ ((noreturn));

void
fatal (...)
{
  ... /* Print error message. */ ...
  exit (1);
}

The noreturn keyword tells the compiler to assume that fatal cannot
return. It can then optimize without regard to what would happen if
fatal ever did return. This makes slightly better code. More
importantly, it helps avoid spurious warnings of uninitialized
variables.

Do not assume that registers saved by the calling function are
restored before calling the noreturn function.

It does not make sense for a noreturn function to have a return type
other than void.
^  
===

  so I'm just going to stick with the pattern that's been used so far.
i realize it offends your sense of syntactic sensibility, but it's
just not worth treating that one attribute so differently from the
rest of them.

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/

Re: Pass struct vfsmount to the inode_create LSM hook

[Andreas Gruenbacher]

On Saturday 26 May 2007 14:09, Tetsuo Handa wrote:
> Hello.
>
> Andreas Gruenbacher wrote:
> > > exec { "/usr/bin/gunzip" } "gzip", "-9", "some/file/to.gz";
> >
> > The above Perl code executes /usr/bin/gunzip and sets argv[0] to "gzip",
> > so this confirms that the value of argv[0] is arbitrary. Well great, we
> > already knew.
> >
> > AppArmor does not look at argv[0] for anything, and doing so would be
> > insane. So please don't jump to the wrong conclusions.
>
> I agree that argv[0] checking is different from pathname-based access
> control or label-based access control, but I want to say argv[0] checking
> is still needed.
>
> If you don't check argv[0], an attacker can request everything like
>
> exec { "/bin/ls" } "/sbin/busybox", "cat", "/etc/shadow";
> exec { "/bin/ls" } "/sbin/busybox", "rm", "/etc/shadow";
>
> if /bin/ls and /bin/cat and /bin/rm are hardlinks of /sbin/busybox (e.g.
> embedded systems).
>
> Therefore, TOMOYO Linux checks the combination of filename and argv[0]
> passed to execve().

So you are indeed trying to control the value of argv[0]? Well, good luck with 
that, but it's totally insane. You are guaranteed to break some applications. 
AppArmor is not going to go down that route.

If /bin/cat and /bin/rm are binaries or hardlinks to the same busybox binary 
(rather than symlinks), different profiles could be used for each of them. 
The cat profile could have no more than read access anywhere, so this would 
prevent it from removing files. That's an effective access control mechanism.

Conspiring with busybox in the kernel and making it do the right thing (and 
just that) at the application level is not an effective security mechanism: 
the kernel would still allow busybox to do anything, and there could be bugs 
in the application, busybox's calling convention could change to allow more 
than one command per invocation (e.g., ``cat /etc/shadow ; rm /etc/shadow''), 
etc.

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

Re: double exclamation (!!) suckage in the kernel

[Jan Engelhardt]

On May 25 2007 14:14, David Miller wrote:
>
>WHat is with multiple people asking about "!!" all of a
>sudden today?
>
>> Are all these occurrences merely the debris of
>> s/something/!notsomething/g kind of patches or is there some
>> dark, unknown C / gcc wizardry I have absolutely no clue of?
>
>"!!" is used in contexts where pointers might be being
>tested as well as plain integers, the "!!" turns a pointer
>into the equivalent integer boolean for testing.
>
>NULL pointers become 0
>non-NULL pointers become 1

Though,
if(!!ptr)
is effectively the same as
if(ptr)

!! is mostly used where non-zero values need to be mapped to 1.
Not so much in logic expressions (if,while,etc.) but in arithmetic
(who'd do that?).

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: 2.6.21.1 - 97% wait time on IDE operations

[Paolo Ornati]

On Sat, 26 May 2007 15:05:38 +0200
Tommy Vercetti <[EMAIL PROTECTED]> wrote:

> I was trying to get answer to my question around, but no one knows.
> I do have DMA turned on, etc, yet - on extensive harddrive operations wait 
> time is 90+% , which means that machine is waiting, rather than doing 
> something meanwhile. (I guess). 
> Can someone describe to me , in more detail why is that happening, and what 
> steps should I consider to avoid it ? I couldn't find any answers that would 
> have help me on net.

It means that the disk is slow and the CPU is fast... so while the disk
is busy seeking and reading data the CPU has nothing to do but wait for
it.

Idle == CPU has nothing to do
Waiting == CPU has nothing to do, but it will have as soon as the slow
disk (or whatever) delivers data


Anyway 97% is quite high... what CPU / Hard Disk do you have?

What kernel version?
I/O scheduler? (cat /sys/block/DEVICE/queue/scheduler)
Filesystem?

And what time of "operations" are you doing?

-- 
Paolo Ornati
Linux 2.6.22-rc3-cfs-v14-gf193016a on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: fix oprofile double free (was Re: Multiple free during oprofile unload)

[Chris Wright]

* Andi Kleen ([EMAIL PROTECTED]) wrote:
> 
> > And, in this case we're in luck.  It's not released in any -stable tree
> > yet (it's queued for the next release).  So there's plenty of time to
> > fix it up before next -stable release.
> > 
> > Something like below should fix it.
> 
> I already got a similar patch, but not tested yet.

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

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

[Andreas Gruenbacher]

On Saturday 26 May 2007 15:34, Alan Cox wrote:
> > As such, AA can detect whether you did exec("gzip") or exec("gunzip")
> > and apply the policy relevant to the program. It could apply different
>
> That's not actually useful for programs which link the same binary to
> multiple names because if you don't consider argv[0] as well I can run
> /usr/bin/gzip passing argv[0] of "gunzip" and get one set of policies and
> the other set of behaviour.

I partially agree. Taken together with the policy of the calling process, 
things suddenly start to make more sense though (even if gzip/gunzip don't 
make good examples): if only allowed to execute /usr/bin/gzip, the calling 
process can still get the gunzip behavior, but it will be bound by 
the /usr/bin/gzip policy.

Controlling the policy is what we really care about; this limits the allowed 
behavior. We cannot really control the behavior of an application anyway 
(think of bugs alone), but we can set the bounds for that behavior.

> And then we have user added hardlinks of course.

Yes, allowing confined processes to change what they are allowed to execute 
under a more permissive policy is not such a good idea.

Thanks,
Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.1 - 97% wait time on IDE operations

[Tommy Vercetti]

On Saturday 26 May 2007 15:52, Paolo Ornati wrote:
> On Sat, 26 May 2007 15:05:38 +0200
> It means that the disk is slow and the CPU is fast... so while the disk
> is busy seeking and reading data the CPU has nothing to do but wait for
> it.
>
> Idle == CPU has nothing to do
> Waiting == CPU has nothing to do, but it will have as soon as the slow
>   disk (or whatever) delivers data
mhm.

> Anyway 97% is quite high... what CPU / Hard Disk do you have?
Intel(R) Pentium(R) M processor 1400MHz
TOSHIBA MK8025GAS

> What kernel version?
2.6.21.1
> I/O scheduler? (cat /sys/block/DEVICE/queue/scheduler)
[EMAIL PROTECTED]:~$ cat /sys/block/hda/queue/scheduler
noop anticipatory deadline [cfq]

> Filesystem?
reiser3
> And what time of "operations" are you doing?
apt-get install, vmware

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

Re: [Bridge] [BUG] Dropping fragmented IP packets within VLAN frames on bridge

[Ingo Oeser]

On Saturday 26 May 2007, Patrick McHardy wrote:
> Adam Osuchowski wrote:
> > if (((skb->protocol == htons(ETH_P_IP) && skb->len > skb->dev->mtu) ||
> > (IS_VLAN_IP(skb) && skb->len > skb->dev->mtu - VLAN_HLEN)) &&
> > !skb_is_gso(skb))
> > return ip_fragment ...
> 
> 
> net/8021q ignores the VLAN header overhead, so we should probably do the
> same here for consistency. Using IS_VLAN_IP (and IS_PPPOE_IP for current
> -rc) looks fine, additionally we should probably also check for
> skb->nfct != NULL to make sure that at least without connection tracking
> the bridge doesn't perform fragmentation.

And could we separe the conditions for that into a static helper function
explaining each of these conditions? e.g. sth. like that:

static bool br_nf_need_fragment(struct sk_buff *skb)
{
/* Plain IP packet does not fit in MTU */
if (!(skb->protocol == htons(ETH_P_IP) && skb->len > skb->dev->mtu))
return true;

/* VLAN encapsulated IP packet does not fit in MTU */
if (IS_VLAN_IP(skb) && skb->len > skb->dev->mtu - VLAN_HLEN)
return true;

/* PPPoE encapsulated IP packet does not fit in MTU */
if (IS_PPPOE_IP(skb) && skb->len > skb->dev->mtu - PPPOE_SES_HLEN)
return true;

return false;
}

and then br_nf_dev_queue_xmit() becomes:

static int br_nf_dev_queue_xmit(struct sk_buff *skb)
{
if (br_nf_need_fragment(skb) &&  !skb_is_gso(skb))
return ip_fragment(skb, br_dev_queue_push_xmit);
else
return br_dev_queue_push_xmit(skb);
}

which is much more readable, more documented and doesn't contain a condition 
monster :-)

@Patrick: Could you check, wether the PPPoE case is correct?

What do you think? Should I submit a patch for that?


Best Regards

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

Re: BUG in 2.6.22-rc2-mm1: Parts of Alsa sound architecture broken

[Mauro Carvalho Chehab]

Em Sáb, 2007-05-26 às 12:51 +0200, Jan Engelhardt escreveu:
> On May 25 2007 23:33, Takashi Iwai wrote:
> >
> >Yeah, I'll check it again if reposted.  Jan, could you split ALSA
> >portins at the next time?
> 
> How much split? This time, I made four out of it.
> 
> >This will make testing and merging much
> >easier for me...
> >
> >But, above all, I'm not convinced much by that patch, especially
> >because it introduces new kconfigs just for menuconfig.
> >For example, CONFIG_SND_PCI_DRIVERS doesn't appear in any Makefiles.
> 
> Neither is/was CONFIG_DVB IIRC. The world does not stop turning just
> because there are now extra options. If you want the functionality
> of menuconfigs without introducing some variable to store their state,
> well, I think that's going to be a bigger kconf patch. (Just think of
> compatibility of the .config format.)

I suspect that kconf is not properly handing the newer way for
menuconfig. Maybe this is the same stuff that happened on ALSA.

We have some stuff like this:

menuconfig VIDEO_CAPTURE_DRIVERS
bool "Video capture adapters"
depends on VIDEO_DEV

if VIDEO_CAPTURE_DRIVERS

config VIDEO_VIVI
tristate "Virtual Video Driver"
depends on VIDEO_V4L2 && !SPARC32 && !SPARC64 && PCI
select VIDEO_BUF

endif #VIDEO_CAPTURE_DRIVERS

config VIDEO_BUF
depends on PCI
tristate

Before adding menuconfig, VIDEO_VIVI were dependent on VIDEO_DEV. After
the patch, what happens is that:
if 
VIDEO_DEV='m' and VIDEO_CAPTURE_DRIVERS='y' and VIDEO_VIVI='m'
then
VIDEO_BUF='y'

But, as video-buf is dependent on video-core (compiled as a module,
since VIDEO_DEV='m'), it is generating compilation errors.

To fix it, I needed to add an explicit dependency on VIDEO_VIVI (and
also on VIDEO_SAA7146_VV):

http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=5cd49ffd9004;style=gitweb

I didn't looked inside kconf, but it seems that it is not checking that,
as VIDEO_CAPTURE_DRIVERS depends on VIDEO_DEV, all drivers inside the
"if" should also depend on VIDEO_DEV.
 
Cheers,
Mauro

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.1 - 97% wait time on IDE operations

[Julio M. Merino Vidal]

On 26/05/2007, at 15:05, Tommy Vercetti wrote:


Hi folks,

I was trying to get answer to my question around, but no one knows.
I do have DMA turned on, etc, yet - on extensive harddrive  
operations wait

time is 90+% , which means that machine is waiting, rather than doing
something meanwhile. (I guess).
Can someone describe to me , in more detail why is that happening,  
and what
steps should I consider to avoid it ? I couldn't find any answers  
that would

have help me on net.


I see in your other post that you have a laptop disk drive and, based  
on its specs, it is a 4200RPM one.  Laptop drives are incredibly slow  
for random disk access -- I have one and hate it with passion... even  
though it is slightly better (5400RPM)...


You mention that you are doing expensive disk operations.  If these  
involve a lot of disk seeks (such as, for example, a "cvs update" on  
a large source tree), disk performance will be very very poor and any  
other operation you attempt on it will be slow as well.  These kind  
of drives are the major bottleneck of current laptop machines, in my  
opinion.


(I just wanted to make this clear wrt the hardware.  I do not know if  
Linux is also involved or not.)


--
Julio M. Merino Vidal <[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: Pass struct vfsmount to the inode_create LSM hook

[Tetsuo Handa]

Hello.

Andreas Gruenbacher wrote:
> > Therefore, TOMOYO Linux checks the combination of filename and argv[0]
> > passed to execve().
> So you are indeed trying to control the value of argv[0]? Well, good luck 
> with 
> that, but it's totally insane. You are guaranteed to break some applications.
TOMOYO Linux ristricts argv[0] using allow_argv0 syntax.
"allow_argv0 /bin/bash -bash" to allow passing "/bin/bash" to filename and 
"-bash" to argv[0] .
"allow_argv0 /bin/gzip gunzip" to allow passing "/bin/gzip" to filename and 
"gunzip" to argv[0] .
"allow_argv0 /sbin/busybox cat" to allow passing "/sbin/busybox" to filename 
and "cat" to argv[0] .
No need to use allow_argv0 syntax if the basename of filename and basename of 
argv[0] are the same
(i.e. "allow_argv0 /bin/bash bash" is not required).
TOMOYO Linux doesn't unconditionally forbid passing different values for 
filename and argv[0].
TOMOYO Linux allows passing different values for filename and argv[0] only if 
it is allowed by allow_argv0 syntax.
Could you please explain me why this approach breaks applications?

> If /bin/cat and /bin/rm are binaries or hardlinks to the same busybox binary 
> (rather than symlinks), different profiles could be used for each of them.
It is true if all processes are kept under control (e.g. strict policy in 
SELinux).
If there is a process that is not kept under control (e.g. targeted policy in 
SELinux),
you can't protect the application.
For example, an administrator may wish to allow users run /bin/ls without 
applying profiles
because /bin/ls won't read/write the content of files. But a malicious user may 
pass
"/bin/ls" to filename and "rm" to argv[0] and "/etc/shadow" to argv[1].
A malicious user may pass "/bin/ls" to filename and "/usr/sbin/httpd" to 
argv[0],
resulting behave as /usr/sbin/httpd without applying profiles for 
/usr/sbin/httpd .

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

[BUG] Warning in mm/slab.c:777

[Rolf Eike Beer]

After bootup (runlevel 5) I found this in dmesg:

WARNING: at mm/slab.c:777 __find_general_cachep()
 [] __kmalloc+0x40/0xc3
 [] drm_rmdraw+0x126/0x24e [drm]
 [] skb_dequeue+0x39/0x3f
 [] drm_rmdraw+0x0/0x24e [drm]
 [] drm_ioctl+0x14c/0x192 [drm]
 [] do_ioctl+0x4c/0x62
 [] vfs_ioctl+0x237/0x249
 [] mntput_no_expire+0x11/0x68
 [] sys_ioctl+0x4c/0x65
 [] sysenter_past_esp+0x5f/0x85
 ===

Kernel is Linus' git of yesterday, the first occurence of this in my logs was 
on May 16th.

Greetings,

Eike


signature.asc
Description: This is a digitally signed message part.

Re: [patch] CFS scheduler, -v14

[S.Çağlar Onur]

Hi Ingo;

23 May 2007 Çar tarihinde, Ingo Molnar şunları yazmıştı: 
> As usual, any sort of feedback, bugreport, fix and suggestion is more
> than welcome!

I have another kaffeine [0.8.4]/xine-lib [1.1.6] problem with CFS for you :)

Under load (compiling any Qt app. or kernel with -j1 or -j2) audio always goes 
sync with time (and i'm sure it never skips) but video starts slowdown and 
loses its sync with audio (like for the 10th sec. of a movie, audio is at 
10th sec. also, but the shown video is from 7th sec.). 

After some time video suddenly wants to sync with audio and starts to play 
really fast (like fast-forward) and syncs with audio. But it will lose its 
audio/video sync after a while and loop continues like that.

I also reproduced that behaviour with CFS-13, i'm not sure its reproducible 
with mainline cause for a long time i only use CFS (but i'm pretty sure that 
problem not exists or not hit me with CFS-1 to CFS-11). And its only 
reproducible with some load and mplayer plays same video without losing its 
audio/video sync with same load.

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

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


signature.asc
Description: This is a digitally signed message part.

Re: PCIE

[Manu Abraham]

Roland Dreier wrote:
>  > I am now wondering whether the usage of MSI would help in this case and
>  > that i should be using enable_msi before request_irq ?
> 
> MSI interrupts are never shared.  So if pci_enable_msi() succeeds, you
> can be sure that the interrupts you get with that IRQ number are
> coming from your device.
> 

i presume then i shouldn't be using IRQF_SHARED, if using MSI.

Another question would be if the device supports multiple messages, MSIX
should be used ?
In such a context, if i request for say more than the messages that i
need, say i request 16 messages, but use only 1 or 2, that does bear any
consequences ?

> But using MSI does not work on all systems, so your driver needs to
> work with standard (possibly shared) INTx interrupts too.  And you
> should probably provide at least a module flag to disable the use of
> MSI, to avoid problems on buggy systems.

I should probably look for CONFIG_PCI_MSI and check whether the system
supports MSI pci_enable_msi() ?

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

Re: [Bridge] [BUG] Dropping fragmented IP packets within VLAN frames on bridge

[Patrick McHardy]

Ingo Oeser wrote:
> On Saturday 26 May 2007, Patrick McHardy wrote:
> 
>>net/8021q ignores the VLAN header overhead, so we should probably do the
>>same here for consistency. Using IS_VLAN_IP (and IS_PPPOE_IP for current
>>-rc) looks fine, additionally we should probably also check for
>>skb->nfct != NULL to make sure that at least without connection tracking
>>the bridge doesn't perform fragmentation.
> 
> 
> And could we separe the conditions for that into a static helper function
> explaining each of these conditions? e.g. sth. like that:


The MTU checks are self-explanatory. Just a comment above the function
stating that it tries to find out whether a packet needs to be
refragmented because it was defragmented by IPv4 connection tracking
and exceeds the MTU should be enough.

> static bool br_nf_need_fragment(struct sk_buff *skb)
> {
>   /* Plain IP packet does not fit in MTU */
>   if (!(skb->protocol == htons(ETH_P_IP) && skb->len > skb->dev->mtu))
>   return true;
> 
>   /* VLAN encapsulated IP packet does not fit in MTU */
>   if (IS_VLAN_IP(skb) && skb->len > skb->dev->mtu - VLAN_HLEN)
>   return true;
> 
>   /* PPPoE encapsulated IP packet does not fit in MTU */
>   if (IS_PPPOE_IP(skb) && skb->len > skb->dev->mtu - PPPOE_SES_HLEN)
>   return true;
> 
>   return false;
> }


As I said, I don't think we should account for the VLAN header overhead,
the VLAN code itself doesn't even do it. And we should exclude packets
that don't have a connection tracking reference attached since we are
only undoing the damage connection tracking did by defragmenting it
and should avoid fragmenting other packets as good as possible.

> and then br_nf_dev_queue_xmit() becomes:
> 
> static int br_nf_dev_queue_xmit(struct sk_buff *skb)
> {
> if (br_nf_need_fragment(skb) &&  !skb_is_gso(skb))
> return ip_fragment(skb, br_dev_queue_push_xmit);
> else
> return br_dev_queue_push_xmit(skb);
> }
> 
> which is much more readable, more documented and doesn't contain a condition 
> monster :-)
> 
> @Patrick: Could you check, wether the PPPoE case is correct?


It looks OK. But there is another problem, ip_fragment doesn't care
about the PPPoE overhead and produces a packet that will be too large
after restoring the PPPoE header. A second __fake_rtable that accounts
for the PPPoE overhead could probably fix that ..

> What do you think? Should I submit a patch for that?


Sure :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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, -v14

[S.Çağlar Onur]

26 May 2007 Cts tarihinde, S.Çağlar Onur şunları yazmıştı: 
> 23 May 2007 Çar tarihinde, Ingo Molnar şunları yazmıştı:
> > As usual, any sort of feedback, bugreport, fix and suggestion is more
> > than welcome!
>
> I have another kaffeine [0.8.4]/xine-lib [1.1.6] problem with CFS for you
> :)
>
> Under load (compiling any Qt app. or kernel with -j1 or -j2) audio always
> goes sync with time (and i'm sure it never skips) but video starts slowdown
> and loses its sync with audio (like for the 10th sec. of a movie, audio is
> at 10th sec. also, but the shown video is from 7th sec.).
>
> After some time video suddenly wants to sync with audio and starts to play
> really fast (like fast-forward) and syncs with audio. But it will lose its
> audio/video sync after a while and loop continues like that.
>
> I also reproduced that behaviour with CFS-13, i'm not sure its reproducible
> with mainline cause for a long time i only use CFS (but i'm pretty sure
> that problem not exists or not hit me with CFS-1 to CFS-11). And its only
> reproducible with some load and mplayer plays same video without losing its
> audio/video sync with same load.

Ah, i forgot to add you can find the "strace -o kaffine.log -f -tttTTT 
kaffeine" and ps output while that problem exists at [1]

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

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


signature.asc
Description: This is a digitally signed message part.

Re: 2.6.21.1 - 97% wait time on IDE operations

[Ray Lee]

On 5/26/07, Tommy Vercetti <[EMAIL PROTECTED]> wrote:

I was trying to get answer to my question around, but no one knows.
I do have DMA turned on, etc, yet - on extensive harddrive operations wait


You may have DMA turned on, but it may be ineffectual if you don't
have the right IDE driver handing your disk.


time is 90+% , which means that machine is waiting, rather than doing
something meanwhile. (I guess).


What does hdparm -tT /dev/hda say? If the numbers are reasonable
(~400MB/s for cache reads, ~25MB/s for buffered disk reads), then
you're just doing a lot of seeking on the drive, and that takes a long
time. (Drives can seek about 100 times a second. If every seek reads
only 4k of data, that's 400k of data processed per second, or a lot of
time spent with the CPU waiting on I/O.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21.1 - 97% wait time on IDE operations

[Guillaume Chazarain]

Hi,


wait time is 90+% , which means that machine is waiting, rather than doing
something meanwhile. (I guess).


Yes, the machine spends its time waiting for the disk to do its things
as it does not have anything else to do. Nothing to worry about. If
you want, launch some CPU bound process at the same time and the wait
time will be replaced by some user+system time but you'll gain
nothing.

Hope this helps.

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

Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)

[Michael Buesch]

On Saturday 26 May 2007 12:40:54 Uwe Bugla wrote:
> Yes! This sort of mistakes is completely impossible, as I use to work with 
> aliases rather than IP adresses. The machine I tried to ping (i. e. my 
> router) is called Jerry (as a reminiscence to Mr. "Captan Trips" from 
> Grateful Dead), and thus "ping jerry" returned the following:
> 
> "destination host unreachable"
> 
> Above that, I state for the second time now that I reverted your patches in 
> 2.6.22-rc2-mm1 with the effect that everything worked perfectly!
> Maxi said something at least similar. So how many proofs do you need, Mister 
> Buesch, to finally pick up patchworking now?? 

How about you stopping with your fucking aggressive wording??

> > Try it again, please.
> 
> NO!
> 
> > And please try with current wireless-dev tree.
> 
> A. I do not know where to download that wireless-dev tree.
> B. I do not know how to implement it into mm or mainline
> C. I have given enough sophisticated proof that your stuff in mm-tree is 
> highly incomplete / buggy.

Ok,

D. As you are not going to help me debugging, I am not going to fix.

> >
> > And I simply do not get it why you suddenly get a good IRQ number, like
> > everybody else does, without fixing The Bug (tm).
> 
> That consequence I already explained:
> But it's a pleasure for me to repeat it once more:
> 
> When you are saying Y to "EISA, VLB, PCI and on board controllers"
> 
> you simply do get not only completely different interrupts for the b4401 
> device, but you get also completely different module dependencies.

That is EXPECTED and I already explained that.
It is a feature. Not a bug.


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

[2.6.21.1] soft lockup when removing netconsole module

[Folkert van Heusden]

Hi,

When trying to remove the netconsole module, I got the following kernel
output after a while (couple of minutes iirc):

[525720.117293] BUG: soft lockup detected on CPU#1!
[525720.117353]  [] show_trace_log_lvl+0x1a/0x30
[525720.117439]  [] show_trace+0x12/0x14
[525720.117526]  [] dump_stack+0x16/0x18
[525720.117613]  [] softlockup_tick+0xa6/0xc2
[525720.117694]  [] run_local_timers+0x12/0x14
[525720.117738]  [] update_process_times+0x72/0xa1
[525720.117744]  [] tick_sched_timer+0x53/0xb6
[525720.117748]  [] hrtimer_interrupt+0x189/0x1e3
[525720.117753]  [] local_apic_timer_interrupt+0x55/0x5b
[525720.117761]  [] smp_apic_timer_interrupt+0x2a/0x39
[525720.117766]  [] apic_timer_interrupt+0x33/0x38
[525720.117770]  [] mutex_lock+0x8/0xa
[525720.117775]  [] flush_workqueue+0x2f/0x8f
[525720.117780]  [] cancel_rearming_delayed_workqueue+0x29/0x2b
[525720.117785]  [] cancel_rearming_delayed_work+0xf/0x11
[525720.117790]  [] netpoll_cleanup+0x75/0xa5
[525720.117794]  [] cleanup_netconsole+0x17/0x1a [netconsole]
[525720.117804]  [] sys_delete_module+0x12f/0x14f
[525720.117809]  [] syscall_call+0x7/0xb
[525720.117812]  ===

Also the rmmod hangs and would not exit even with kill -9. It also
sucks up 100% cpu.


Folkert van Heusden

-- 
MultiTail es una herramienta flexibele para consiguir archivos de log,
y para ejecutar ordenes. Filtrar, añadir colores, merger y vista de
las differencias.  http://www.vanheusden.com/multitail/
--
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: [ckrm-tech] [RFC] [PATCH 0/3] Add group fairness to CFS

[William Lee Irwin III]

Srivatsa Vaddagiri wrote:
>> Ingo/Peter, any thoughts here?  CFS and smpnice probably is "broken" 
>> with respect to such example as above albeit for nice-based tasks.

On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
> See above.  I think that faced with cpu affinity use by the system 
> administrator that smpnice will tend towards a task to cpu allocation 
> that is (close to) the best that can be achieved without violating the 
> cpu affinity assignments.  (It may take a little longer than normal but 
> it should get there eventually.)
> You have to assume that the system administrator knows what (s)he's 
> doing and is willing to accept the impact of their policy decision on 
> the overall system performance.
> Having said that, if it was deemed necessary you could probably increase 
> the speed at which the load balancer converged on a good result in the 
> face of cpu affinity by keeping a "pinned weighted load" value for each 
> run queue and using that to modify find_busiest_group() and 
> find_busiest_queue() to be a bit smarter.   But I'm not sure that it 
> would be worth the added complexity.

Just in case anyone was looking for algorithms...

Lag should be considered in lieu of load because lag is what the
scheduler is trying to minimize; load is not directly relevant, but
appears to have some sort of relationship. Also, instead of pinned,
unpinned should be considered. It's unpinned that load balancing can
actually migrate. Using the signed minimax pseudonorm (i.e. the highest
signed lag, where positive is higher than all negative regardless of
magnitude) on unpinned lags yields a rather natural load balancing
algorithm consisting of migrating from highest to lowest signed lag,
with progressively longer periods for periodic balancing across
progressively higher levels of hierarchy in sched_domains etc. as usual.
Basically skip over pinned tasks as far as lag goes.

The trick with all that comes when tasks are pinned within a set of
cpus (especially crossing sched_domains) instead of to a single cpu.
There one can just consider a cpu to enter a periodic load balance
cycle, and then consider pushing and pulling, perhaps what could be
called the "exchange lags" for the pair of cpus. That would be the
minimax lag pseudonorms for the tasks migratable to both cpus of the
pair. That makes the notion of moving things from highest to lowest
lag (where load is now considered) unambiguous apart from whether all
this converges, but not when to actually try to load balance vs. when
not to, or when it's urgent vs. when it should be done periodically.

To clarify that, an O(cpus**2) notion appears to be necessary, namely
the largest exchange lag differential between any pair of cpus. There
is also the open question of whether moving tasks between cpus with the
highest exchange lag differential will actually reduce it or whether it
runs the risk of increasing it by creating a larger exchange lag
differential between different pairs of cpus. A similar open question
is raised by localizing balancing decisions to sched_domains. What
remains clear is that any such movement reduces the worst-case lag in
the whole system. Because of that, the worst-case lag in the whole
system monotonically decreases as balancing decisions are made, and
that much is subject to an infinite descent argument. Unfortunately,
determining the largest exchange lag differential appears to be more
complex than merely finding the highest and lowest lags. Bipartite
forms of the problem also arise from sched_domains.

I doubt anyone's really paying any sort of attention, so I'll not
really bother working out much more in the way of details with respect
to load balancing. It may be that there are better ways to communicate
algorithmic notions than prose descriptions. However, it's doubtful I'll
produce anything in a timely enough fashion to attract or hold interest.

The smpnice affair is better phrased in terms of task weighting. It's
simple to honor nice in such an arrangement. First unravel the
grouping hierarchy, then weight by nice. This looks like

tasknicehier1   hier2   ... hierN
t_1 w_n1w_h11   w_h21   ... w_hN1
t_2 w_n2w_h12   w_h22   ... w_hN2
...

For the example of nice 0 vs. nice 10 as distinct users with 10%
steppings between nice levels, one would have

tasknice   hier1
t_1 1  1
t_2 0.3855 1

w_1, the weight of t_1, would be
(w_h11*w_n1/(w_h11*w_n1 + w_h12*w_n2))
= (1*1/(1 + 1*0.3855..))
= 0.7217..
w_2, the weight of t_2, would be
(w_h12*w_n2/(w_h11*w_n1 + w_h12*w_n2))
= (1*0.3855../(1 + 1*0.3855..))
= 0.27826..
This just so happens to work out to being the same as if t_1 and t_2
had their respective nice numbers without the scheduler grouping, which
is basically what everyone wants to happen.

It's more obvious how to extend it to more tasks than levels of
hierarchy. An example of 

Re: 2.6.21.1 - 97% wait time on IDE operations

[Tommy Vercetti]

in terms of driver, what do you mean ?
this is my lspci:
00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller 
(rev 21)
00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 
21)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) 
USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) 
USB UHCI Controller #2 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI 
Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge 
(rev 03)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 
03)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM 
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 
Modem Controller (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation NV34M [GeForce FX 
Go5200] (rev a1)
02:07.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 
Controller (PHY/Link)
02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (MOB) 
Ethernet Controller (rev 83)
02:0a.0 Network controller: Intel Corporation PRO/Wireless LAN 2100 3B Mini 
PCI Adapter (rev 04)
02:0b.0 CardBus bridge: Toshiba America Info Systems ToPIC100 PCI to Cardbus 
Bridge with ZV Support (rev 33)
02:0d.0 System peripheral: Toshiba America Info Systems SD TypA Controller 
(rev 05)
03:00.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC 
(rev 01)


modules list, and config on request (don't want to pollute devs mailboxes).

/dev/hda:
 Timing cached reads:   732 MB in  2.00 seconds = 365.74 MB/sec
 Timing buffered disk reads:   76 MB in  3.00 seconds =  25.31 MB/sec
[EMAIL PROTECTED]:~# htparm -i -v /dev/hda
-su: htparm: command not found
[EMAIL PROTECTED]:~# hdparm -i -v /dev/hda

/dev/hda:
 multcount= 16 (on)
 IO_support   =  0 (default 16-bit)
 unmaskirq=  0 (off)
 using_dma=  1 (on)
 keepsettings =  0 (off)
 readonly =  0 (off)
 readahead= 256 (on)
 geometry = 65535/16/63, sectors = 156301488, start = 0

 Model=TOSHIBA MK8025GAS, FwRev=KA023A, SerialNo=95NX6153S
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=48
 BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma3 udma4 *udma5
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 
ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6

 * signifies the current active mode




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

Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)

[Michael Buesch]

Andrew,

I am going to ignore Uwe from now on. It's simply impossible
to debug the problem the way he is responding.
Well, I'm not the first person in the Linux community adding
him to the killfile, ... .
I ask to try wireless-dev, as the driver works perfectly fine
for me there, but he refuses to try it, too. So I'm stuck.
I already tried your -mm kernel, but it crashes on my machine
for other reasons. (Yeah, I should look into them, too :P )

Andrew, is it possible that the breakage was introduced in the
merge process somehow? Didn't the patch apply cleanly? Are there
other changes to b44 I should know about in your tree?

If it is really impossible to debug this problem, I'd like to
suggest you to drop the b44-ssb port completely.
I'm not going to destroy my nerves any further with guys like
Uwe, so I'll include the b44-ssb port in the OpenWRT tree
and be done with it.
Although I would be very sad about it, as my longterm goal was
to make a vanilla kernel run on the OpenWRT devices... .

But maybe we can get another tester for -mm with similiar problems,
who is not bullshitting the whole time and is also going to
test wireless-dev to make sure it's not a merge bug.


---

And Uwe: Remember, I am not payed for this. I do _all_ this
in my free time.
So sentences like: "So, the ball has been in your court
for two days now, and you simply keep on hesitating
to take action now."
are _completely_ displaced in this discussion.

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

Re: [2.6.21.1] soft lockup when removing netconsole module

[Parag Warudkar]

Seems to be hrtimers related - CC'ed Thomas.

Parag

Folkert van Heusden wrote:

Hi,

When trying to remove the netconsole module, I got the following kernel
output after a while (couple of minutes iirc):

[525720.117293] BUG: soft lockup detected on CPU#1!
[525720.117353]  [] show_trace_log_lvl+0x1a/0x30
[525720.117439]  [] show_trace+0x12/0x14
[525720.117526]  [] dump_stack+0x16/0x18
[525720.117613]  [] softlockup_tick+0xa6/0xc2
[525720.117694]  [] run_local_timers+0x12/0x14
[525720.117738]  [] update_process_times+0x72/0xa1
[525720.117744]  [] tick_sched_timer+0x53/0xb6
[525720.117748]  [] hrtimer_interrupt+0x189/0x1e3
[525720.117753]  [] local_apic_timer_interrupt+0x55/0x5b
[525720.117761]  [] smp_apic_timer_interrupt+0x2a/0x39
[525720.117766]  [] apic_timer_interrupt+0x33/0x38
[525720.117770]  [] mutex_lock+0x8/0xa
[525720.117775]  [] flush_workqueue+0x2f/0x8f
[525720.117780]  [] cancel_rearming_delayed_workqueue+0x29/0x2b
[525720.117785]  [] cancel_rearming_delayed_work+0xf/0x11
[525720.117790]  [] netpoll_cleanup+0x75/0xa5
[525720.117794]  [] cleanup_netconsole+0x17/0x1a [netconsole]
[525720.117804]  [] sys_delete_module+0x12f/0x14f
[525720.117809]  [] syscall_call+0x7/0xb
[525720.117812]  ===

Also the rmmod hangs and would not exit even with kill -9. It also
sucks up 100% cpu.


Folkert van Heusden



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-rc2-mm1

[Tilman Schmidt]

Am 23.05.2007 09:42 schrieb Andrew Morton:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/

This breaks network initialization on my SuSE 10.0 box once
again although I compiled with CONFIG_SYSFS_DEPRECATED=y.
Acquisition of the IP address via DHCP times out.
Manual start (rcnetwork restart) doesn't help either.

I'll start bisecting as soon as the machine is free.

-- 
Tilman Schmidt  E-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)



signature.asc
Description: OpenPGP digital signature

Re: 2.6.21.1 - 97% wait time on IDE operations

[Paolo Ornati]

On Sat, 26 May 2007 16:07:49 +0200
Tommy Vercetti <[EMAIL PROTECTED]> wrote:

> > Anyway 97% is quite high... what CPU / Hard Disk do you have?  
> Intel(R) Pentium(R) M processor 1400MHz
> TOSHIBA MK8025GAS
> 
> > What kernel version?  
> 2.6.21.1
> > I/O scheduler? (cat /sys/block/DEVICE/queue/scheduler)  
> [EMAIL PROTECTED]:~$ cat /sys/block/hda/queue/scheduler
> noop anticipatory deadline [cfq]
> 
> > Filesystem?  
> reiser3
> > And what time of "operations" are you doing?  
> apt-get install, vmware

It's probably just a slow disk... try hdparm as suggested by Ray and
see if they look sane (PS: just seen the numbers and looks sane to me).

If they are and you need more performance buy a better HD :)

Improvements from kernel side are possible but don't expect too much.


Things to check/try:

1) FS: is it in good shape? Or is it full and fragmented?

2) FS mount options, try adding everything that can reduce accesses
(noatime, nodiratime)

3) try experimental patches such as Adaptive Readahead, it seems to
help some workload (it was there in older -mm, now there's a much
simplier readahead replacement in 2.6.22-rc2-mm1 called "on-demand
readahead", maybe that helps too?)

-- 
Paolo Ornati
Linux 2.6.22-rc3-cfs-v14-gf193016a on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)

[Uwe Bugla]

Am Samstag, 26. Mai 2007 17:36 schrieben Sie:
> On Saturday 26 May 2007 12:40:54 Uwe Bugla wrote:
> > Yes! This sort of mistakes is completely impossible, as I use to work
> > with aliases rather than IP adresses. The machine I tried to ping (i. e.
> > my router) is called Jerry (as a reminiscence to Mr. "Captan Trips" from
> > Grateful Dead), and thus "ping jerry" returned the following:
> >
> > "destination host unreachable"
> >
> > Above that, I state for the second time now that I reverted your patches
> > in 2.6.22-rc2-mm1 with the effect that everything worked perfectly! Maxi
> > said something at least similar. So how many proofs do you need, Mister
> > Buesch, to finally pick up patchworking now??
>
> How about you stopping with your fucking aggressive wording??

If you stop repeating that you are not responsible for that buggy stuff then I 
will be friendlier. That's all.
So calm down and provide me some parametres to debug.
I will be cooperative and we're gonna fix it for sure, OK?

>
> > > Try it again, please.
> >
> > NO!
> >
> > > And please try with current wireless-dev tree.
> >
> > A. I do not know where to download that wireless-dev tree.
> > B. I do not know how to implement it into mm or mainline
> > C. I have given enough sophisticated proof that your stuff in mm-tree is
> > highly incomplete / buggy.
>
> Ok,
>
> D. As you are not going to help me debugging, I am not going to fix.

First of all, I need debugging parametres for both modules (b44 and ssb).
Second, I need to know which log you need after using those debug parametres.

This is the only chance to move forward, isn't it?

>
> > > And I simply do not get it why you suddenly get a good IRQ number, like
> > > everybody else does, without fixing The Bug (tm).
> >
> > That consequence I already explained:
> > But it's a pleasure for me to repeat it once more:
> >
> > When you are saying Y to "EISA, VLB, PCI and on board controllers"
> >
> > you simply do get not only completely different interrupts for the b4401
> > device, but you get also completely different module dependencies.
>
> That is EXPECTED and I already explained that.
> It is a feature. Not a bug.

Yes. But the features / extensions / different cases of b44 usage need to be 
explained in some small Kconfig text, making it easy for users to put the 
right selection for their specific NIC controller. But exactly this Kconfig 
leaves you in the dark. That's it what I critizise, nothing else. Just try to 
see through my eyes: Who would be happy with guessing around? Noone.

Cheers

Uwe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-rc2-mm1

[Andrew Morton]

On Sat, 26 May 2007 17:59:15 +0200 Tilman Schmidt <[EMAIL PROTECTED]> wrote:

> Am 23.05.2007 09:42 schrieb Andrew Morton:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
> 
> This breaks network initialization on my SuSE 10.0 box once
> again although I compiled with CONFIG_SYSFS_DEPRECATED=y.
> Acquisition of the IP address via DHCP times out.
> Manual start (rcnetwork restart) doesn't help either.
> 
> I'll start bisecting as soon as the machine is free.

Thanks.  I think others have seen similar things and it was attributed to
driver-core-check-return-code-of-sysfs_create_link.patch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: fix section mismatch warnings in mtrr

[Andi Kleen]

On Saturday 26 May 2007 14:07:24 Indan Zupancic wrote:

> 
> Did the patches reach 2.6.22-rc3 yet?

No.

> 
> If they did, then the following warnings might need fixing:

There is already one patch queued for it. But actually in my experience I cannot
remember a single real bug showed by these warnings. All were false positives
and there are always more of them.

Maybe it would be best to disable these warnings again; not much good 
seems to come from them.

-Andi

> WARNING: arch/i386/kernel/built-in.o(.text+0x84bc): Section mismatch: 
> reference to
>.init.text:amd_init_mtrr (between 'mtrr_bp_init' and 'mtrr_attrib_to_str')
>WARNING: arch/i386/kernel/built-in.o(.text+0x84c1): Section mismatch: 
>reference to
>.init.text:cyrix_init_mtrr (between 'mtrr_bp_init' and 'mtrr_attrib_to_str')
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.1 - 97% wait time on IDE operations

[Ray Lee]

On 5/26/07, Tommy Vercetti <[EMAIL PROTECTED]> wrote:

in terms of driver, what do you mean ?


The software driver that handles the specific chipset for that drive.
The thing that shows up when you do an lsmod, assuming you have the
driver compiled as a module.


/dev/hda:
 Timing cached reads:   732 MB in  2.00 seconds = 365.74 MB/sec
 Timing buffered disk reads:   76 MB in  3.00 seconds =  25.31 MB/sec


That looks fine. Your filesystem may just be very fragmented. I'm not
familiar with how reiser3 filesystems age, so if you've had the system
installed for quite some time, it may be time to back it up and
reinstall. Dunno.

All of Paolo's suggestions look good, BTW. Sorry I couldn't be more help.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-rt2..8 troubles

[Thomas Gleixner]

On Fri, 2007-05-25 at 21:58 +0100, Rui Nuno Capela wrote:
> Is there anything I can do better to help myself figuring out this
> issue? As this is a  modern laptop such things like a serial console are
> unavailable, but it would be nice to track things up over netconsole
> perhaps?
> 
> I just need some bright and nice directions now ;) Hope someone finds
> this worth of attention too. Meanwhile, I'll be happy with 2.6.21-rt1 :)

Can you boot with "hpet=disable" on the command line ?

If that does not help, please provide the output of /proc/timer_list.

Thanks,

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: Race free attributes in sysfs

[Bill Davidsen]

Greg KH wrote:

On Wed, May 23, 2007 at 09:27:12AM -0400, Mark Lord wrote:

 Greg KH wrote:

And yes, it only starts to look for things when it recieves an event, it
does not "scan" sysfs at all.

 Does it "look for" only that one event, or does it "scan" at that point?


udev will act on that event, and as I mentioned, not read anything from
sysfs at all, unless a custom rule is in the rules file asking it to
read a specific sysfs file in the tree.

So no "scanning" happens unless specificically asked for.

And as mentioned, udev can work just fine without sysfs enabled at all
now, with the exception of some custom rules for some devices.

I think what Mark is asking is about the case where udev gets an event, 
is told to look in sysfs, and while looking encounters a partially 
described device.


Now that the "this won't happen unless..." cases, could someone cover 
this and state that it either can't happen because {reason} or that if 
it does the result will be {description}.


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.1] soft lockup when removing netconsole module

[Thomas Gleixner]

On Sat, 2007-05-26 at 11:53 -0400, Parag Warudkar wrote:
> Seems to be hrtimers related - CC'ed Thomas.

I doubt that. The tick interrupt just finds out, that the machine is
stuck in rmmod.

> > Also the rmmod hangs and would not exit even with kill -9. It also
> > sucks up 100% cpu.

Can you please enable CONFIG_PROVE_LOCKING ?

Thanks,

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: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)

[Andrew Morton]

On Sat, 26 May 2007 17:50:48 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote:

> Andrew,
> 
> I am going to ignore Uwe from now on. It's simply impossible
> to debug the problem the way he is responding.
> Well, I'm not the first person in the Linux community adding
> him to the killfile, ... .

Well yes, there are some personality issues here ;) But the main thing is
to struggle on and fix this bug, wherever it lies.

> I ask to try wireless-dev, as the driver works perfectly fine
> for me there, but he refuses to try it, too. So I'm stuck.

I don't think he knows how to obtain it.

Uwe, http://userweb.kernel.org/~akpm/git-wireless.patch.gz is the current
wireless tree.  That's a patch against 2.6.22-rc3.  Could you please test
that?  If that works then we know that the bug probably lies outside the
b44 driver (or it was subsequently fixed).

> I already tried your -mm kernel, but it crashes on my machine
> for other reasons. (Yeah, I should look into them, too :P )

err, please do.  Just the oops trace would be a start.

> Andrew, is it possible that the breakage was introduced in the
> merge process somehow? Didn't the patch apply cleanly? Are there
> other changes to b44 I should know about in your tree?

Only git-wireless.net modifies b44.c but if we're having IRQ assignment
problems then we'd need to look elsewhere.  I guess you could diff
rc2-mm1's b44.c against the expected version.


> If it is really impossible to debug this problem, I'd like to
> suggest you to drop the b44-ssb port completely.

Well we don't know if that'll fix it.

I believe that Uwe said that reverting the b44.c changes from rc2-mm1 fixes
things for him?  Odd, but it still doesn't rule out acip/pci/platform
changes as being the cause.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.1] soft lockup when removing netconsole module

[Folkert van Heusden]

> > Seems to be hrtimers related - CC'ed Thomas.
> I doubt that. The tick interrupt just finds out, that the machine is
> stuck in rmmod.
> > > Also the rmmod hangs and would not exit even with kill -9. It also
> > > sucks up 100% cpu.
> Can you please enable CONFIG_PROVE_LOCKING ?

Luckily I already had :-)
Here is its output:

[   44.500182] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., 
Ingo Molnar
[   44.500228] ... MAX_LOCKDEP_SUBCLASSES:8
[   44.500266] ... MAX_LOCK_DEPTH:  30
[   44.500305] ... MAX_LOCKDEP_KEYS:2048
[   44.500343] ... CLASSHASH_SIZE:   1024
[   44.500383] ... MAX_LOCKDEP_ENTRIES: 8192
[   44.500421] ... MAX_LOCKDEP_CHAINS:  16384
[   44.500459] ... CHAINHASH_SIZE:  8192
[   44.500498]  memory used by lock dependency info: 1096 kB
[   44.500537]  per task-struct memory footprint: 1200 bytes
[   44.500576] 
[   44.500614] | Locking API testsuite:
[   44.500651] 

[   44.500697]  | spin |wlock |rlock |mutex | 
wsem | rsem |
[   44.500743]   
--
[   44.500794]  A-A deadlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[   44.501739]  A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[   44.502675]  A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[   44.503617]  A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[   44.504557]  A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[   44.505509]  A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[   44.506469]  A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[   44.507424] double unlock:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[   44.508327]   initialize held:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[   44.509245]  bad unlock order:  ok  |  ok  |  ok  |  ok  |  
ok  |  ok  |
[   44.510197]   
--
[   44.510243]   recursive read-lock: |  ok  |  
   |  ok  |
[   44.510656]recursive read-lock #2: |  ok  |  
   |  ok  |
[   44.511069] mixed read-write-lock: |  ok  |  
   |  ok  |
[   44.511507] mixed write-read-lock: |  ok  |  
   |  ok  |
[   44.511968]   
--
[   44.512015]  hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[   44.512501]  soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
[   44.512998]  hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[   44.513484]  soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
[   44.513970]sirq-safe-A => hirqs-on/12:  ok  |  ok  |  ok  |
[   44.514456]sirq-safe-A => hirqs-on/21:  ok  |  ok  |  ok  |
[   44.514941]  hard-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
[   44.515425]  soft-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
[   44.515910]  hard-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
[   44.516396]  soft-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
[   44.516882] hard-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
[   44.517380] soft-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
[   44.517924] hard-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
[   44.518417] soft-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
[   44.518909] hard-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
[   44.519402] soft-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
[   44.519896] hard-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
[   44.520388] soft-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
[   44.520881] hard-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
[   44.521388] soft-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
[   44.521886] hard-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
[   44.522389] soft-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
[   44.522907] hard-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
[   44.523402] soft-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
[   44.523894] hard-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
[   44.524387] soft-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
[   44.524880] hard-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
[   44.525373] soft-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
[   44.525866] hard-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
[   44.526359] soft-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
[   44.526850] hard-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
[   44.527342] soft-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok

Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)

[Uwe Bugla]

Am Samstag, 26. Mai 2007 17:50 schrieben Sie:
> Andrew,
>
> I am going to ignore Uwe from now on. It's simply impossible
> to debug the problem the way he is responding.
> Well, I'm not the first person in the Linux community adding
> him to the killfile, ... .
> I ask to try wireless-dev, as the driver works perfectly fine
> for me there, but he refuses to try it, too. So I'm stuck.

A. Where can I get wireless-dev, please?
B. Against what kernel can I apply it?
C. How must this stuff be applied?

Three clear questions, three clear answers please, if we want get forward.

Apart from that I do not owe a wireless device, and i more and more get the 
impression that you simply do not want to rework your code.
You rather search hungrily for excuses to point to some voluntary other side 
as soon as your code does not seem to work as expected and as soon as 
responsibilty issues are concerned.

So what tester would enjoy such a stubborn behaviour?
And additionally: Without getting paid for all the time effort?

> I already tried your -mm kernel, but it crashes on my machine
> for other reasons. (Yeah, I should look into them, too :P )
>
> Andrew, is it possible that the breakage was introduced in the
> merge process somehow? Didn't the patch apply cleanly? Are there
> other changes to b44 I should know about in your tree?

I think you can easily compare your wireless-dev code (where can I download 
it?) with the patch in the mm-tree. A simple diff will do I suppose.

>
> If it is really impossible to debug this problem, I'd like to
> suggest you to drop the b44-ssb port completely.
> I'm not going to destroy my nerves any further with guys like
> Uwe, so I'll include the b44-ssb port in the OpenWRT tree
> and be done with it.

As I stated already, debugging is not impossible!
In fact your responses didn't even mention real debugging as a choice.
To debug the issue I need the debug command line parametres for both ssb and 
b44. I cannot guess them, as there is no documentation available, neither for 
b44 nor for ssb. So what are the debug parametres please?

> Although I would be very sad about it, as my longterm goal was
> to make a vanilla kernel run on the OpenWRT devices... .

It is not my primary goal to leave you alone with this..

>
> But maybe we can get another tester for -mm with similiar problems,
> who is not bullshitting the whole time and is also going to
> test wireless-dev to make sure it's not a merge bug.

No, we need simply friendlier code developers without that immense arrogance 
behaviour that you show. That's it.

>
>
> ---
>
> And Uwe: Remember, I am not payed for this. I do _all_ this
> in my free time.
> So sentences like: "So, the ball has been in your court
> for two days now, and you simply keep on hesitating
> to take action now."
> are _completely_ displaced in this discussion.

Yes. And I am doing this in my spare time too. And what I do not like is 
simply guessing around (ACPI bug, typo errors at DNS and nonsense like that 
etc.) plus this gesture going: "You are dumb, you are not understanding 
anything etc."

Cheers and happy reflection

Uwe

P. S.: My door is open, although the whole issue starts to nerve me due to 
your behaviour.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.1 on Fedora Core 6 breaks LVM/vgscan

[Bill Davidsen]

Jonathan Woithe wrote:

On 21 May 2007 I wrote:


Attempting to compile a 2.6.21.1 kernel for use on a Fedora Core 6 box
results in a panic at boot because the root filesystem can't be found.


I have just compiled 2.6.22-rc2 with the configuration file given in my
previous post and the resulting kernel successfully boots on the machine
concerned.  Whatever broke LVM for this machine in between 2.6.18 and
2.6.21.1 has now been fixed.

I haven't had any problem booting with any of the kernels, but when I 
try to build a kernel with a Fedora config from /boot, it builds fine 
but doesn't boot after install. I started by building a very basic 
kernel for testing, and then started adding features to get everything I 
need. But just using the latest FC6 config file gets me a kernel which 
fails in just the way you mention.



There is still a problem with the CDROM but I will follow up in another
thread about that.

Happy to say I don't see that, I'm using PATA optical devices, and USB 
on some machines, both work. I can't get scanning to work even after 
buying a "supported" scanner, so I may have to go back to Slackware and 
a 2.4 kernel on one machine, but boot and run does fine.


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)

[Michael Buesch]

On Saturday 26 May 2007 18:13:09 Andrew Morton wrote:
> > I already tried your -mm kernel, but it crashes on my machine
> > for other reasons. (Yeah, I should look into them, too :P )
> 
> err, please do.  Just the oops trace would be a start.

Yes, I will look into it. I think it was related to my
onboard RTL networking chip. When trying to bring it down,
it oopses the machine. But I'm not sure what happens exactly, yet.
I'll take a look at it.

> > Andrew, is it possible that the breakage was introduced in the
> > merge process somehow? Didn't the patch apply cleanly? Are there
> > other changes to b44 I should know about in your tree?
> 
> Only git-wireless.net modifies b44.c but if we're having IRQ assignment
> problems then we'd need to look elsewhere.

I think we don't have IRQ assignment problems. Uwe simply disabled
b44-PCI support in his first bugreport (I guess). So there was
no b44-PCI driver loaded.
Later on he said that it does magically work now...

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

Fw: Re: [2.6.21.1] soft lockup when removing netconsole module

[Folkert van Heusden]

Hi,

> > Seems to be hrtimers related - CC'ed Thomas.
> 
> I doubt that. The tick interrupt just finds out, that the machine is
> stuck in rmmod.

Can you please make netconsole unloadable via rmmod? My system seems to
hang every time I do rmmod on netconsole (rmmod using 100% cpu and not
returning). Because now when the destination system gets a new
network-card or anything else changes I need to reboot the complete
(sending) machine.


Folkert van Heusden

-- 
MultiTail est un flexible tool pour suivre de logfiles et execution de
commandements. Filtrer, pourvoir de couleur, merge, 'diff-view', etc.
http://www.vanheusden.com/multitail/
--
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: IDE/ATA: Intel i865-based mainboard, CDROM not detected

[Bill Davidsen]

Jonathan Woithe wrote:

A collegue of mine has an Intel mainboard with the i865 chipset onboard
(DQ965).  All kernels up to and including 2.6.22-rc2 do not detect the IDE
CDROM/DVDROM when booting.  The SATA hard drive is found without any
problems.

Let me belatedly ask if the device shows up in POST at cold boot. It may 
need some BIOS setting to be visible.



--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)

[Uwe Bugla]

Am Samstag, 26. Mai 2007 18:13 schrieben Sie:
> On Sat, 26 May 2007 17:50:48 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote:
> > Andrew,
> >
> > I am going to ignore Uwe from now on. It's simply impossible
> > to debug the problem the way he is responding.
> > Well, I'm not the first person in the Linux community adding
> > him to the killfile, ... .
>
> Well yes, there are some personality issues here ;) But the main thing is
> to struggle on and fix this bug, wherever it lies.
>
> > I ask to try wireless-dev, as the driver works perfectly fine
> > for me there, but he refuses to try it, too. So I'm stuck.
>
> I don't think he knows how to obtain it.
>
> Uwe, http://userweb.kernel.org/~akpm/git-wireless.patch.gz is the current
> wireless tree.  That's a patch against 2.6.22-rc3.  Could you please test
> that?  If that works then we know that the bug probably lies outside the
> b44 driver (or it was subsequently fixed).

Thank you, Andrew, just wait for a while. I am gonna try.

>
> > I already tried your -mm kernel, but it crashes on my machine
> > for other reasons. (Yeah, I should look into them, too :P )
>
> err, please do.  Just the oops trace would be a start.
>
> > Andrew, is it possible that the breakage was introduced in the
> > merge process somehow? Didn't the patch apply cleanly? Are there
> > other changes to b44 I should know about in your tree?
>
> Only git-wireless.net modifies b44.c but if we're having IRQ assignment
> problems then we'd need to look elsewhere.  I guess you could diff
> rc2-mm1's b44.c against the expected version.
>
> > If it is really impossible to debug this problem, I'd like to
> > suggest you to drop the b44-ssb port completely.
>
> Well we don't know if that'll fix it.
>
> I believe that Uwe said that reverting the b44.c changes from rc2-mm1 fixes
> things for him?  Odd, but it still doesn't rule out acip/pci/platform
> changes as being the cause.

No, Andrew, not odd, but simply real! And Maximilian Engelhardt replied 
something similar on that : )

Cheers

Uwe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.3] [pata_jmicron] BUG: soft lockup detected on CPU#0!

[Bjoern Olausson]

Dear list members,

I am posting to this list just to get additional help for the bug I 
reported here:
http://bugzilla.kernel.org/show_bug.cgi?id=8259  

So the problem is the following:

I have a Asus P5W-DH Delux Mainboard with an onboard JMicron 20360/20363 AHCI 
Controller.
As soon as I enable this controller my system freezes after some time.

I captured some of the soft lockups with and without the closed source Nvidia 
drivers.  

As no one has answered for some time now on my bug, I am seeking help on this 
list.

My major question is: Does it look like a hardware issue or is it a bug in the 
driver?


Thanks for your help in advance.  

Best regards
Bjoern


Below I will provide all logs/dmsg/lspci  which could be from interest. If 
you need more info, blease let me kno
===
The soft lockup occurs still on  2.6.21.3
All logs/lspci/dmsg... can be found here http://olausson.name/bug/

The latest, captured today is
http://olausson.name/bug/2007.05.25-freax-bug-nvidia.log

Usefull information can be found on the following lines:
--Line 764 lspci --vv
--Line 1167 dmsg
--Line 1803 lsmod
--Line 1841 cat /proc/interrupts
--Line 1865 lsusb
--Line 1883 uname -a
--Line 1886 cat /usr/src/linux/.config

May 25 18:53:45 freax BUG: soft lockup detected on CPU#0!
May 25 18:53:45 freax
May 25 18:53:45 freax Call Trace:
May 25 18:53:45 freax   [] softlockup_tick+0xda/0xf5
May 25 18:53:45 freax [] update_process_times+0x42/0x68
May 25 18:53:45 freax [] smp_local_timer_interrupt+0x34/0x52
May 25 18:53:45 freax [] smp_apic_timer_interrupt+0x44/0x5e
May 25 18:53:45 freax [] apic_timer_interrupt+0x66/0x70
May 25 18:53:45 freax [] handle_IRQ_event+0x1a/0x53
May 25 18:53:45 freax [] handle_edge_irq+0xe4/0x128
May 25 18:53:45 freax [] do_IRQ+0xf1/0x160
May 25 18:53:45 freax [] ret_from_intr+0x0/0xa
May 25 18:53:45 freax [] ata_scsi_qc_complete+0x0/0x385
May 25 18:53:45 freax [] call_softirq+0x1c/0x28
May 25 18:53:45 freax [] __do_softirq+0x3e/0xb8
May 25 18:53:45 freax [] call_softirq+0x1c/0x28
May 25 18:53:45 freax [] do_softirq+0x2c/0x7d
May 25 18:53:45 freax [] irq_exit+0x36/0x42
May 25 18:53:45 freax [] do_IRQ+0x13d/0x160
May 25 18:53:45 freax [] ret_from_intr+0x0/0xa
May 25 18:53:45 freax   [] 
_spin_unlock_irqrestore+0xc/0x31
May 25 18:53:45 freax [] scsi_dispatch_cmd+0x1f1/0x236
May 25 18:53:45 freax [] scsi_request_fn+0x26c/0x337
May 25 18:53:45 freax [] generic_unplug_device+0x18/0x25
May 25 18:53:45 freax [] sync_buffer+0x36/0x40
May 25 18:53:45 freax [] __wait_on_bit+0x40/0x6e
May 25 18:53:45 freax [] sync_buffer+0x0/0x40
May 25 18:53:45 freax [] out_of_line_wait_on_bit+0x6c/0x78
May 25 18:53:45 freax [] wake_bit_function+0x0/0x23
May 25 18:53:45 freax [] 
journal_commit_transaction+0x68b/0x11fe
May 25 18:53:45 freax [] lock_timer_base+0x1b/0x3c
May 25 18:53:45 freax [] _spin_unlock_irqrestore+0x16/0x31
May 25 18:53:45 freax [] keventd_create_kthread+0x0/0x6a
May 25 18:53:45 freax [] kjournald+0xba/0x217
May 25 18:53:45 freax [] autoremove_wake_function+0x0/0x2e
May 25 18:53:45 freax [] keventd_create_kthread+0x0/0x6a
May 25 18:53:45 freax [] kjournald+0x0/0x217
May 25 18:53:45 freax [] kthread+0xd1/0x100
May 25 18:53:45 freax [] child_rip+0xa/0x12
May 25 18:53:45 freax [] keventd_create_kthread+0x0/0x6a
May 25 18:53:45 freax [] kthread+0x0/0x100
May 25 18:53:45 freax [] child_rip+0x0/0x12
May 25 18:53:45 freax
---

Older Soft Lockups:

(NV in the filenames means the xorg's nvidia driver)
(nvidia in the fienames means Nvidias closed source driver)

Heres a soft-lockup without NVIDIA driver (using the xorgs NV driver instead)

Apr 13 22:33:59 freax BUG: soft lockup detected on CPU#0!
Apr 13 22:33:59 freax  
Apr 13 22:33:59 freax Call Trace:
Apr 13 22:33:59 freax  [] softlockup_tick+0xda/0xf5
Apr 13 22:33:59 freax [] update_process_times+0x42/0x68
Apr 13 22:33:59 freax [] smp_local_timer_interrupt+0x34/0x52  
Apr 13 22:33:59 freax [] smp_apic_timer_interrupt+0x44/0x5e
Apr 13 22:33:59 freax [] apic_timer_interrupt+0x66/0x70
Apr 13 22:33:59 freax [] handle_IRQ_event+0x1a/0x53  
Apr 13 22:33:59 freax [] handle_edge_irq+0xe4/0x128
Apr 13 22:33:59 freax [] call_softirq+0x1c/0x28
Apr 13 22:33:59 freax [] do_IRQ+0xf1/0x160  
Apr 13 22:33:59 freax [] ret_from_intr+0x0/0xa
Apr 13 22:33:59 freax 


And this one is WITH the CS NVIDIA driver:

Apr 13 18:14:09 freax BUG: soft lockup detected on CPU#0!  
Apr 13 18:14:09 freax
Apr 13 18:14:09 freax Call Trace:
Apr 13 18:14:09 freax  [] softlockup_tick+0xda/0xf5
Apr 13 18:14:09 freax [] update_process_times+0x42/0x68  
Apr 13 18:14:09 freax [] smp_local_timer_interrupt+0x34/0x52
Apr 13 18:14:09 freax [] smp_apic_timer_interrupt+0x44/0x5e
Apr 13 18:14:09 freax [] apic_timer_interrupt+0x66/0x70  
Apr 13 18:14:09 freax [] handle_IRQ_event+0x1a/0x53
Apr 13 18:14:09 freax [] handle_edge_irq+0xe4/0x128
Apr 13

Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)

[Uwe Bugla]

Am Samstag, 26. Mai 2007 18:21 schrieben Sie:
> On Saturday 26 May 2007 18:13:09 Andrew Morton wrote:
> > > I already tried your -mm kernel, but it crashes on my machine
> > > for other reasons. (Yeah, I should look into them, too :P )
> >
> > err, please do.  Just the oops trace would be a start.
>
> Yes, I will look into it. I think it was related to my
> onboard RTL networking chip. When trying to bring it down,
> it oopses the machine. But I'm not sure what happens exactly, yet.
> I'll take a look at it.
>
> > > Andrew, is it possible that the breakage was introduced in the
> > > merge process somehow? Didn't the patch apply cleanly? Are there
> > > other changes to b44 I should know about in your tree?
> >
> > Only git-wireless.net modifies b44.c but if we're having IRQ assignment
> > problems then we'd need to look elsewhere.
>
> I think we don't have IRQ assignment problems. Uwe simply disabled
> b44-PCI support in his first bugreport (I guess).

Yes!

> So there was 
> no b44-PCI driver loaded.

Well, not exactly: b44 plus ssb were in fact produced, but did not function, 
at least in that case, due to the misleading / superficial information in the 
Kconfig menu..

> Later on he said that it does magically work now...

NO!

Later on I said I did chose that b44-PCI driver, got the right dependencies,
and there was no interrupt problem at all. So the driver got loaded as 
expected but simply did not work at all..

Cheers

Uwe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.1] soft lockup when removing netconsole module

[Thomas Gleixner]

On Sat, 2007-05-26 at 18:17 +0200, Folkert van Heusden wrote:
> > > Seems to be hrtimers related - CC'ed Thomas.
> > I doubt that. The tick interrupt just finds out, that the machine is
> > stuck in rmmod.
> > > > Also the rmmod hangs and would not exit even with kill -9. It also
> > > > sucks up 100% cpu.
> > Can you please enable CONFIG_PROVE_LOCKING ?
>
> Luckily I already had :-)
> Here is its output:

So there is no output from lockdep, during the rmmod hang ? The rmmod
sucks 100% cpu, so it busy loops at some place. Looking at the stack
trace this seems to be in:


void cancel_rearming_delayed_workqueue(struct workqueue_struct *wq, 


   struct delayed_work *dwork)  


{   


while (!cancel_delayed_work(dwork)) 


flush_workqueue(wq);


}

which is not really related to timers :)

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 2/3] Unify dma blacklist in ide-dma.c and libata-core.c

[Bill Davidsen]

Junio C Hamano wrote:

This introduces a shared header file that defines the entries
for two dma blacklists in ide-dma.c and libata-core.c to make it
easier to keep them in sync.

Why wasn't this done this way in the first place? Out of tree 
development for libata or something?


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: double exclamation (!!) suckage in the kernel

[Bodo Eggert]

Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> On May 25 2007 14:14, David Miller wrote:

>>"!!" is used in contexts where pointers might be being
>>tested as well as plain integers, the "!!" turns a pointer
>>into the equivalent integer boolean for testing.
>>
>>NULL pointers become 0
>>non-NULL pointers become 1
> 
> Though,
> if(!!ptr)
> is effectively the same as
> if(ptr)

Not exactly, if(foo) is the same as if( (int) foo), which is not
guaranteed to result in non-null values for non-null pointers.
ISO 9899/1999 says: "Any pointer may be converted to an integer type. [...]
 The result need not be in the range of values of any integer type."

"if(!!foo)" is the same as "if(0 == (0 == foo))", which is (I asume) the same
as "if(0 == ((type_of_foo)NULL == foo))", or if((type_of_foo)NULL != foo).
-- 
Funny quotes:
11. Atheism is a non-prophet orgainization.

Friß, Spammer: [EMAIL PROTECTED] [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: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)

[Michael Buesch]

On Saturday 26 May 2007 18:26:06 Uwe Bugla wrote:
> > I think we don't have IRQ assignment problems. Uwe simply disabled
> > b44-PCI support in his first bugreport (I guess).
> 
> Yes!
> 
> > So there was 
> > no b44-PCI driver loaded.
> 
> Well, not exactly: b44 plus ssb were in fact produced, but did not function, 
> at least in that case, due to the misleading / superficial information in the 
> Kconfig menu..
> 
> > Later on he said that it does magically work now...
> 
> NO!
> 
> Later on I said I did chose that b44-PCI driver, got the right dependencies,
> and there was no interrupt problem at all. So the driver got loaded as 
> expected but simply did not work at all..

One small sidenote:
If you did _not_ play around with the b44/ssb kconfig options at all,
it would have selected the right options _automatically_ for you.
That means:

cp ../old_kernel_without_ssb/.config .
make oldconfig
make
be done.

You intentionaly disabled PCI device support for b44 and you
still wonder why it doesn't work on your PCI device?
I'm not sure how to make the helptext any clearer on the b44-PCI
option. We have _lots_ of other drivers in the tree that work
EXACTLY the same way, regarding to kconfig. There are _lots_
of drivers where there are seperate options for a "bus-glue".
b44-ssb is no different. And additionally it automatically
selects the right options for 99.9% of the users (you included).

So I'm not sure why you keep bashing the kconfig implementation
here. It's common practice to have seperate config options for
bus-glues and it _automatically_ selects the right options for
you.

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

Re: [BUG] Warning in mm/slab.c:777

[Richard Mittendorfer]

Also sprach Rolf Eike Beer <[EMAIL PROTECTED]> (Sat, 26 May 2007 08:48:55 
+0200):
> After bootup (runlevel 5) I found this in dmesg:
> 
> WARNING: at mm/slab.c:777 __find_general_cachep()
>  [] __kmalloc+0x40/0xc3
>  [] drm_rmdraw+0x126/0x24e [drm]
>  [] skb_dequeue+0x39/0x3f
>  [] drm_rmdraw+0x0/0x24e [drm]
>  [] drm_ioctl+0x14c/0x192 [drm]
>  [] do_ioctl+0x4c/0x62
>  [] vfs_ioctl+0x237/0x249
>  [] mntput_no_expire+0x11/0x68
>  [] sys_ioctl+0x4c/0x65
>  [] sysenter_past_esp+0x5f/0x85
>  ===
> 
> Kernel is Linus' git of yesterday, the first occurence of this in my logs was 
> on May 16th.

It may be the same zero request I hit in slub, and according to 
http://bugzilla.kernel.org/show_bug.cgi?id=8476 people care about. Also
I remember a mail from Linus, where he meant it's handled quite well
(currently no link cause fetching thze whole IMAP quite takes some
time, sry).

> Greetings,
> 
> Eike

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

Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)

[Francois Romieu]

Uwe Bugla <[EMAIL PROTECTED]> :
> Am Samstag, 26. Mai 2007 18:13 schrieben Sie:
[...]
> > Uwe, http://userweb.kernel.org/~akpm/git-wireless.patch.gz is the current
> > wireless tree.  That's a patch against 2.6.22-rc3.  Could you please test
> > that?  If that works then we know that the bug probably lies outside the
> > b44 driver (or it was subsequently fixed).
> 
> Thank you, Andrew, just wait for a while. I am gonna try.

Please post the .config and the dmesg for the kernels that you try too.

-- 
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.1] soft lockup when removing netconsole module

[Folkert van Heusden]

> > > > Seems to be hrtimers related - CC'ed Thomas.
> > > I doubt that. The tick interrupt just finds out, that the machine is
> > > stuck in rmmod.
> > > > > Also the rmmod hangs and would not exit even with kill -9. It also
> > > > > sucks up 100% cpu.
> > > Can you please enable CONFIG_PROVE_LOCKING ?
> > Luckily I already had :-)
> > Here is its output:
> So there is no output from lockdep, during the rmmod hang ? The rmmod

Nope, just other subsystems (nfs, usb) minutes before that.

> sucks 100% cpu, so it busy loops at some place. Looking at the stack
> trace this seems to be in:
> void cancel_rearming_delayed_workqueue(struct workqueue_struct *wq,
>struct delayed_work *dwork)
> {
> while (!cancel_delayed_work(dwork))
> flush_workqueue(wq);
> }
> which is not really related to timers :)

Ok.


Folkert van Heusden

-- 

Multitail - gibkaja utilita po sledovaniju log-fajlov i vyvoda
kommand. Fil'trovanie, raskrašivanie, slijanie, vizual'noe sravnenie,
i t.d.  http://www.vanheusden.com/multitail/
--
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: double exclamation (!!) suckage in the kernel

[Al Viro]

On Sat, May 26, 2007 at 06:38:07PM +0200, Bodo Eggert wrote:
> Not exactly, if(foo) is the same as if( (int) foo), which is not
> guaranteed to result in non-null values for non-null pointers.

RTFStandard.

> ISO 9899/1999 says: "Any pointer may be converted to an integer type. [...]
>  The result need not be in the range of values of any integer type."

... and it sure as hell does *NOT* say that controlling expression of
if statement is converted to an integer type.  For pointers of for anything
else.  if (v) is the same as if (v != 0) [6.8.4.1p2], and if v is a pointer,
0 in that comparison becomes a null pointer constant [6.5.9p5].
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Pass struct vfsmount to the inode_create LSM hook

[Andreas Gruenbacher]

On Saturday 26 May 2007 16:44, Tetsuo Handa wrote:
> Hello.
>
> Andreas Gruenbacher wrote:
> > > Therefore, TOMOYO Linux checks the combination of filename and argv[0]
> > > passed to execve().
> >
> > So you are indeed trying to control the value of argv[0]? Well, good luck
> > with that, but it's totally insane. You are guaranteed to break some
> > applications.
>
> TOMOYO Linux restricts argv[0] using allow_argv0 syntax.

Alright, so it's configurable. This reduces it from being broken to being a 
truly bad idea.

> For example, an administrator may wish to allow users to run /bin/ls without
> applying profiles because /bin/ls won't read/write the content of files.

No, forget that line of reasoning. As soon as you run anything unconfined that 
isn't trusted, you have basically lost control. Relying on the fact 
that /bin/ls won't do any harm is assuming to much. Features might exist that 
allow it to be abused, new features might get added, or there may be bugs. 
Just don't do it.

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

Re: [PATCH 2/3] Unify dma blacklist in ide-dma.c and libata-core.c

[Alan Cox]

On Mon, 21 May 2007 22:06:36 -0700
Junio C Hamano <[EMAIL PROTECTED]> wrote:

> This introduces a shared header file that defines the entries
> for two dma blacklists in ide-dma.c and libata-core.c to make it
> easier to keep them in sync.
> 
> Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>

NAK

This makes stuff so much more ugly its not funny

> ---
> 
>  * Removes more lines than it adds.  I am not proud of the
>DMA_BLACK_LIST macro in ide-dma.c which relies on the
>compiler doing a sane thing for compile time constant
>expression to initialize the list, but that hopefully can be
>fixed in the next patch.

The basic concept is sound but it would be better to make sure
the ATA_HORKAGE macros and struct ata_blacklist_entry as well as all the
blacklist stuff was placed together in one file to avoid the horrors you
are proposing and then used by both driver sets.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.1] soft lockup when removing netconsole module

[Thomas Gleixner]

On Sat, 2007-05-26 at 18:49 +0200, Folkert van Heusden wrote:
> > > > > Seems to be hrtimers related - CC'ed Thomas.
> > > > I doubt that. The tick interrupt just finds out, that the machine is
> > > > stuck in rmmod.
> > > > > > Also the rmmod hangs and would not exit even with kill -9. It also
> > > > > > sucks up 100% cpu.
> > > > Can you please enable CONFIG_PROVE_LOCKING ?
> > > Luckily I already had :-)
> > > Here is its output:
> > So there is no output from lockdep, during the rmmod hang ? The rmmod
> 
> Nope, just other subsystems (nfs, usb) minutes before that.

Hmm. Can you provide the output of that ? Might be some stale stuff
leading to the hang later.

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/