RE: [PATCH 03/10] PCI: AMD SATA IDE mode quirk
> On Mon, Feb 25, 2008 at 09:43:59AM +0800, Cai, Crane wrote:
> > > On Fri, Feb 22, 2008 at 01:49:20PM +0800, Cai, Crane wrote:
> > > > > On Thu, Feb 21, 2008 at 03:47:33PM -0800, Greg
> > > Kroah-Hartman wrote:
> > > > > > +static void __devinit quirk_amd_ide_mode(struct pci_dev
> > > > > > +*pdev)
> > > > > > {
> > > > > > - /* set sb600 sata to ahci mode */
> > > > > > - if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> > > > > > - u8 tmp;
> > > > > > + /* set sb600/sb700/sb800 sata to ahci mode */
> > > > > > + u8 tmp;
> > > > > >
> > > > > > + pci_read_config_byte(pdev, PCI_CLASS_DEVICE, &tmp);
> > > > > > + if (tmp == 0x01) {
> > > > > > pci_read_config_byte(pdev, 0x40, &tmp);
> > > > >
> > > > > This seems like a dis-improvement. Why are we reading a
> > > config byte
> > > > > for something we already have in the pci_dev?
> > > > > Why are we now checking against 0x01 instead of a
> > > symbolic constant?
> > > > > Why are we no longer checking that this is
> PCI_BASE_CLASS_STORAGE?
> > > > It is a quirk. In pci_ids.h did have PCI_CLASS_STORAGE_IDE and
> > > > PCI_BASE_CLASS_STORAGE, these can not represent the right
> > > situation we
> > > > want to check. 0x01 represents PCI_CLASS_STORAGE_IDE last 2
> > > bit. Also
> > > > because it is a quirk, I do not think we need to change
> > > pci_ids.h. So
> > > > 0x01 used.
> > >
> > > You haven't explained what is wrong with the original code:
> > >
> > > if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> > >
> >
> > When resume, this pdev->class is quirked, however BIOS has modified
> > pci configuration too. Inconsistance occurs.
>
> Can you update pdev->class from the quirk?
I think we can, there are many places where pdev->class is changed in quirks.c.
> It would be consistent then.
> That would leave the code as-is except it's re-reading the
> field from config space.
>
> hth,
> grant
> > > > > Nothing in the changelog entry suggests why we now need
> > > FIXUP_RESUME
> > > > > entries when we didn't before.
> > > > >
> > > > PCI configuration space will be changed by BIOS and then in
> > > pci init
> > > > and restore. So resume also needed.
> > >
> > > That information needed to be in the changelog.
> >
> > This info, is a normal info. If maintainer need us to added
> in source code. I preferred too.
> > > --
> > > Intel are signing my paycheques ... these opinions are still mine
> > > "Bill, look, we understand that you're interested in
> selling us this
> > > operating system, but compare it to ours. We can't possibly take
> > > such a retrograde step."
> > >
> > >
> > >
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Q] x86 - boot/header.S
[H. Peter Anvin - Sun, Feb 24, 2008 at 06:15:52PM -0800] > Cyrill Gorcunov wrote: >> Hi Peter, Sam, >> could you take a look on x86/boot/header.S:280 please? >> # Zero the bss >> movw$__bss_start, %di >> movw$_end+3, %cx >> xorl%eax, %eax >> subw%di, %cx >> shrw$2, %cx >> rep; stosl >> I wonder why is $_end there instead of $__bss_stop? >> Well, accroding to vmlinux_32.lsd both _end and __bss_stop >> are the same BUT __bss_stop is more convenient methink. >> Would it be usefull to change? > > x86/boot/header.S goes with x86/boot/setup.ld and no other linker script. > > -hpa > indeed... :( anyway, setup.ld has the definition of __bss_stop too though in this case __bss_stop is not equal to _end BUT [__bss_start;__bss_stop] do cover *bss section anyway. According to Sam's last post it will not be a problem anymore 'cause of memset further usage. Thanks for comments, Peter. - Cyrill - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] atmel_spi: support zero length transfer
On Saturday 23 February 2008, David Brownell wrote: ... > No, it's fully defined. "Crash my engine" is not OK. The delay > is controlled by transfer.delay_usecs ... possibly zero, which is > best viewed as a degenerate case. Ooops, I missed that (the delay *is* defined in transfer.delay_usecs). So I agree, it's fully defined. Regards Marc -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Xilinx: hwicap: cleanup
On 02/25/2008 12:21 AM, Stephen Neuendorffer wrote: @@ -549,8 +556,7 @@ static int hwicap_release(struct inode *inode, struct file *file) int i; int status = 0; - if (down_interruptible(&drvdata->sem)) - return -ERESTARTSYS; + mutex_lock(&drvdata->sem); Why not mutex_lock_interruptible()? (goes for all cases of mutex_lock()) It's not clear to me how to get 'correct' behavior in these functions if the interrupt happens. For instance in probe/setup, if the mutex_lock is interrupted, it doesn't appear that there is anything to do other than return an error code that no device is present? I think this was suggested by Jiri... Yeah, since ERESTARTSYS would be ignored from f_op->release (see __fput()), drv->probe (see really_probe() and probe_failed label); not even talking about void return value functions. In those cases, the device won't be de/initialized and might result in unwanted behaviour (multiple modprobes for one device, rmmod/insmod need if you hit the path in release etc.). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] autofs4 - implement a miscelaneous device for ioctl control
We have four patches, all with the same title - please avoid doing this. I could invent titles for them (as I often have to do), but I think it would be best if you were to do so. That way, we avoid confusion and people who later google for the patch's title to understand the patch's background will get better coverage. So... resend, please? Documentation/SubmittingPatches has some tips on all of this - search term is "Subject:". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression [Was: Boot hang with stack protector on x86_64]
* James Morris <[EMAIL PROTECTED]> wrote: > > > could you try the fix below ontop of x86.git#testing, does it > > > solve your boot hang? > > > > find below another fix that is somewhat better as it does not affect > > the native kernel and !PARAVIRT. > > This works. thanks. We'll delay the stackprotector fixes for v2.6.26 (it's been broken for too long), but if you want to have it you can pick it up from x86.git. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] x86: Use ELF section to list CPU vendor specific code (Linux Tiny)
Le Sat, 23 Feb 2008 10:43:37 +0800,
Matt Mackall <[EMAIL PROTECTED]> a écrit :
> This is not quite what Peter and I were thinking of, I think. It's not
> at all generic. How about a section that simply contains a set of
> function pointers, a macro to add things to that section, and a
> function that calls all the pointers in that section. Eg:
>
> CALLBACK_SECTION(init_cpu_amd, "cpuvendor.init");
> invoke_callback_section("cpuvendor.init");
>
> ..which would give us a generic facility we could use in various
> places.
I see. Probably doable. How would it work in the LD script file ? Your
mechanism allows to specify any section name, but AFAIK, the sections
must be explicitly listed in the kernel LD script in order to be
included in the final kernel image. Am I missing something ?
Sincerly,
Thomas
--
Thomas Petazzoni, Free Electrons
Free Embedded Linux Training Materials
on http://free-electrons.com/training
(More than 1500 pages!)
signature.asc
Description: PGP signature
Re: [PATCH 3/3] IDE: Coding Style fixes to drivers/ide/pci/cy82c693.c
On Mon, Feb 25, 2008 at 8:31 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Paolo Ciarrocchi <[EMAIL PROTECTED]> wrote: > > > Before: > > total: 34 errors, 14 warnings, 456 lines checked > > > > After: > > total: 0 errors, 8 warnings, 456 lines checked > > sidenote: please also indicate to maintainers that the cleanup causes no > change in generated code. Find below of how one of your cleanup patches > looks like in its final form in x86.git. (i auto-generated all of the > commit log) > > info like that makes it easier for maintainers to see the intended zero > impact of your changes. Sure, I'll script that. Ciao, -- Paolo http://paolo.ciarrocchi.googlepages.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: Q: volatile vs barriers to access memory data changed by device DMA
> === after conversion
> struct bus_master_interface *interface;
> while (interface->ack != OK) {
> delay(a short while);
> rmb();
> [ after X loops device changes interface->ack by dma ]
> };
>
> All I need is for the read of interface->ack in the loop not to be optimised
> away - is rmb() the appropriate incantation to achieve this?
Yes - ish. You want the equivalent of
do {
rmb();
if (interface->ack == OK)
break;
} while(1);
(eg putting another rmb before the while in your case)
You want a barrier before the *first* read in case the
compiler has managed to cache the value before you enter the loop.
> struct bus_master_interface *interface;
> interface->cmd = command;
> wmb();
> iowrite(device_interrupt, 1);
Yes.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.25-rc] pcmcia section mismatches
During compilation: LD [M] drivers/pcmcia/pcmcia_core.o WARNING: drivers/pcmcia/pcmcia_core.o(.data+0x1d4): Section mismatch in reference from the variable pccard_sysfs_interface to the function .devinit.text:pccard_sysfs_add_socket() The variable pccard_sysfs_interface references the function __devinit pccard_sysfs_add_socket() If the reference is valid then annotate the variable with __init* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: drivers/pcmcia/pcmcia_core.o(.data+0x1d8): Section mismatch in reference from the variable pccard_sysfs_interface to the function .devexit.text:pccard_sysfs_remove_socket() The variable pccard_sysfs_interface references the function __devexit pccard_sysfs_remove_socket() If the reference is valid then annotate the variable with __exit* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, LD [M] drivers/pcmcia/pcmcia.o WARNING: drivers/pcmcia/pcmcia.o(.data+0x4c): Section mismatch in reference from the variable pcmcia_bus_interface to the function .devinit.text:pcmcia_bus_add_socket() The variable pcmcia_bus_interface references the function __devinit pcmcia_bus_add_socket() If the reference is valid then annotate the variable with __init* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, and later during modpost: MODPOST 260 modules WARNING: drivers/pcmcia/pcmcia.o(.data+0x4c): Section mismatch in reference from the variable pcmcia_bus_interface to the function .devinit.text:pcmcia_bus_add_socket() The variable pcmcia_bus_interface references the function __devinit pcmcia_bus_add_socket() If the reference is valid then annotate the variable with __init* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: drivers/pcmcia/pcmcia_core.o(.data+0x1d4): Section mismatch in reference from the variable pccard_sysfs_interface to the function .devinit.text:pccard_sysfs_add_socket() The variable pccard_sysfs_interface references the function __devinit pccard_sysfs_add_socket() If the reference is valid then annotate the variable with __init* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: drivers/pcmcia/pcmcia_core.o(.data+0x1d8): Section mismatch in reference from the variable pccard_sysfs_interface to the function .devexit.text:pccard_sysfs_remove_socket() The variable pccard_sysfs_interface references the function __devexit pccard_sysfs_remove_socket() If the reference is valid then annotate the variable with __exit* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: drivers/pcmcia/rsrc_nonstatic.o(.data+0x9c): Section mismatch in reference from the variable pccard_rsrc_interface to the function .devinit.text:pccard_sysfs_add_rsrc() The variable pccard_rsrc_interface references the function __devinit pccard_sysfs_add_rsrc() If the reference is valid then annotate the variable with __init* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: drivers/pcmcia/rsrc_nonstatic.o(.data+0xa0): Section mismatch in reference from the variable pccard_rsrc_interface to the function .devexit.text:pccard_sysfs_remove_rsrc() The variable pccard_rsrc_interface references the function __devexit pccard_sysfs_remove_rsrc() If the reference is valid then annotate the variable with __exit* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, config attached. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc3 # Mon Feb 25 09:46:58 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_N
Re: [BUG] 2.6.25-rc2-git8 fails to boot on 486 due to TSC breakage
* H. Peter Anvin <[EMAIL PROTECTED]> wrote: > Please fix it in both places. Using XOR instead of AND-NOT is a bug, > plain and simple. yes, i already fixed that when i added Mikael's patch and it's all queued up. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bluez-devel] forcing SCO connection patch
Sorry, [EMAIL PROTECTED] was missed in cc On Mon, Feb 25, 2008 at 3:34 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > On Mon, Feb 25, 2008 at 3:30 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > Quote mail from [EMAIL PROTECTED] : > > > > 2007/12/17 Louis JANG <[EMAIL PROTECTED]>: > > > > > > > Hello everybody, > > > > > > I attached two patches. the first one(bluez-kernel-forcesco.patch) is > to > > > force using HCI_OP_ADD_SCO instead of HCI_OP_SETUP_SYNC_CONN, and the > > > second one is to handle SCO connection complete event but its request > > > was ESCO. > > > > > > 1. > > > I'm developing bluetooth functions in my linux phone project, and I'm > > > using bluez for my job. I've tested lots of headsets, and found that I > > > coudn't connect SCO channel with HCI_OP_SETUP_SYNC_CONN in some old > > > headsets. I could connect SCO channel with HCI_OP_ADD_SCO in this case. > > > however, there is no api to force using SCO instead of ESCO in bluez. > so > > > I added SCO_FORCESCO to handle this old headsets > > > > > > 2. > > > When I tried to connect SCO channel with > > > HCI_OP_SETUP_SYNC_CONN(LINK_TYPE_ESCO), some bluetooth headsets > responds > > > with LINK_TYPE_SCO because it did not support ESCO. But bluez couldn't > > > handle this situation, and patch_hci_event.c is for this. > > > > > > > > > BRs > > > Louis JANG > > > > > > > > > > Reply from [EMAIL PROTECTED]: > > > > On Mon, Feb 25, 2008 at 2:43 PM, Brad Midgley <[EMAIL PROTECTED]> wrote: > > > Louis > > > > > > > > > > > > When I tried to connect SCO channel with > > > > HCI_OP_SETUP_SYNC_CONN(LINK_TYPE_ESCO), some bluetooth headsets > responds > > > > with LINK_TYPE_SCO because it did not support ESCO. But bluez > couldn't > > > > handle this situation, and patch_hci_event.c is for this. > > > > > > > > Marcel looked at this patch and came back with the comments below. Can > > > you revisit it? I think some other people are seeing the same issues. > > > The patch won't go upstream until Marcel likes it. > > > > > > the patch you sent me is fully broken. First of all the coding style > > > is wrong. Does nobody have learned this by now? I always look for that > > > first before even reading the patch. Second the case where an > > > ESCO_LINK returns NULL is broken and will fall over and crash. > > > > > > -- > > > Brad > > > > > > > > > I ever asked marcel about the coding style. please see following thread: > > http://lkml.org/lkml/2008/1/22/91 > > > > I think the style problem marcel said is > > 1. using kernel codeing style > > 2. marcel's style > > container_of or get_user_data calls at the top of the variable declaration > > using the empty lines to seperate code blocks > > > > Please rework your patch and resend if you fixed them. > > > > BTW, please use the new bluetooth mailing list for kerne issue. > > [EMAIL PROTECTED] > > > > (Thanks for andrew and davem) > > On bugzilla, bug 9871 are same problem as yours. > > add davem and netdev in cc-list > > > > > Regards > > dave > > > > Regards > > dave > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.25-rc] pci_scan_child_bus, pci_acpi_scan_root section mismatch
MODPOST vmlinux.o WARNING: vmlinux.o(.text+0xec461): Section mismatch in reference from the function pci_scan_child_bus() to the function .devinit.text:pcibios_fixup_bus() The function pci_scan_child_bus() references the function __devinit pcibios_fixup_bus(). This is often because pci_scan_child_bus lacks a __devinit annotation or the annotation of pcibios_fixup_bus is wrong. WARNING: vmlinux.o(.text+0x12388b): Section mismatch in reference from the function acpi_pci_root_add() to the function .devinit.text:pci_acpi_scan_root() The function acpi_pci_root_add() references the function __devinit pci_acpi_scan_root(). This is often because acpi_pci_root_add lacks a __devinit annotation or the annotation of pci_acpi_scan_root is wrong. config attached. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc3 # Mon Feb 25 09:46:58 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_EMBEDDED=y # CONFIG_UID16 is not set # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=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_PROFILING=y # CONFIG_MARKERS is not set CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_KPROBES=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG 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" CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=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_X86_RDC321X is not set # CONFIG_X86_VSMP is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT_GUEST 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
Re: 2.6.25-rc2-mm1 - several bugs and a crash
Paul E. McKenney schrieb: On Fri, Feb 22, 2008 at 01:52:53AM +0100, Tilman Schmidt wrote: So the nf_conntrack BUG is fixed, but the crash (and of course the swapper "spinlock bad magic" BUG) persists. Do you have CONFIG_DEBUG_PREEMPT set? That would help find any other bugs similar to nf_conntrack. CONFIG_DEBUG_PREEMPT=y was set but didn't produce anything. Or perhaps it did and the message just didn't make it to the disk. Time to set up a test with netconsole, I guess. -- Tilman SchmidtE-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: Patch kernel: I have 8 Gbytes RAM, but why I can only allocate 2.8 Gbytes RAM for a single process?
On 25-02-08 08:44, Ady Wicaksono wrote: I have 8 Gbytes RAM, but why I can allocate 2.8 Gbytes RAM for a single process? How to patch kernel so I have more than 2.8 Gbytes limitation? [ ... ] flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl est cid xtpr Run a 64-bit kernel and userspace. not a 32-bit. Rene. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 [RT] 11/14] optimize the !printk fastpath through the lock acquisition
On Sun, Feb 24, 2008 at 10:21 PM, Bill Huey (hui) <[EMAIL PROTECTED]> wrote: > It's probably safe to use, but it's not what its original purpose was > and you should use another function/macro. This is an annotation issue > and your use of it is inconsistent with how it's used in voluntary > preempt. I mentioned it before in a previous post. Folks will correct > me if I'm wrong but you should use another macro or function. Actually, forget what I said, it's ok to use it. bill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB OOPS 2.6.25-rc2-git1
On Thursday 21 February 2008, Alan Stern wrote: > > = CUT HERE > > Modify EHCI irq handling on the theory that at least some of the > > "lost" IRQs are caused by goofage between multiple lowlevel IRQ > > acking mechanisms: try rescanning before we exit the handler, in > > case the EHCI-internal ack (by clearing the irq status) doesn't > > always suffice for IRQs triggered nearly back-to-back. > > > > --- > > drivers/usb/host/ehci-hcd.c | 8 > > 1 file changed, 8 insertions(+) > > > > --- g26.orig/drivers/usb/host/ehci-hcd.c 2008-02-20 13:26:00.0 > > -0800 > > +++ g26/drivers/usb/host/ehci-hcd.c 2008-02-20 13:54:37.0 -0800 > > @@ -638,6 +638,8 @@ static irqreturn_t ehci_irq (struct usb_ > > return IRQ_NONE; > > } > > > > +retrigger: > > + > > /* clear (just) interrupts */ > > ehci_writel(ehci, status, &ehci->regs->status); > > cmd = ehci_readl(ehci, &ehci->regs->command); > > @@ -725,6 +727,12 @@ dead: > > > > if (bh) > > ehci_work (ehci); > > + > > + status = ehci_readl(ehci, &ehci->regs->status); > > + status &= INTR_MASK; > > + if (status) > > + goto retrigger; > > + > > spin_unlock (&ehci->lock); > > if (pcd_status & STS_PCD) > > usb_hcd_poll_rh_status(hcd); > > There's one little problem here. As a result of this change, the line > where pcd_status gets set (not shown in this patch) needs to be changed > to: > > pcd_status |= (status & STS_PCD); Actually, no change is needed. It's initialized to zero, then set to "status" given "if (status & STS_PCD)", and never cleared. So if it's ever set, it stays set... > > Then the test shown above can be simplified to: > > if (pcd_status) True with the current code too ... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.25-rc2-git8 fails to boot on 486 due to TSC breakage
Ingo Molnar writes: > > * H. Peter Anvin <[EMAIL PROTECTED]> wrote: > > > Please fix it in both places. Using XOR instead of AND-NOT is a bug, > > plain and simple. > > yes, i already fixed that when i added Mikael's patch and it's all > queued up. Ok. For reference and for LKML viewers, this is what the final patch should be: diff -rupN linux-2.6.25-rc3/arch/x86/kernel/cpu/common.c linux-2.6.25-rc3.x86-apply-cleared_cpu_caps-correctly/arch/x86/kernel/cpu/common.c --- linux-2.6.25-rc3/arch/x86/kernel/cpu/common.c 2008-02-25 09:29:03.0 +0100 +++ linux-2.6.25-rc3.x86-apply-cleared_cpu_caps-correctly/arch/x86/kernel/cpu/common.c 2008-02-25 09:44:11.0 +0100 @@ -504,7 +504,7 @@ void __cpuinit identify_cpu(struct cpuin /* Clear all flags overriden by options */ for (i = 0; i < NCAPINTS; i++) - c->x86_capability[i] ^= cleared_cpu_caps[i]; + c->x86_capability[i] &= ~cleared_cpu_caps[i]; /* Init Machine Check Exception if available. */ mcheck_init(c); diff -rupN linux-2.6.25-rc3/arch/x86/kernel/setup_64.c linux-2.6.25-rc3.x86-apply-cleared_cpu_caps-correctly/arch/x86/kernel/setup_64.c --- linux-2.6.25-rc3/arch/x86/kernel/setup_64.c 2008-02-25 09:29:03.0 +0100 +++ linux-2.6.25-rc3.x86-apply-cleared_cpu_caps-correctly/arch/x86/kernel/setup_64.c 2008-02-25 09:44:57.0 +0100 @@ -1021,7 +1021,7 @@ void __cpuinit identify_cpu(struct cpuin /* Clear all flags overriden by options */ for (i = 0; i < NCAPINTS; i++) - c->x86_capability[i] ^= cleared_cpu_caps[i]; + c->x86_capability[i] &= ~cleared_cpu_caps[i]; #ifdef CONFIG_X86_MCE mcheck_init(c); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.25-rc2-git8 fails to boot on 486 due to TSC breakage
* Mikael Pettersson <[EMAIL PROTECTED]> wrote:
> > yes, i already fixed that when i added Mikael's patch and it's all
> > queued up.
>
> Ok. For reference and for LKML viewers, this is what the final patch
> should be:
below is the full commit - will send it to Linus later today.
Ingo
--->
Subject: x86: fix boot failure on 486 due to TSC breakage
From: Mikael Pettersson <[EMAIL PROTECTED]>
Date: Sun, 24 Feb 2008 18:27:03 +0100
> Diffing dmesg between git7 and git8 doesn't sched any light since
> git8 also removed the printouts of the x86 caps as they were being
> initialised and updated. I'm currently adding those printouts back
> in the hope of seeing where and when the caps get broken.
That turned out to be very illuminating:
--- dmesg-2.6.24-git7 2008-02-24 18:01:25.295851000 +0100
+++ dmesg-2.6.24-git8 2008-02-24 18:01:25.530358000 +0100
...
CPU: After generic identify, caps: 0003
CPU: After all inits, caps: 0003
+CPU: After applying cleared_cpu_caps, caps: 0013
Notice how the TSC cap bit goes from Off to On.
(The first two lines are printout loops from -git7 forward-ported
to -git8, the third line is the same printout loop added just after
the xor-with-cleared_cpu_caps[] loop.)
Here's how the breakage occurs:
1. arch/x86/kernel/tsc_32.c:tsc_init() sees !cpu_has_tsc,
so bails and calls setup_clear_cpu_cap(X86_FEATURE_TSC).
2. include/asm-x86/cpufeature.h:setup_clear_cpu_cap(bit) clears
the bit in boot_cpu_data and sets it in cleared_cpu_caps
3. arch/x86/kernel/cpu/common.c:identify_cpu() XORs all caps
in with cleared_cpu_caps
HOWEVER, at this point c->x86_capability correctly has TSC
Off, cleared_cpu_caps has TSC On, so the XOR incorrectly
sets TSC to On in c->x86_capability, with disastrous results.
The real bug is that clearing bits with XOR only works if the
bits are known to be 1 prior to the XOR, and that's not true here.
A simple fix is to convert the XOR to AND-NOT instead. The following
patch does that, and allows my 486 to boot 2.6.25-rc kernels again.
[ [EMAIL PROTECTED]: fixed a similar bug in setup_64.c as well. ]
The breakage was introduced via commit 7d851c8d3db0.
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/common.c |2 +-
arch/x86/kernel/setup_64.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-x86.q/arch/x86/kernel/cpu/common.c
===
--- linux-x86.q.orig/arch/x86/kernel/cpu/common.c
+++ linux-x86.q/arch/x86/kernel/cpu/common.c
@@ -504,7 +504,7 @@ void __cpuinit identify_cpu(struct cpuin
/* Clear all flags overriden by options */
for (i = 0; i < NCAPINTS; i++)
- c->x86_capability[i] ^= cleared_cpu_caps[i];
+ c->x86_capability[i] &= ~cleared_cpu_caps[i];
/* Init Machine Check Exception if available. */
mcheck_init(c);
Index: linux-x86.q/arch/x86/kernel/setup_64.c
===
--- linux-x86.q.orig/arch/x86/kernel/setup_64.c
+++ linux-x86.q/arch/x86/kernel/setup_64.c
@@ -1021,7 +1021,7 @@ void __cpuinit identify_cpu(struct cpuin
/* Clear all flags overriden by options */
for (i = 0; i < NCAPINTS; i++)
- c->x86_capability[i] ^= cleared_cpu_caps[i];
+ c->x86_capability[i] &= ~cleared_cpu_caps[i];
#ifdef CONFIG_X86_MCE
mcheck_init(c);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1/2 CD/DVD burning broken
"Kiyoshi Ueda" <[EMAIL PROTECTED]> writes: > o Have you tried bisecting the kernel changes to find suspicious >commit? If so, that information will be much appreciated. That is close to impossible. Intervening kernels either don't boot or crash while burning. Especially the one with the bad commit crashes in cdrom_newpc_intr almost immediately when burning starts. > o Is this problem 100% reproducible on your Pioneer drive? Yes. See the comment in the growisofs sources, this sense code is Pioneer specific. > o Do you get some messages from kernel like "DMA error" when >the problem happens? Never. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] autofs4 - implement a miscelaneous device for ioctl control
On Mon, 2008-02-25 at 00:17 -0800, Andrew Morton wrote: > We have four patches, all with the same title - please avoid doing this. > > I could invent titles for them (as I often have to do), but I think it > would be best if you were to do so. That way, we avoid confusion and > people who later google for the patch's title to understand the patch's > background will get better coverage. > > So... resend, please? OK, sorry. I was waiting to hear from you anyway as, for some reason, at least one of the posts had HTML and so was bounced form lkml and fsdevel. I'll just re-send'em all. Ian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.25-rc2 Regression Thinkpad acpi
Hello, 2.6.25-rc2-git7 has regression, thinkpad keys do not work any more. Probably this commit broke things 6c231bd5eb07ce546517019f334652b9ecfc329a -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: fix comment of struct usb_interface
From: Lei Ming <[EMAIL PROTECTED]>
update the comment for the removed "driver" field and being
out-of-order of @cur_altsetting and @num_altsetting.
Signed-off-by: Lei Ming <[EMAIL PROTECTED]>
---
include/linux/usb.h |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
mode change 100644 => 100755 include/linux/usb.h
diff --git a/include/linux/usb.h b/include/linux/usb.h
old mode 100644
new mode 100755
index 2372e2e..8a864f8
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -94,10 +94,9 @@ enum usb_interface_condition {
* @altsetting: array of interface structures, one for each alternate
* setting that may be selected. Each one includes a set of
* endpoint configurations. They will be in no particular order.
- * @num_altsetting: number of altsettings defined.
* @cur_altsetting: the current altsetting.
+ * @num_altsetting: number of altsettings defined.
* @intf_assoc: interface association descriptor
- * @driver: the USB driver that is bound to this interface.
* @minor: the minor number assigned to this interface, if this
* interface is bound to a driver that uses the USB major number.
* If this interface does not use the USB major, this field should
--
1.5.4.rc4.338.g923d4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-next: Tree for Feb 24
Hi, Stephen Rothwell wrote: > I have created today's linux-next tree at i bet your $SUBJECT was meant for the Tree for Feb 25, wasn't it? ;-) Thanks, Frank -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bluez-devel] forcing SCO connection patch
> I ever asked marcel about the coding style. please see following thread:
> http://lkml.org/lkml/2008/1/22/91
>
> I think the style problem marcel said is
> 1. using kernel codeing style
> 2. marcel's style
> container_of or get_user_data calls at the top of the variable declaration
> using the empty lines to seperate code blocks
>
> Please rework your patch and resend if you fixed them.
>
> BTW, please use the new bluetooth mailing list for kerne issue.
> [EMAIL PROTECTED]
>
> (Thanks for andrew and davem)
>
> Regards
> dave
>
> Regards
> dave
>
>
Hi all,
I adjusted indentation of the patches but I'm not sure what's wrong
about second comment of Marcel. please let me know if there are another
problems in this patch.
Thanks in advance,
Louis JANG
--- net/bluetooth/hci_event.c.orig 2008-02-25 17:17:11.0 +0900
+++ net/bluetooth/hci_event.c 2008-02-25 17:30:23.0 +0900
@@ -1313,8 +1313,17 @@
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
- if (!conn)
- goto unlock;
+ if (!conn) {
+ if (ev->link_type != ACL_LINK) {
+ __u8 link_type = (ev->link_type == ESCO_LINK) ?
SCO_LINK : ESCO_LINK;
+
+ conn = hci_conn_hash_lookup_ba(hdev, link_type,
&ev->bdaddr);
+ if (conn)
+ conn->type = ev->link_type;
+ }
+ if (!conn)
+ goto unlock;
+ }
if (!ev->status) {
conn->handle = __le16_to_cpu(ev->handle);
diff -uNr include/net/bluetooth-orig/sco.h include/net/bluetooth/sco.h
--- include/net/bluetooth-orig/sco.h2007-10-10 05:31:38.0 +0900
+++ include/net/bluetooth/sco.h 2008-02-25 18:04:20.0 +0900
@@ -51,6 +51,8 @@
__u8 dev_class[3];
};
+#define SCO_FORCESCO 0x03
+
/* SCO connections */
struct sco_conn {
struct hci_conn *hcon;
@@ -74,6 +76,7 @@
struct bt_sock bt;
__u32 flags;
struct sco_conn *conn;
+ unsigned intforce_sco :1;
};
#endif /* __SCO_H */
diff -uNr net/bluetooth-orig/hci_conn.c net/bluetooth/hci_conn.c
--- net/bluetooth-orig/hci_conn.c 2008-02-25 17:58:27.0 +0900
+++ net/bluetooth/hci_conn.c2008-02-25 18:02:04.0 +0900
@@ -354,7 +354,7 @@
if (acl->state == BT_CONNECTED &&
(sco->state == BT_OPEN || sco->state == BT_CLOSED)) {
- if (lmp_esco_capable(hdev))
+ if (type == ESCO_LINK)
hci_setup_sync(sco, acl->handle);
else
hci_add_sco(sco, acl->handle);
diff -uNr net/bluetooth-orig/sco.c net/bluetooth/sco.c
--- net/bluetooth-orig/sco.c2008-02-25 17:58:27.0 +0900
+++ net/bluetooth/sco.c 2008-02-25 18:08:51.0 +0900
@@ -200,7 +200,10 @@
err = -ENOMEM;
- type = lmp_esco_capable(hdev) ? ESCO_LINK : SCO_LINK;
+ if (sco_pi(sk)->force_sco)
+ type = SCO_LINK;
+ else
+ type = lmp_esco_capable(hdev) ? ESCO_LINK : SCO_LINK;
hcon = hci_connect(hdev, type, dst);
if (!hcon)
@@ -660,12 +663,21 @@
{
struct sock *sk = sock->sk;
int err = 0;
+ unsigned int force_sco;
BT_DBG("sk %p", sk);
lock_sock(sk);
switch (optname) {
+ case SCO_FORCESCO:
+ if (copy_from_user((char *)&force_sco, optval, sizeof(unsigned
int))) {
+ err = -EFAULT;
+ break;
+ }
+ sco_pi(sk)->force_sco = (force_sco != 0);
+ break;
+
default:
err = -ENOPROTOOPT;
break;
@@ -681,6 +693,7 @@
struct sco_options opts;
struct sco_conninfo cinfo;
int len, err = 0;
+ unsigned int force_sco;
BT_DBG("sk %p", sk);
@@ -721,6 +734,13 @@
break;
+ case SCO_FORCESCO:
+ force_sco = sco_pi(sock)->force_sco;
+ if (copy_to_user(optval, (char *)&force_sco, sizeof(unsigned
int)))
+ err = -EFAULT;
+
+ break;
+
default:
err = -ENOPROTOOPT;
break;
vmlinux.lds cleanup
Hi Sam, you know I've just take a look on different architectures and I suddenly realized that I even can't test my changes I'm bringnin in. For example - xtensa arch, most of lds numeric constants could (and should) be changed to PAGE_SIZE and THREAD_SIZE but this requires to include additional heades in lds script and I'm not even sure if it link without errors... (actually, i'm absolutely sure there would be errors ;) I'm not sure, but maybe it would be more convenient to ask mainteiners fix their scripts? At least their have access to an appropriate hardware to test. - Cyrill - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.25-rc3] cpuidle: fix cpuidle time and usage overflow
cpuidle C-state sysfs node time and usage are very easy to overflow because
they are all of unsigned int type, time will overflow within about two hours,
usage will take longer time to overflow, but they are increasing for ever.
This patch will convert them to unsigned long long.
Signed-off-by: Yi Yang <[EMAIL PROTECTED]>
---
drivers/cpuidle/cpuidle.c |2 +-
drivers/cpuidle/sysfs.c | 10 --
include/linux/cpuidle.h |4 ++--
--- a/include/linux/cpuidle.h 2008-02-25 02:31:26.0 -0500
+++ b/include/linux/cpuidle.h 2008-02-25 04:30:24.0 -0500
@@ -38,8 +38,8 @@ struct cpuidle_state {
unsigned intpower_usage; /* in mW */
unsigned inttarget_residency; /* in US */
- unsigned intusage;
- unsigned inttime; /* in US */
+ unsigned long long usage;
+ unsigned long long time; /* in US */
int (*enter)(struct cpuidle_device *dev,
struct cpuidle_state *state);
--- a/drivers/cpuidle/cpuidle.c 2008-02-25 02:37:14.0 -0500
+++ b/drivers/cpuidle/cpuidle.c 2008-02-25 04:29:19.0 -0500
@@ -67,7 +67,7 @@ static void cpuidle_idle_call(void)
/* enter the state and update stats */
dev->last_residency = target_state->enter(dev, target_state);
dev->last_state = target_state;
- target_state->time += dev->last_residency;
+ target_state->time += (unsigned long long)dev->last_residency;
target_state->usage++;
/* give the governor an opportunity to reflect on the outcome */
--- a/drivers/cpuidle/sysfs.c 2008-02-25 02:33:14.0 -0500
+++ b/drivers/cpuidle/sysfs.c 2008-02-25 03:10:50.0 -0500
@@ -218,6 +218,12 @@ static ssize_t show_state_##_name(struct
return sprintf(buf, "%u\n", state->_name);\
}
+#define define_show_state_ull_function(_name) \
+static ssize_t show_state_##_name(struct cpuidle_state *state, char *buf) \
+{ \
+ return sprintf(buf, "%llu\n", state->_name);\
+}
+
#define define_show_state_str_function(_name) \
static ssize_t show_state_##_name(struct cpuidle_state *state, char *buf) \
{ \
@@ -228,8 +234,8 @@ static ssize_t show_state_##_name(struct
define_show_state_function(exit_latency)
define_show_state_function(power_usage)
-define_show_state_function(usage)
-define_show_state_function(time)
+define_show_state_ull_function(usage)
+define_show_state_ull_function(time)
define_show_state_str_function(name)
define_show_state_str_function(desc)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bcm43xx regression in 2.6.24 (with patch)
On Monday 25 February 2008 07:49:35 Greg KH wrote: > On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote: > > Hi Michael, > > > > On Sun, 24 Feb 2008, Michael Buesch wrote: > > > > The ony way I see this was possible, you manually changed the > > > > module loading order, so that the b43xx module was loaded prior > > > > to the ssb and b44 modules. Right? > > > > > > Right. So "so I'm left with either no wifi or no ethenet" being wrong. > > > > Lets make this simple: it used to work before and now it doesn't. > > Therefore it's a regression that must be addressed. Period. > > Isn't the resolution Michael is suggesting is, "use the different driver"? I have two resolutions. One being: rmmod b44 rmmod ssb modprobe bcm43xx modprobe b44 The other being: Wait for 2.6.25 and use the maintained b43 driver. -- 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: [PATCH 2.6.25-rc3] cpuidle: fix cpuidle time and usage overflow
* Yi Yang <[EMAIL PROTECTED]> wrote: > cpuidle C-state sysfs node time and usage are very easy to overflow > because they are all of unsigned int type, time will overflow within > about two hours, usage will take longer time to overflow, but they are > increasing for ever. > > This patch will convert them to unsigned long long. what happens if such an overflow happens - any particular regression or other misbehavior, or just funny looking stats in sysfs? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] add a private data field within kobj_attribute structure (final#2)
Greg KH wrote: On Mon, Feb 25, 2008 at 03:57:44PM +0900, Kohei KaiGai wrote: Greg KH wrote: On Mon, Feb 25, 2008 at 03:10:27PM +0900, Kohei KaiGai wrote: [PATCH 1/3] add a private data field within kobj_attribute structure. This patch add a private data field, declared as void *, within kobj_attribute structure. The _show() and _store() method in the sysfs attribute entries can refer this information to identify what entry is accessed. It makes easier to share a single method implementation with several similar entries, like ones to export the list of capabilities the running kernel supports. Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]> -- Documentation/kobject.txt |6 ++ That's good, but you didn't modify the sample/kobject/ file to use the new void pointer, instead of the strcmp() call. The 3/3 of patches updates sample/kobject to use the new void pointer. Do you want it to replace strcmp() examples completly? Doh, I totally missed that one, very sorry. I'll be glad to take patches 1 and 3 in my tree, if you want me to. I want them to be upstreamed, no need to say. BTW, how do you think about the second patch which provides the most practical feature? Thanks for your reviewing. -- OSS Platform Development Division, NEC KaiGai Kohei <[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: [Bluez-devel] forcing SCO connection patch
On Mon, Feb 25, 2008 at 5:28 PM, Louis JANG <[EMAIL PROTECTED]> wrote:
>
> > I ever asked marcel about the coding style. please see following thread:
> > http://lkml.org/lkml/2008/1/22/91
> >
> > I think the style problem marcel said is
> > 1. using kernel codeing style
> > 2. marcel's style
> > container_of or get_user_data calls at the top of the variable declaration
> > using the empty lines to seperate code blocks
> >
> > Please rework your patch and resend if you fixed them.
> >
> > BTW, please use the new bluetooth mailing list for kerne issue.
> > [EMAIL PROTECTED]
> >
> > (Thanks for andrew and davem)
> >
> > Regards
> > dave
> >
> > Regards
> > dave
> >
> >
>
> Hi all,
>
> I adjusted indentation of the patches
Not enough.
Please first read Documentation/CodingStyle, fix them, and
then use scripts/checkpatch.pl to check your patch.
>but I'm not sure what's wrong
> about second comment of Marcel. please let me know if there are another
> problems in this patch.
>
> Thanks in advance,
> Louis JANG
>
>
> --- net/bluetooth/hci_event.c.orig 2008-02-25 17:17:11.0 +0900
> +++ net/bluetooth/hci_event.c 2008-02-25 17:30:23.0 +0900
> @@ -1313,8 +1313,17 @@
> hci_dev_lock(hdev);
>
> conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
> - if (!conn)
> - goto unlock;
> + if (!conn) {
> + if (ev->link_type != ACL_LINK) {
> + __u8 link_type = (ev->link_type == ESCO_LINK) ?
> SCO_LINK : ESCO_LINK;
> +
> + conn = hci_conn_hash_lookup_ba(hdev, link_type,
> &ev->bdaddr);
> + if (conn)
> + conn->type = ev->link_type;
> + }
> + if (!conn)
> + goto unlock;
> + }
>
> if (!ev->status) {
> conn->handle = __le16_to_cpu(ev->handle);
>
> diff -uNr include/net/bluetooth-orig/sco.h include/net/bluetooth/sco.h
> --- include/net/bluetooth-orig/sco.h2007-10-10 05:31:38.0 +0900
> +++ include/net/bluetooth/sco.h 2008-02-25 18:04:20.0 +0900
> @@ -51,6 +51,8 @@
> __u8 dev_class[3];
> };
>
> +#define SCO_FORCESCO 0x03
> +
> /* SCO connections */
> struct sco_conn {
> struct hci_conn *hcon;
> @@ -74,6 +76,7 @@
> struct bt_sock bt;
> __u32 flags;
> struct sco_conn *conn;
> + unsigned intforce_sco :1;
> };
>
> #endif /* __SCO_H */
> diff -uNr net/bluetooth-orig/hci_conn.c net/bluetooth/hci_conn.c
> --- net/bluetooth-orig/hci_conn.c 2008-02-25 17:58:27.0 +0900
> +++ net/bluetooth/hci_conn.c2008-02-25 18:02:04.0 +0900
> @@ -354,7 +354,7 @@
>
> if (acl->state == BT_CONNECTED &&
> (sco->state == BT_OPEN || sco->state == BT_CLOSED)) {
> - if (lmp_esco_capable(hdev))
> + if (type == ESCO_LINK)
> hci_setup_sync(sco, acl->handle);
> else
> hci_add_sco(sco, acl->handle);
> diff -uNr net/bluetooth-orig/sco.c net/bluetooth/sco.c
> --- net/bluetooth-orig/sco.c2008-02-25 17:58:27.0 +0900
> +++ net/bluetooth/sco.c 2008-02-25 18:08:51.0 +0900
> @@ -200,7 +200,10 @@
>
> err = -ENOMEM;
>
> - type = lmp_esco_capable(hdev) ? ESCO_LINK : SCO_LINK;
> + if (sco_pi(sk)->force_sco)
> + type = SCO_LINK;
> + else
> + type = lmp_esco_capable(hdev) ? ESCO_LINK : SCO_LINK;
>
> hcon = hci_connect(hdev, type, dst);
> if (!hcon)
> @@ -660,12 +663,21 @@
> {
> struct sock *sk = sock->sk;
> int err = 0;
> + unsigned int force_sco;
>
> BT_DBG("sk %p", sk);
>
> lock_sock(sk);
>
> switch (optname) {
> + case SCO_FORCESCO:
> + if (copy_from_user((char *)&force_sco, optval,
> sizeof(unsigned int))) {
> + err = -EFAULT;
> + break;
> + }
> + sco_pi(sk)->force_sco = (force_sco != 0);
> + break;
> +
> default:
> err = -ENOPROTOOPT;
> break;
> @@ -681,6 +693,7 @@
> struct sco_options opts;
> struct sco_conninfo cinfo;
> int len, err = 0;
> + unsigned int force_sco;
>
> BT_DBG("sk %p", sk);
>
> @@ -721,6 +734,13 @@
>
> break;
>
> + case SCO_FORCESCO:
> + force_sco = sco_pi(sock)->force_sco;
> + if (copy_to_user(optval, (char *)&force_sco, sizeof(unsigned
> int)))
> + err = -EFAULT;
> +
> + break;
> +
> default:
> err = -ENOPROTOOPT;
> break;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
Re: bcm43xx regression in 2.6.24 (with patch)
On Monday 25 February 2008 11:23:02 Alexey Zaytsev wrote: > On Mon, Feb 25, 2008 at 9:49 AM, Greg KH <[EMAIL PROTECTED]> wrote: > > > > On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote: > > > Hi Michael, > > > > > > On Sun, 24 Feb 2008, Michael Buesch wrote: > > > > > The ony way I see this was possible, you manually changed the > > > > > module loading order, so that the b43xx module was loaded prior > > > > > to the ssb and b44 modules. Right? > > > > > > > > Right. So "so I'm left with either no wifi or no ethenet" being wrong. > > > > > > Lets make this simple: it used to work before and now it doesn't. > > > Therefore it's a regression that must be addressed. Period. > > > > Isn't the resolution Michael is suggesting is, "use the different driver"? > > > > The b43 driver from 2.6.24 does not work with my hardware. The one from > 2.6.25 seems to work, but 2.6.25 is far from being ready yet. > > The only way you can get the old driver working in 2.6.24 is to > compile certain (completely unrelated for an outsider) drivers as > modules and play with the module loading order. I think this is a > bug, and it should be fixed in -stable. It must first go into the 2.6.25 tree and then into -stable. And the patch must be considered to do The Right Thing (tm). > And for 2.6.25, I think the patch should also be included, as the > bcm43xx driver is still there. > > Btw, what are we discussing? The real bcm43xx maintainer > (Larry Finger) reviewed the patch and agreet it should go > into 2.6.24-stable and 2.6.25 . Now we only have to wait for > John Linville and Jeff Garzik to pick it up, right? If someone > still thinks the patch should not go in, he should at least > add them to the CC list. ;) Heh, wait. Larry is neither the bcm43xx maintainer [1], nor does this code touch bcm43xx code. It does touch ssb and b43 code, which I am the maintainer of. Though, as I said, if somebody else is familiar with the code does really understand the patch and does ACK it (which Larry did), I'm probably OK with applying it. As long as I'm not bothered with any followup regressions caused by this. So if the one signing off the patch will handle all this, I'm fine with it. [1] bcm43xx is unmaintained. Larry used to be the maintainer until he dropped it a few months ago. -- 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: [PATCH] Add rdc321x defconfig file
Hi Ingo, Le lundi 25 février 2008, Ingo Molnar a écrit : > hm, i'm not sure. Right now we just have a 32-bit defconfig and a 64-bit > defconfig - but there are about 8 subarchitectures in arch/x86. Given > the amount of variety in PC hardware, i doubt it makes sense to start > collecting defconfigs for hardware variants - we'd end up having > hundreds or thousands of them. Even ARM has only 75 defconfigs. I was answering to Adrian Bunk's email about missing defconfigs for the x86 subarchitecture boards. > > what i do is i regularly test whether "make allyesconfig" boots all the > way up to general user-space in regular whitebox PC hardware. For > example the attached config is such a config, i successfully booted it > on 2.6.25-rc3 on a stock PC. Apart from selecting the 486 instruction subset, everything else should be allright though I had the habit to have a stripped down kernel for testing. > > In fact for rdc321x that should be rather easy to do right now: wdt.c > could/should become a regular watchdog driver, and do we really need > those GPIO specials in include/asm-x86/mach-rdc321x/ ? I believe it > should be possible to boot CONFIG_X86_GENERICARCH on a rdc321x. Am i > missing any particular complication? The GPIO calls will be moving later when I have finished the gpiolib integration for RDC just like what is currently done for ARM. You are right for the watchdog driver, I will move it right now. > > Ingo -- Cordialement, Florian Fainelli -- signature.asc Description: This is a digitally signed message part.
Re: [PATCH][x86] rdc321x: remove watchdog file
Hi Ingo, Le lundi 25 février 2008, Ingo Molnar a écrit : > thanks, applied. I guess i should push this change upstream only once > the new watchdog driver has been committed to drivers/watchdog/ ? Yes it would be better, thank you very much ! signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Add rdc321x defconfig file
Hi Ingo, Le lundi 25 février 2008, Ingo Molnar a écrit : > ok, great! Btw., do you think you could achieve your board to boot fine > with CONFIG_X86_GENERICARCH=y and CONFIG_M486=y? I think it can boot already, will tell you when I have done the necessary testing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Add rdc321x defconfig file
This patch adds the default kernel configuration for the RDC R-321x SoC. Signed-off-by: Florian Fainelli <[EMAIL PROTECTED]> --- diff --git a/arch/x86/configs/rdc321x_defconfig b/arch/x86/configs/rdc321x_defconfig new file mode 100644 index 000..d87e731 --- /dev/null +++ b/arch/x86/configs/rdc321x_defconfig @@ -0,0 +1,1449 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.25-rc2 +# Mon Feb 25 10:42:11 2008 +# +# CONFIG_64BIT is not set +CONFIG_X86_32=y +# CONFIG_X86_64 is not set +CONFIG_X86=y +# CONFIG_GENERIC_LOCKBREAK is not set +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_CLOCKSOURCE_WATCHDOG=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_SEMAPHORE_SLEEPERS=y +CONFIG_FAST_CMPXCHG_LOCAL=y +CONFIG_MMU=y +CONFIG_ZONE_DMA=y +CONFIG_QUICKLIST=y +CONFIG_GENERIC_ISA_DMA=y +CONFIG_GENERIC_IOMAP=y +CONFIG_GENERIC_BUG=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_GPIO=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_DMI=y +# CONFIG_RWSEM_GENERIC_SPINLOCK is not set +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +# CONFIG_GENERIC_TIME_VSYSCALL is not set +CONFIG_ARCH_HAS_CPU_RELAX=y +# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_SUSPEND_POSSIBLE=y +# CONFIG_ZONE_DMA32 is not set +CONFIG_ARCH_POPULATES_NODE_MAP=y +# CONFIG_AUDIT_ARCH is not set +CONFIG_ARCH_SUPPORTS_AOUT=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_X86_BIOS_REBOOT=y +CONFIG_KTIME_SCALAR=y +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=18 +# CONFIG_CGROUPS is not set +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_RELAY=y +CONFIG_NAMESPACES=y +# CONFIG_UTS_NS is not set +# CONFIG_IPC_NS is not set +# CONFIG_USER_NS is not set +# CONFIG_PID_NS is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +# CONFIG_EMBEDDED is not set +CONFIG_UID16=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +CONFIG_KALLSYMS_ALL=y +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_COMPAT_BRK=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_PROFILING=y +# CONFIG_MARKERS is not set +CONFIG_OPROFILE=y +CONFIG_HAVE_OPROFILE=y +CONFIG_KPROBES=y +CONFIG_HAVE_KPROBES=y +CONFIG_PROC_PAGE_MONITOR=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +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 is not set +CONFIG_BLOCK=y +CONFIG_LBD=y +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG 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" +CONFIG_CLASSIC_RCU=y +# CONFIG_PREEMPT_RCU is not set + +# +# Processor type and features +# +CONFIG_TICK_ONESHOT=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y +# CONFIG_SMP is not set +# CONFIG_X86_PC is not set +# 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_X86_RDC321X=y +# CONFIG_X86_VSMP is not set +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +# CONFIG_PARAVIRT_GUEST is not set +# CONFIG_M386 is not set +CONFIG_M486=y +# 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 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_M
The I/O bandwidth controller: dm-ioband Performance Report
Hi All, I report new results of dm-ioband bandwidth control test. The previous test results were posted on Jan 25. I've got really good results as well as the last report. dm-ioband works well with Xen virtual disk. I also announce that dm-ioband website has launched. The patches, the manual, the benchmark results and other related information are available through this site. Please check it out: http://people.valinux.co.jp/~ryov/dm-ioband/ Bandwidth control on a per partition basis == Test procedure -- o Prepare three partitions sda11, sda12 and sda13. o Create three ioband devices ioband1, ioband2 and ioband3 on each partition respectively. o Give weights of 40, 20 and 10 to each ioband device respectively. o Run 50, 100 and 200 processes issuing random read/write direct I/O with 4KB data on each ioband device at the same time respectively. o Count up the number of I/Os which have done in 60 seconds. o For comparison, do this test under different conditions. The conditions are: - Direct access to the physical devices without dm-ioband. - Give weights in equal proportion to each ioband devices. Read/Write process Read/Write process Read/Write process x 50 x 100x 200 ||| +V-+ +V-+ +V-+ | ioband1 | | ioband2 | | ioband3 | ioband devices +--+ +--+ +--+ | default group | | default group | | default group | ioband groups | (40) | | (20) | | (10) | (weight) +|-+ +|-+ +|-+ +V-+ +V-+ +V-+ |/dev/sda11| |/dev/sda12| |/dev/sda13| physical devs. +--+ +--+ +--+ Results --- Direct access without dm-ioband --- | device | sda11 | sda12 | sda13 | | I/O processes |50 (14.3%) | 100 (28.6%) | 200 (57.1%) | |-+-+-+-| | I/Os | 1469 | 2486 | 5032 | | ratio to total | 16.3% | 27.7% | 56.0% | --- Weights in inverse proportion to the number of processes --- | device | sda11 | sda12 | sda13 | | weight | 40 (57.1%)|20 (28.6%) |10 (14.3%) | |-+-+-+-| | I/Os | 5023 | 2654 | 1369 | | ratio to total | 55.5% | 29.3% | 15.1% | --- Weights in equal proportion --- | device | sda11 | sda12 | sda13 | | weight | 10 (33.3%)|10 (33.3%) |10 (33.3%) | |-+-+-+-| | I/Os | 2954 | 3004 | 2986 | | ratio to total | 33.0% | 33.6% | 33.4% | --- Bandwidth control on a per logical volume basis === Test procedure -- o Prepare two partitions sda11 and sdb11. o Create a volume group with the two partitions. o Create two striped logical volumes on the volume group. o Give weights of 20 and 10 to lv0 and lv1 respectively. o Run 128 processes issuing random read/write direct I/O with 4KB data on each ioband device at the same time respectively. o Count up the number of I/Os which have done in 60 seconds. Block diagram - Read/Write process x 128 Read/Write process x 128 | | +-V+ +-V+ | /dev/mapper/ioband1| | /dev/mapper/ioband2| ioband devices +--+ +--+ | default group | | default group | ioband groups | (20) | | (10) |(weight) +-|+ +-|+ +-V+ +-V+ | /dev/mapper/lv0
Re: bcm43xx regression in 2.6.24 (with patch)
On Mon, Feb 25, 2008 at 9:49 AM, Greg KH <[EMAIL PROTECTED]> wrote: > > On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote: > > Hi Michael, > > > > On Sun, 24 Feb 2008, Michael Buesch wrote: > > > > The ony way I see this was possible, you manually changed the > > > > module loading order, so that the b43xx module was loaded prior > > > > to the ssb and b44 modules. Right? > > > > > > Right. So "so I'm left with either no wifi or no ethenet" being wrong. > > > > Lets make this simple: it used to work before and now it doesn't. > > Therefore it's a regression that must be addressed. Period. > > Isn't the resolution Michael is suggesting is, "use the different driver"? > The b43 driver from 2.6.24 does not work with my hardware. The one from 2.6.25 seems to work, but 2.6.25 is far from being ready yet. The only way you can get the old driver working in 2.6.24 is to compile certain (completely unrelated for an outsider) drivers as modules and play with the module loading order. I think this is a bug, and it should be fixed in -stable. And for 2.6.25, I think the patch should also be included, as the bcm43xx driver is still there. Btw, what are we discussing? The real bcm43xx maintainer (Larry Finger) reviewed the patch and agreet it should go into 2.6.24-stable and 2.6.25 . Now we only have to wait for John Linville and Jeff Garzik to pick it up, right? If someone still thinks the patch should not go in, he should at least add them to the CC list. ;) > thanks, > > greg k-h > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.25-rc3] lockdep: add spin_lock_irq_nested()
On Sun, 2008-02-24 at 20:33 -0800, David Brownell wrote: > > > > ==> LOCKDEP feature is evidently missing: > > > > spin_lock_irq_nested(lock_ptr, lock_class) > > > > > > This rant is more lines than adding the API :-/ the reason for it not > > > being there is simple, it wasn't needed up until now. > > > > I suspected that was the case, but for all I knew there was some > > religious objection. > > Does this look about right? Or, I suppose it could just call > the _spin_lock_irqsave_nested() routine and discard the result. Before I look at the code, and with a notice that I haven't had my morning juice yet... It seems to me a spin_lock_irq_nested() thing is redundant, because: The lock must obviously be held hardirq safe and nested implies one is already held. Hence the context is already hardirq safe thus using spin_lock_irq/spin_unlock_irq is wrong because it will enable irqs and destroy the irqsafe guarantee for the parent lock. Obviously I'm missing something here.. otherwise you wouldn't need it. As I'm very much not familiar with the IRQ code, could you spell it out to me? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: dma engine drivers for 2.6.25?
Hi, Sorry for missing lots of emails in my long vacation. :) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dan Williams > Sent: Sunday, February 24, 2008 10:06 AM > To: Kumar Gala > Cc: LKML Kernel; Zhang Wei > Subject: Re: dma engine drivers for 2.6.25? > > On Thu, Feb 14, 2008 at 10:29 PM, Dan Williams > <[EMAIL PROTECTED]> wrote: > > On Thu, Feb 14, 2008 at 8:44 PM, Kumar Gala > <[EMAIL PROTECTED]> wrote: > > > > > > On Feb 14, 2008, at 12:14 PM, Dan Williams wrote: > > > > > > > On Wed, Feb 13, 2008 at 8:52 PM, Kumar Gala > > > > <[EMAIL PROTECTED]> wrote: > > > >> Dan, > > > >> > > > >> What's going on with the dma engine drivers for > 2.6.25? We had a > > > >> Freescale dma driver from Zhang Wei queued up but > seems to have been > > > >> lost. > > > > > > > > I pulled it into my tree and am holding it until Zhang has an > > > > opportunity to address the pending review comments > [1]. I also did > > > > not feel comfortable pushing it to Linus without a > PPC maintainer's > > > > Acked-by/Reviewed-by. > > > > > > > > I have attached the version I am carrying. > > > > > > What issues are still open. I was under the belief > that Zhang had > > > resolved all the issues. > > > > > > > The high priority review item is that the driver performs operation > > completion callbacks in hardirq context. Clients of the API assume > > that callbacks will happen in softirq context. Of lesser > concern is > > the use of GFP_ATOMIC in fsl_dma_alloc_descriptor. Other drivers > > preallocate a small pool of descriptors. > > > > Have not received a response, so let's try this the other way. I took > a closer look and found that my concern should be addressed by the > following one-liner: > > diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c > index 902e852..cc9a681 100644 > --- a/drivers/dma/fsldma.c > +++ b/drivers/dma/fsldma.c > @@ -685,7 +685,6 @@ static irqreturn_t fsl_dma_chan_do_interrupt(int > irq, void *data) > "nlndar 0x%016llx\n", > (u64)get_cdar(fsl_chan), > (u64)get_ndar(fsl_chan)); > stat &= ~FSL_DMA_SR_EOSI; > - fsl_chan_ld_cleanup(fsl_chan); > } > > /* If it current transfer is the end-of-transfer, > > With your ack I'll push the driver plus this fixlet for the > current kernel. I agree with you to remove the fsl_chan_ld_cleanup() function calling in Interrupt action, which is already called in tasklet. I forgot to remove it. Thanks! Cheers! Wei. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.25-rc3] cpuidle: fix cpuidle time and usage overflow
On Mon, 2008-02-25 at 11:15 +0100, Ingo Molnar wrote: > * Yi Yang <[EMAIL PROTECTED]> wrote: > > > cpuidle C-state sysfs node time and usage are very easy to overflow > > because they are all of unsigned int type, time will overflow within > > about two hours, usage will take longer time to overflow, but they are > > increasing for ever. > > > > This patch will convert them to unsigned long long. > > what happens if such an overflow happens - any particular regression or > other misbehavior, or just funny looking stats in sysfs? They are just stats info in sysfs, cpuidle's behaviors don't depend on them. I didn't notice any regression or misbehaviors. > > Ingo > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [patch] fuse: fix permission checking
Hi Greg! > On Fri, Feb 15, 2008 at 11:23:47AM +0100, Miklos Szeredi wrote: > > This is for 2.6.25 and 2.6.24.y, but NOT for 2.6.23.y. > > > > Thanks, > > Miklos > > > > > > From: Miklos Szeredi <[EMAIL PROTECTED]> > > > > I added a nasty local variable shadowing bug to fuse in 2.6.24, with > > the result, that the 'default_permissions' mount option is basically > > ignored. > > When this goes into Linus's tree, can you let us know along with the git > commit id? It's now in Linus tree: commit 1a823ac9ff09cbdf39201df37b7ede1f9395de83 Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [1/3] Don't set up early exception handlers for external interrupts
All of early setup runs with interrupts disabled, so there is no
need to set up early exception handlers for vectors >= 32
That saves some text size
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/kernel/head64.c |2 +-
arch/x86/kernel/head_64.S |6 ++
include/asm-x86/segment.h |3 ++-
3 files changed, 5 insertions(+), 6 deletions(-)
Index: linux/arch/x86/kernel/head64.c
===
--- linux.orig/arch/x86/kernel/head64.c
+++ linux/arch/x86/kernel/head64.c
@@ -91,7 +91,7 @@ void __init x86_64_start_kernel(char * r
/* Cleanup the over mapped high alias */
cleanup_highmap();
- for (i = 0; i < IDT_ENTRIES; i++) {
+ for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) {
#ifdef CONFIG_EARLY_PRINTK
set_intr_gate(i, &early_idt_handlers[i]);
#else
Index: linux/include/asm-x86/segment.h
===
--- linux.orig/include/asm-x86/segment.h
+++ linux/include/asm-x86/segment.h
@@ -191,13 +191,14 @@
#define SEGMENT_TI_MASK0x4
#define IDT_ENTRIES 256
+#define NUM_EXCEPTION_VECTORS 32
#define GDT_SIZE (GDT_ENTRIES * 8)
#define GDT_ENTRY_TLS_ENTRIES 3
#define TLS_SIZE (GDT_ENTRY_TLS_ENTRIES * 8)
#ifdef __KERNEL__
#ifndef __ASSEMBLY__
-extern const char early_idt_handlers[IDT_ENTRIES][10];
+extern const char early_idt_handlers[NUM_EXCEPTION_VECTORS][10];
#endif
#endif
Index: linux/arch/x86/kernel/head_64.S
===
--- linux.orig/arch/x86/kernel/head_64.S
+++ linux/arch/x86/kernel/head_64.S
@@ -278,10 +278,8 @@ bad_address:
.globl early_idt_handlers
early_idt_handlers:
- early_idt_tramp 0, 63
- early_idt_tramp 64, 127
- early_idt_tramp 128, 191
- early_idt_tramp 192, 255
+ .set maxe,NUM_EXCEPTION_VECTORS-1
+ early_idt_tramp 0,maxe
#endif
ENTRY(early_idt_handler)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [2/3] Move early exception handlers into init.text
Currently they are in .text.head because the rest of head_64.S. .text.head is not removed as init data, but the early exception handlers should be because they are not needed after early boot of the BP. So move them over. Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> --- arch/x86/kernel/head_64.S |2 ++ 1 file changed, 2 insertions(+) Index: linux/arch/x86/kernel/head_64.S === --- linux.orig/arch/x86/kernel/head_64.S +++ linux/arch/x86/kernel/head_64.S @@ -267,6 +267,7 @@ ENTRY(secondary_startup_64) bad_address: jmp bad_address + .section ".init.text","ax" #ifdef CONFIG_EARLY_PRINTK .macro early_idt_tramp first, last .ifgt \last-\first @@ -325,6 +326,7 @@ early_idt_msg: early_idt_ripmsg: .asciz "RIP %s\n" #endif /* CONFIG_EARLY_PRINTK */ + .previous .balign PAGE_SIZE -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] [3/3] Replace macro recursion with more conventional loop
The early exception handlers are currently set up using a macro recursion. Replace that with a standard loop. Noop patch, just a cleanup. --- arch/x86/kernel/head_64.S | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) Index: linux/arch/x86/kernel/head_64.S === --- linux.orig/arch/x86/kernel/head_64.S +++ linux/arch/x86/kernel/head_64.S @@ -269,18 +269,17 @@ bad_address: .section ".init.text","ax" #ifdef CONFIG_EARLY_PRINTK -.macro early_idt_tramp first, last - .ifgt \last-\first - early_idt_tramp \first, \last-1 - .endif - movl $\last,%esi +.macro early_idt_tramp i + movl $\i,%esi jmp early_idt_handler .endm - .globl early_idt_handlers early_idt_handlers: - .set maxe,NUM_EXCEPTION_VECTORS-1 - early_idt_tramp 0,maxe + i = 0 + .rept NUM_EXCEPTION_VECTORS + early_idt_tramp i + i = i+1 + .endr #endif ENTRY(early_idt_handler) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 11:14:33AM +0100, Ingo Molnar wrote: > > * Florian Fainelli <[EMAIL PROTECTED]> wrote: > > > This patch adds the default kernel configuration for the RDC R-321x > > SoC. > > hm, i'm not sure. Right now we just have a 32-bit defconfig and a 64-bit > defconfig - but there are about 8 subarchitectures in arch/x86. Given > the amount of variety in PC hardware, i doubt it makes sense to start > collecting defconfigs for hardware variants - we'd end up having > hundreds or thousands of them. Even ARM has only 75 defconfigs. What I want is at least one defconfig per subarchitecture for compile tests. And especially considering the original purpose "configuration users can use as a starting point for configuring their kernel" I even wouldn't mind if we had a few dozen x86 defconfigs. > what i do is i regularly test whether "make allyesconfig" boots all the > way up to general user-space in regular whitebox PC hardware. For > example the attached config is such a config, i successfully booted it > on 2.6.25-rc3 on a stock PC. You are testing something completely different here. What I want is that e.g. after fiddling with kernel headers I want an easy way of having much compile coverage. And my script that builds all defconfig's is trivial (although it takes a day to finish). > This way we can ensure that the (near-) totality of the config space is > bootable on regular PCs, and the subarch support is basically just > bootstrap and quirks differences. You miss our headers mess. You remember how your big x86 merge this merge window broke 8 or 9 other architectures? Change one file under include/ and watch how many configurations no longer build. Or other subtle differences between the subarchs that have in the past led to compile errors. I do consider them useful for the way I'm doing kernel tests, and even if you don't consider them that useful can we agree that adding a defconfig is neither a big deal for the subarchitecture maintainer nor imposes any maintainance work on you as maintainer (except for sometimes applying patches adding/updating them)? > Longer term we should get rid of the > subarchitecture distinction altogether and turn them into regular > quirks/callbacks/drivers. >... Generally agreed (with my biggest worry being whether changing CLOCK_TICK_RATE from a compile time constant to a runtime variable has any performance effects). > Ingo cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-next: Tree for Feb 24
Hi Frank, On Mon, 25 Feb 2008 11:12:45 +0100 Frank Seidel <[EMAIL PROTECTED]> wrote: > > Stephen Rothwell wrote: > > I have created today's linux-next tree at > > i bet your $SUBJECT was meant for the Tree for Feb 25, wasn't it? > ;-) Damn! I remembered to reread to body of the mail and forgot to check the subject - one more for the TODO list :-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpDzCRoupIqW.pgp Description: PGP signature
Re: [PATCH] Add rdc321x defconfig file
* Adrian Bunk <[EMAIL PROTECTED]> wrote: > What I want is that e.g. after fiddling with kernel headers I want an > easy way of having much compile coverage. And my script that builds > all defconfig's is trivial (although it takes a day to finish). no, i think you misunderstood me. I do allyesconfig testing to make sure the kernel is still generic enough on PC hardware - not to catch build breakage. What i do against build breakage is randconfig testing. That catches far more build breakage than a few limited number of defconfigs would ever. More defconfigs would just be a constant maintenance drag, they are rather pointless on PC hardware anyway (we'd have to have at least a few hundred of them for it to be meaningful as a "default config") and it does not really solve the problem either. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Change a WARN message in checkpatch
On Mon, Feb 25, 2008 at 10:21:01AM +0330, Paolo Ciarrocchi wrote: > On 2/25/08, Andy Whitcroft > > As we want the messages to be as short as possible, I am leaning towards > > standardising on: > > > > spaces prohibited > > spaces required > > > in that case i would prefer: > space not required > space required "not required" implies that you don't have to have the space, but you can can have it if you want. So I don't think thats quite right either. -apw -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
* Florian Fainelli <[EMAIL PROTECTED]> wrote: > > In fact for rdc321x that should be rather easy to do right now: > > wdt.c could/should become a regular watchdog driver, and do we > > really need those GPIO specials in include/asm-x86/mach-rdc321x/ ? I > > believe it should be possible to boot CONFIG_X86_GENERICARCH on a > > rdc321x. Am i missing any particular complication? > > The GPIO calls will be moving later when I have finished the gpiolib > integration for RDC just like what is currently done for ARM. You are > right for the watchdog driver, I will move it right now. ok, great! Btw., do you think you could achieve your board to boot fine with CONFIG_X86_GENERICARCH=y and CONFIG_M486=y? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bcm43xx regression in 2.6.24 (with patch)
On Mon, 2008-02-25 at 11:38 +0100, Michael Buesch wrote: > [1] bcm43xx is unmaintained. Larry used to be the maintainer until > he dropped it a few months ago. Doesn't that mean that Alexey gets to be the maintainer, as he's the one patching it ? Xav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][x86] rdc321x: remove watchdog file
This driver should be moved to drivers/watchdog so let's
remove the arch/x86/mach-rdc321x/wdt.c file.
Signed-off-by: Florian Fainelli <[EMAIL PROTECTED]>
---
diff --git a/arch/x86/mach-rdc321x/Makefile b/arch/x86/mach-rdc321x/Makefile
index 1faac81..8325b4c 100644
--- a/arch/x86/mach-rdc321x/Makefile
+++ b/arch/x86/mach-rdc321x/Makefile
@@ -1,5 +1,5 @@
#
# Makefile for the RDC321x specific parts of the kernel
#
-obj-$(CONFIG_X86_RDC321X):= gpio.o platform.o wdt.o
+obj-$(CONFIG_X86_RDC321X):= gpio.o platform.o
diff --git a/arch/x86/mach-rdc321x/wdt.c b/arch/x86/mach-rdc321x/wdt.c
deleted file mode 100644
index ec5625a..000
--- a/arch/x86/mach-rdc321x/wdt.c
+++ /dev/null
@@ -1,275 +0,0 @@
-/*
- * RDC321x watchdog driver
- *
- * Copyright (C) 2007 Florian Fainelli <[EMAIL PROTECTED]>
- *
- * This driver is highly inspired from the cpu5_wdt driver
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#define RDC_WDT_MASK 0x8000 /* Mask */
-#define RDC_WDT_EN 0x0080 /* Enable bit */
-#define RDC_WDT_WTI0x0020 /* Generate CPU reset/NMI/WDT on timeout */
-#define RDC_WDT_RST0x0010 /* Reset bit */
-#define RDC_WDT_WIF0x0004 /* WDT IRQ Flag */
-#define RDC_WDT_IRT0x0100 /* IRQ Routing table */
-#define RDC_WDT_CNT0x0001 /* WDT count */
-
-#define RDC_CLS_TMR0x80003844 /* Clear timer */
-
-#define RDC_WDT_INTERVAL (HZ/10+1)
-
-int nowayout = WATCHDOG_NOWAYOUT;
-module_param(nowayout, int, 0);
-MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
-
-static int ticks = 1000;
-
-/* some device data */
-
-static struct {
- struct completion stop;
- volatile int running;
- struct timer_list timer;
- volatile int queue;
- int default_ticks;
- unsigned long inuse;
-} rdc321x_wdt_device;
-
-/* generic helper functions */
-
-static void rdc321x_wdt_trigger(unsigned long unused)
-{
- if (rdc321x_wdt_device.running)
- ticks--;
-
- /* keep watchdog alive */
- outl(RDC_WDT_EN|inl(RDC3210_CFGREG_DATA), RDC3210_CFGREG_DATA);
-
- /* requeue?? */
- if (rdc321x_wdt_device.queue && ticks)
- mod_timer(&rdc321x_wdt_device.timer,
- jiffies + RDC_WDT_INTERVAL);
- else {
- /* ticks doesn't matter anyway */
- complete(&rdc321x_wdt_device.stop);
- }
-
-}
-
-static void rdc321x_wdt_reset(void)
-{
- ticks = rdc321x_wdt_device.default_ticks;
-}
-
-static void rdc321x_wdt_start(void)
-{
- if (!rdc321x_wdt_device.queue) {
- rdc321x_wdt_device.queue = 1;
-
- /* Clear the timer */
- outl(RDC_CLS_TMR, RDC3210_CFGREG_ADDR);
-
- /* Enable watchdog and set the timeout to 81.92 us */
- outl(RDC_WDT_EN|RDC_WDT_CNT, RDC3210_CFGREG_DATA);
-
- mod_timer(&rdc321x_wdt_device.timer,
- jiffies + RDC_WDT_INTERVAL);
- }
-
- /* if process dies, counter is not decremented */
- rdc321x_wdt_device.running++;
-}
-
-static int rdc321x_wdt_stop(void)
-{
- if (rdc321x_wdt_device.running)
- rdc321x_wdt_device.running = 0;
-
- ticks = rdc321x_wdt_device.default_ticks;
-
- return -EIO;
-}
-
-/* filesystem operations */
-
-static int rdc321x_wdt_open(struct inode *inode, struct file *file)
-{
- if (test_and_set_bit(0, &rdc321x_wdt_device.inuse))
- return -EBUSY;
-
- return nonseekable_open(inode, file);
-}
-
-static int rdc321x_wdt_release(struct inode *inode, struct file *file)
-{
- clear_bit(0, &rdc321x_wdt_device.inuse);
- return 0;
-}
-
-static int rdc321x_wdt_ioctl(struct inode *inode, struct file *file,
- unsigned int cmd, unsigned long arg)
-{
- void __user *argp = (void __user *)arg;
- unsigned int value;
- static struct watchdog_info ident = {
- .options = WDIOF_CARDRESET,
- .identity = "RDC321x WDT",
- };
-
- switch (
Re: [PATCH][x86] rdc321x: remove watchdog file
* Florian Fainelli <[EMAIL PROTECTED]> wrote: > This driver should be moved to drivers/watchdog so let's remove the > arch/x86/mach-rdc321x/wdt.c file. thanks, applied. I guess i should push this change upstream only once the new watchdog driver has been committed to drivers/watchdog/ ? (If that's a completely new driver then please Cc: me to the driver submission so that i can track that trigger condition properly.) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bcm43xx regression in 2.6.24 (with patch)
On Monday 25 February 2008 11:49:34 Xavier Bestel wrote: > On Mon, 2008-02-25 at 11:38 +0100, Michael Buesch wrote: > > [1] bcm43xx is unmaintained. Larry used to be the maintainer until > > he dropped it a few months ago. > > Doesn't that mean that Alexey gets to be the maintainer, as he's the one > patching it ? 1) He is not patching it. 2) Yeah, if he likes to be the bcm43xx maintainer, please go for it. -- 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: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 11:51:10AM +0100, Ingo Molnar wrote: > > * Florian Fainelli <[EMAIL PROTECTED]> wrote: > > > > In fact for rdc321x that should be rather easy to do right now: > > > wdt.c could/should become a regular watchdog driver, and do we > > > really need those GPIO specials in include/asm-x86/mach-rdc321x/ ? I > > > believe it should be possible to boot CONFIG_X86_GENERICARCH on a > > > rdc321x. Am i missing any particular complication? > > > > The GPIO calls will be moving later when I have finished the gpiolib > > integration for RDC just like what is currently done for ARM. You are > > right for the watchdog driver, I will move it right now. > > ok, great! Btw., do you think you could achieve your board to boot fine > with CONFIG_X86_GENERICARCH=y and CONFIG_M486=y? Booting it might fine, but CLOCK_TICK_RATE will be wrong... > Ingo cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Add rdc321x defconfig file
Le lundi 25 février 2008, Adrian Bunk a écrit : > Booting it might fine, but CLOCK_TICK_RATE will be wrong... PIT_TICK_RATE is overriden specificaly for R321x in include/asm-x86/timex.h, just like for AMD Elan. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.25-rc2-git 2/2] atmel_tc clocksource/clockevent code
On Sun, 24 Feb 2008 15:42:51 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> > On Fri, 22 Feb 2008 17:28:37 -0800
> > David Brownell <[EMAIL PROTECTED]> wrote:
> >
> > > +static cycle_t tc_get_cycles(void)
> > > +{
> > > + unsigned long flags;
> > > + u32 lower, upper;
> > > +
> > > + raw_local_irq_save(flags);
> >
> > Why do you need to use the raw version?
>
> This is part of the system timer code, and it should never be a
> preemption point. Plus I didn't want to waste any instruction
> cycles in code that runs before e.g. the DBGU IRQ handler would
> get called... observably, such extra cycles *do* hurt.
I don't understand what you mean by preemption point, but I guess the
non-raw version may consume some extra cycles when lockdep is enabled.
> > > +#ifdef CONFIG_GENERIC_CLOCKEVENTS
> > > +#define USE_TC_CLKEVT
> > > +#endif
> > > +
> > > +#ifdef CONFIG_ARCH_AT91RM9200
> > > +/* The AT91rm9200 system timer is a oneshot-capable 32k timer that's
> > > + * always running ... configuring a TC channel to work the same way
> > > + * would just waste some power.
> > > + */
> > > +#undef USE_TC_CLKEVT
> > > +#endif
> > > +
> > > +#ifdef USE_TC_CLKEVT
> >
> > Can't you just use #ifndef CONFIG_ARCH_AT91RM9200 and avoid the whole
> > ifdef/define/undef dance above?
>
> I can't know that some other platform won't have a better system
> timer solution, and didn't want to assume that only that single
> venerable chip had such a solution ... it's kind of puzzling to
> me (software guy) that none of the newest Atmel SOCs have better
> timer infrastructure than they do. ;)
Heh.
If we really expect using TC as a clocksource but not as a clockevent
is going to be a common usage, perhaps we should move the decision into
Kconfig?
Besides, I don't really see the difference between having a big #ifdef
expression around the whole clockevent block and having a big #ifdef
expression around the definition of USE_TC_CLKEVT except that the
latter is more code...
> > > + case CLOCK_EVT_MODE_ONESHOT:
> > > + /* slow clock, count up to RC, then irq and stop */
> >
> > Hmm. Do you really want to stop it? Won't you get better accuracy if
> > you let it run and program the next event as (prev_event + delta)?
>
> No, ONESHOT means "stop after the IRQ I asked for". And when
> tc_next_event() is asked to trigger that IRQ, it's relative to
> the instant it's requested, not relative to the last one that
> was requested (which may not have triggered yet, or may have
> been quite some time ago).
Right. Sounds like it might introduce some inaccuracy, but I guess it's
the clocksource's job to keep track of the actual time at the time of
the event.
> > > +static struct irqaction tc_irqaction = {
> > > + .name = "tc_clkevt",
> > > + .flags = IRQF_TIMER | IRQF_DISABLED,
> > > + .handler= ch2_irq,
> > > +};
> >
> > I don't think you need to define this statically. You can call
> > request_irq() at arch_initcall() time.
>
> That could be done, yes ... and using request_irq()/free_irq()
> would also let this be linked as a module, not just statically.
>
> On the other hand, doing it this way doesn't hurt either does it?
> Unless a modular build is important.
No, it doesn't hurt. Maybe we should keep it static so that we have the
option of initializing it earlier if we need to.
> > I don't think it is safe to assume that one clock per channel always
> > means one irq per channel as well...
>
> On current chips, that's how it works.
Indeed. I just don't see any fundamental reason why it has to work that
way, which is why I don't think we should depend on it.
> > What's wrong with
> >
> > irq = platform_get_irq(pdev, 2);
> > if (irq < 0)
> > irq = platform_get_irq(pdev, 0);
>
> Nothing much, except that I took the more concise path. Got patch?
Not until we reach a conclusion about the tclib core.
> > How about we make tcb_clksrc_init() global and call it from the
> > platform code with whatever TCB the platform thinks is appropriate?
>
> That could work too, but if it goes that way then there's no
> point in changes to support a modular build (e.g. the irqaction
> thing you noted above).
True.
> > Perhaps remove the prompt from ATMEL_TCB_CLKSRC and have the platform
> > select it as well? I certainly want to force this stuff on on the
> > AP7000...otherwise we'll just get lots of complaints that the thing is
> > using 4x more power than it's supposed to...
>
> Well, "force" seems the wrong approach to me. That should be a
> board-specific choice. The ap700x power budget may not be the
> most important system design consideration, so making such a
> decision at the platform ("ap700x") level seems wrong.
>
> Suppose someone has to build an AVR32 based system that uses both
> TCB modules to hook up to external hardware, so that neither one
> is available for use as a "system timer"?
Good point. Let's keep it as it is and let the board "select" it
through
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 12:17:07PM +0100, Ingo Molnar wrote: > > * Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > What I want is that e.g. after fiddling with kernel headers I want an > > easy way of having much compile coverage. And my script that builds > > all defconfig's is trivial (although it takes a day to finish). > > no, i think you misunderstood me. I do allyesconfig testing to make sure > the kernel is still generic enough on PC hardware - not to catch build > breakage. > > What i do against build breakage is randconfig testing. That catches far > more build breakage than a few limited number of defconfigs would ever. How do you test whether a x86 merge might break the compilation of e.g. some ARM platform without using any defconfig? And building all defconfigs is the trivial way of having most reasonable configurations covered with only one day of compile time. > More defconfigs would just be a constant maintenance drag, they are > rather pointless on PC hardware anyway (we'd have to have at least a few > hundred of them for it to be meaningful as a "default config") and it > does not really solve the problem either. My goal was "one per subarchitecture" which is not such a big number. At least for the patches I'm sending more defconfigs reduce the probability of me introducing bugs (and I might e.g. again work a bit on improving our headers mess in the future). > Ingo cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: filesystem corruption on xfs after 2.6.25-rc1 (bisected, powerpc related?)
Hi, > Git reset is just the easiest way to reproduce it. Interesting :) > I was able to track this corruption down to commit > a69b176df246d59626e6a9c640b44c0921fa4566 ([XFS] Use the generic bitops > rather than implementing them ourselves.) using git bisect. > > Reverting edd319dc527733e61eec5bdc9ce20c94634b6482 ([XFS] Fix > xfs_lowbit64) to avoid merge conflicts and the faulty commit on top of > 2.6.25-rc3 fixes the problem. Odd. The replaced code doesn't look like it has any sort of endianness assumptions. > My filesystem is on an LVM2 logical volume and my computer is a > PowerBook G4 (model 5,8). I'm using GCC 4.2.3. > > My problem is similar to the problem Johannes Berg reported in: > http://oss.sgi.com/archives/xfs/2008-02/msg00244.html > > AFAIK Johannes also uses a PowerBook. Indeed, I do, forgot to mention that, thanks for copying me. johannes signature.asc Description: This is a digitally signed message part
Re: [Bluez-devel] forcing SCO connection patch
Dave Young 쓴 글:
> On Mon, Feb 25, 2008 at 5:28 PM, Louis JANG <[EMAIL PROTECTED]> wrote:
>
>> > I ever asked marcel about the coding style. please see following thread:
>> > http://lkml.org/lkml/2008/1/22/91
>> >
>> > I think the style problem marcel said is
>> > 1. using kernel codeing style
>> > 2. marcel's style
>> > container_of or get_user_data calls at the top of the variable declaration
>> > using the empty lines to seperate code blocks
>> >
>> > Please rework your patch and resend if you fixed them.
>> >
>> > BTW, please use the new bluetooth mailing list for kerne issue.
>> > [EMAIL PROTECTED]
>> >
>> > (Thanks for andrew and davem)
>> >
>> > Regards
>> > dave
>> >
>> > Regards
>> > dave
>> >
>> >
>>
>> Hi all,
>>
>> I adjusted indentation of the patches
>>
>
> Not enough.
>
> Please first read Documentation/CodingStyle, fix them, and
> then use scripts/checkpatch.pl to check your patch.
>
I fixed all of errors except 80 characters warning.
Thanks
Louis JANG
Signed-off-by: Louis JANG <[EMAIL PROTECTED]>
--- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-25 17:17:11.0
+0900
+++ linux-2.6.23/net/bluetooth/hci_event.c 2008-02-25 17:30:23.0
+0900
@@ -1313,8 +1313,17 @@
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
- if (!conn)
- goto unlock;
+ if (!conn) {
+ if (ev->link_type != ACL_LINK) {
+ __u8 link_type = (ev->link_type == ESCO_LINK) ?
SCO_LINK : ESCO_LINK;
+
+ conn = hci_conn_hash_lookup_ba(hdev, link_type,
&ev->bdaddr);
+ if (conn)
+ conn->type = ev->link_type;
+ }
+ if (!conn)
+ goto unlock;
+ }
if (!ev->status) {
conn->handle = __le16_to_cpu(ev->handle);
Signed-off-by: Louis JANG <[EMAIL PROTECTED]>
diff -uNr linux-2.6.23/include/net/bluetooth-orig/sco.h
linux-2.6.23/include/net/bluetooth/sco.h
--- linux-2.6.23/include/net/bluetooth-orig/sco.h 2007-10-10
05:31:38.0 +0900
+++ linux-2.6.23/include/net/bluetooth/sco.h2008-02-25 18:04:20.0
+0900
@@ -51,6 +51,8 @@
__u8 dev_class[3];
};
+#define SCO_FORCESCO 0x03
+
/* SCO connections */
struct sco_conn {
struct hci_conn *hcon;
@@ -74,6 +76,7 @@
struct bt_sock bt;
__u32 flags;
struct sco_conn *conn;
+ unsigned intforce_sco :1;
};
#endif /* __SCO_H */
diff -uNr linux-2.6.23/net/bluetooth-orig/hci_conn.c
linux-2.6.23/net/bluetooth/hci_conn.c
--- linux-2.6.23/net/bluetooth-orig/hci_conn.c 2008-02-25 17:58:27.0
+0900
+++ linux-2.6.23/net/bluetooth/hci_conn.c 2008-02-25 18:02:04.0
+0900
@@ -354,7 +354,7 @@
if (acl->state == BT_CONNECTED &&
(sco->state == BT_OPEN || sco->state == BT_CLOSED)) {
- if (lmp_esco_capable(hdev))
+ if (type == ESCO_LINK)
hci_setup_sync(sco, acl->handle);
else
hci_add_sco(sco, acl->handle);
diff -uNr linux-2.6.23/net/bluetooth-orig/sco.c linux-2.6.23/net/bluetooth/sco.c
--- linux-2.6.23/net/bluetooth-orig/sco.c 2008-02-25 17:58:27.0
+0900
+++ linux-2.6.23/net/bluetooth/sco.c2008-02-25 18:08:51.0 +0900
@@ -200,7 +200,10 @@
err = -ENOMEM;
- type = lmp_esco_capable(hdev) ? ESCO_LINK : SCO_LINK;
+ if (sco_pi(sk)->force_sco)
+ type = SCO_LINK;
+ else
+ type = lmp_esco_capable(hdev) ? ESCO_LINK : SCO_LINK;
hcon = hci_connect(hdev, type, dst);
if (!hcon)
@@ -660,12 +663,21 @@
{
struct sock *sk = sock->sk;
int err = 0;
+ int force_sco;
BT_DBG("sk %p", sk);
lock_sock(sk);
switch (optname) {
+ case SCO_FORCESCO:
+ if (copy_from_user(&force_sco, optval, sizeof(int))) {
+ err = -EFAULT;
+ break;
+ }
+ sco_pi(sk)->force_sco = (force_sco != 0);
+ break;
+
default:
err = -ENOPROTOOPT;
break;
@@ -681,6 +693,7 @@
struct sco_options opts;
struct sco_conninfo cinfo;
int len, err = 0;
+ int force_sco;
BT_DBG("sk %p", sk);
@@ -721,6 +734,13 @@
break;
+ case SCO_FORCESCO:
+ force_sco = sco_pi(sock)->force_sco;
+ if (copy_to_user(optval, &force_sco, sizeof(int)))
+ err = -EFAULT;
+
+ break;
+
default:
err = -ENOPROTOOPT;
break;
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Monday, 25 of February 2008, Alan Stern wrote: > On Sun, 24 Feb 2008, Pavel Machek wrote: > > > > > At the very least, you'd need rmb() before reading it and wmb() after > > > > writing to it, but I'm not sure if that's enough on every obscure > > > > architecture out there. > > > > > > No, neither one is needed because of the way suspending_task is used. > > > > > > It's not necessary for a reader R to see the variable's actual value; > > > all R needs to know is whether or not suspending_task is equal to R. > > > Since the only process which can set suspending_task to R is R itself, > > > and since R will set suspending_task back to NULL before releasing the > > > write lock on pm_sleep_rwsem, there's never any ambiguity. > > > > Subtle. > > > > Very subtly wrong ;-). > > > > imagine suspending_task == 0xabcdef01. Now task "R" with current == > > 0xabcd reads suspending_task while the other cpu is writing to it, > > and sees 0xabcd (0xef01 was not yet written) -- and mistakenly > > believes that "R" == suspending_task. > > I always thought that reads and writes of pointers are atomic, just > like reads and writes of longs. Is that wrong? That depends on the architecture. It may be wrong on alpha, IIRC. > Now if pointers were the same size as long long then I would agree with > you. That certainly is true on x86-64. On alpha probably too. > > I agree it is very unlikely, and it will not happen on i386. But what > > about just using atomic_t suspending_task, and store current->pid into > > it? > > That would work just as well. Except that it wouldn't need to be > atomic_t, because current->pid is always an integer (not guaranteed, I > suppose, but that's what it is on all current architectures) and > reads/writes of ints _are_ atomic. That also depends on the arch, I'm afraid, and in general if we assume something to be atomic, it's better to make the code reflect that assumption. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Monday, 25 of February 2008, Alan Stern wrote: > On Sun, 24 Feb 2008, Rafael J. Wysocki wrote: > > > > Very subtly wrong ;-). > > > > > > imagine suspending_task == 0xabcdef01. Now task "R" with current == > > > 0xabcd reads suspending_task while the other cpu is writing to it, > > > and sees 0xabcd (0xef01 was not yet written) -- and mistakenly > > > believes that "R" == suspending_task. > > > > > > I agree it is very unlikely, and it will not happen on i386. But what > > > about just using atomic_t suspending_task, and store current->pid into > > > it? > > > > I'd rather use a lock, frankly. For example, we can require the readers to > > take pm_sleep_rwsem for reading in order to access that. > > That certainly won't work. Imagine what would happen when the reader > _was_ the suspending task. Yeah, I've already realized it was a stupid idea. :-) > But if you really twist my arm, I'll go along with Pavel's suggestion. So can you do that, pretty please? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.25-rc2-git 1/2] atmel_tc library
On Sun, 24 Feb 2008 17:03:10 -0800 David Brownell <[EMAIL PROTECTED]> wrote: > > Which reminds me...you were talking about a patch that adds oneshot > > support for the count/compare clocksource and more cleanups, but I > > don't think I've seen it...? > > I avoid sending non-working patches, and hadn't made time to > work on that issue recently. I was thinking that I could perhaps help you get it working... > > But I was thinking about Linus' suggestions that we exploit the > > distributed nature of git and do cross-tree merges to synchronize > > changes to common code. > > > > Setting up a separate git tree would allow the changes to go into the > > arm tree without littering it with possibly unstable avr32 changes as > > well, and it would allow me to merge them and put more stuff on top. > > Doing that with ARM patches is Russell's call; he hasn't been too > keen on merging from non-Linus GIT trees when that came up before. Fine with me either way. > > I've never really seen the point of indenting those defines at all. > > Without them, it's harder to discern the logical structure of > all the various bitfields and their contents. I prefer to separate the registers from the bitfields and the other stuff. That way, no indentation is necessary. > > I thought about that, but while the driver can safely call clk_enable() > > on the same clock several times, I'm not sure if it's such a great idea > > to call request_irq() on the same interrupt several times. So the > > driver probably needs to know how many irqs there really are and might > > as well use platform_get_irq() to find out. > > I thought the whole point of passing the clocks was to avoid needing > to ask for them!! If trying one or three platform_get_irq() calls is > OK, then surely trying one or three clk_get() calls is also OK... If you want to go down that path, surely reserving the iomem resource is fine too? Why don't we just kill the whole tclib layer, the driver can certainly do everything itself? Of course the driver should be responsible for calling clk_enable() and clk_disable(). Otherwise, power management will be tricky. And since the driver may need to make a decision about which interrupts to request, it might as well call platform_get_irq() directly. On the other hand, the driver will _always_ need a reference to each clock, and it will always need a pointer through which to access the registers, so the mid-layer might as well do those things. Haavard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 12:27:34PM +0100, Florian Fainelli wrote: > Le lundi 25 février 2008, Adrian Bunk a écrit : > > Booting it might fine, but CLOCK_TICK_RATE will be wrong... > > PIT_TICK_RATE is overriden specificaly for R321x in include/asm-x86/timex.h, > just like for AMD Elan. Not when you try CONFIG_X86_GENERICARCH=y as Ingo suggested. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 Regression Thinkpad acpi
On Monday, 25 of February 2008, Lukas Hejtmanek wrote: > Hello, Hi, Thanks for the report. > 2.6.25-rc2-git7 has regression, thinkpad keys do not work any more. > > Probably this commit broke things 6c231bd5eb07ce546517019f334652b9ecfc329a Please always provide the commit subject along with the hash in bug reports. Also, CCing the author and the relevant list on a report usually is a good idea. :-) Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
* Adrian Bunk <[EMAIL PROTECTED]> wrote: > > What i do against build breakage is randconfig testing. That catches > > far more build breakage than a few limited number of defconfigs > > would ever. > > How do you test whether a x86 merge might break the compilation of > e.g. some ARM platform without using any defconfig? yes, we do test that too. (we added this recently) > And building all defconfigs is the trivial way of having most > reasonable configurations covered with only one day of compile time. the existing 32-bit and 64-bit defconfigs should be enough for that. For better/full coverage, randconfig should be used. > > More defconfigs would just be a constant maintenance drag, they are > > rather pointless on PC hardware anyway (we'd have to have at least a > > few hundred of them for it to be meaningful as a "default config") > > and it does not really solve the problem either. > > My goal was "one per subarchitecture" which is not such a big number. at least on x86 subarchitectures are not at all that important (they are a rather inflexible build-time concept), and as you have seen it in this thread, we are working on reducing their count. 99% of the real hardware is covered under the generic subarchitecture. they are more important on other (mostly embedded) platforms, with ARM having 75 defconfigs. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
* Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Mon, Feb 25, 2008 at 12:27:34PM +0100, Florian Fainelli wrote: > > Le lundi 25 février 2008, Adrian Bunk a écrit : > > > Booting it might fine, but CLOCK_TICK_RATE will be wrong... > > > > PIT_TICK_RATE is overriden specificaly for R321x in > > include/asm-x86/timex.h, just like for AMD Elan. > > Not when you try CONFIG_X86_GENERICARCH=y as Ingo suggested. good point. The clean solution would be to make PIT_TICK_RATE/CLOCK_TICK_RATE a variable that defaults to 1193182 on x86, and which an early quirk would set to 1189200 on AMD Elan and to 1041667 on RDC321X. likewise, other subarch details should be turned into specific drivers or specific quirks as well. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
filesystem corruption on xfs after 2.6.25-rc1 (bisected, powerpc related?)
Hi Since upgrading to 2.6.25-rc1 I see filesystem corruption on my XFS filesystem. I can reproduce this by doing "git reset --hard v2.6.25-rc1" on a git checkout which is on some other revision. Git outputs strange error messages (like file xxx is a directory when xxx really is a file) and sometimes the filesystem "hangs" (I can no longer do any operations on it even from another shell). If I reboot with a working kernel and check the filesystem xfs_check reports many errors. I also see the problem when doing other (not related to git) operations on the filesystem. Git reset is just the easiest way to reproduce it. I was able to track this corruption down to commit a69b176df246d59626e6a9c640b44c0921fa4566 ([XFS] Use the generic bitops rather than implementing them ourselves.) using git bisect. Reverting edd319dc527733e61eec5bdc9ce20c94634b6482 ([XFS] Fix xfs_lowbit64) to avoid merge conflicts and the faulty commit on top of 2.6.25-rc3 fixes the problem. My filesystem is on an LVM2 logical volume and my computer is a PowerBook G4 (model 5,8). I'm using GCC 4.2.3. My problem is similar to the problem Johannes Berg reported in: http://oss.sgi.com/archives/xfs/2008-02/msg00244.html AFAIK Johannes also uses a PowerBook. Maybe this is an endianness issue. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-next: Tree for Feb 24
Hi!
> > velocity_suspend() seems to be at fault.
>
> (gdb) l *(velocity_suspend+0x37)
> 0xc0244665 is in velocity_suspend (drivers/net/via-velocity.c:3399).
> 3394 if(!netif_running(vptr->dev))
> 3395 return 0;
> 3396
> 3397 netif_device_detach(vptr->dev);
> 3398
> 3399 spin_lock_irqsave(&vptr->lock, flags);
> 3400 pci_save_state(pdev);
> 3401 #ifdef ETHTOOL_GWOL
> 3402 if (vptr->flags & VELOCITY_FLAGS_WOL_ENABLED) {
> 3403 velocity_get_ip(vptr);
> (gdb)
> 3404 velocity_save_context(vptr, &vptr->context);
> 3405 velocity_shutdown(vptr);
> 3406 velocity_set_wol(vptr);
> 3407 pci_enable_wake(pdev, PCI_D3hot, 1);
> 3408 pci_set_power_state(pdev, PCI_D3hot);
> 3409 } else {
> 3410 velocity_save_context(vptr, &vptr->context);
> 3411 velocity_shutdown(vptr);
> 3412 pci_disable_device(pdev);
> 3413 pci_set_power_state(pdev, pci_choose_state(pdev,
> state));
> (gdb)
> 3414 }
> 3415 #else
> 3416 pci_set_power_state(pdev, pci_choose_state(pdev, state));
> 3417 #endif
> 3418 spin_unlock_irqrestore(&vptr->lock, flags);
> 3419 return 0;
> 3420 }
>
> So velocity_suspend calls spin_lock_irqsave, and then pci_set_power_state
> which msleep()s. Is that the root problem here? (I've added Ingo & Peter to
> the CC list since they may have some comments on the scheduler/lockdep parts
> of the trace).
Looks like velocity is broken. Can you try to unload it before sleep
to see if the rest of suspend works for you?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.25-rc3] lockdep: add spin_lock_irq_nested()
> > > > > ==> LOCKDEP feature is evidently missing:
> > > > > spin_lock_irq_nested(lock_ptr, lock_class)
> > > >
> > > > This rant is more lines than adding the API :-/ the reason for it not
> > > > being there is simple, it wasn't needed up until now.
> > >
> > > I suspected that was the case, but for all I knew there was some
> > > religious objection.
> >
> > Does this look about right? Or, I suppose it could just call
> > the _spin_lock_irqsave_nested() routine and discard the result.
>
> Before I look at the code, and with a notice that I haven't had my
> morning juice yet...
>
> It seems to me a spin_lock_irq_nested() thing is redundant, because:
>
> The lock must obviously be held hardirq safe and nested implies one is
> already held.
I thought the way to use the *_nested() calls was "consistently"!
That is, if one instance of a lock access uses it, they all should,
since that's the only way lockdep learns about equivalence classes.
Also, locks shouldn't move between those equivalence classes... so
the raw lockdep data stays correct.
The IRQ framework uses spin_lock_irq() in only one place that I saw:
in kernel/irq/autoprobe.c for the probe_irq_{on,off,mask}() calls.
Those calls will grab locks at their "top level", and then the
irqchip methods they call might need to grab locks for other irqs.
Potential example: chip->startup() and chip->shutdown() could
need to ensure a *parent* controller starts/stops, and that should
involve mutual exclusion using the parent's irq lock (as well as
the child's). So the chip and its parent should be in different
lock classes, else lockdep will wrongly warn of recursion.
> Hence the context is already hardirq safe thus using
> spin_lock_irq/spin_unlock_irq is wrong because it will enable irqs and
> destroy the irqsafe guarantee for the parent lock.
That's not how the autoprobe() stuff works. The other calls in
the genirq framework don't use the *_irq() variants though, so
your intuition is right there. (Only the autoprobe paths had
the FIXME comments in that patch I sent earlier, related to the
lack of the $SUBJECT primitive.)
> Obviously I'm missing something here.. otherwise you wouldn't need it.
>
> As I'm very much not familiar with the IRQ code, could you spell it out
> to me?
The probe_irq_*() calls are made from task context, not hardirq
context, but they access the same locks involved in IRQ management
and processing. So either they need to pass the same lock class
annodations to lockdep, or there's something that's unusually
counter-intuitive going on with respect to those annotations in
simple tree data structures.
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Memory controller rename to Memory Resource Controller
Rename Memory Controller to Memory Resource Controller. Reflect the same
changes in the CONFIG definition for the Memory Resource Controller.
Group together the config options for Resource Counters and Memory
Resource Controller.
This code has been compile tested with the Memory Resource Controller on and
off.
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
Documentation/controllers/memory.txt |8 ++--
include/linux/cgroup_subsys.h|2 +-
include/linux/memcontrol.h |4 ++--
include/linux/mm_types.h |4 ++--
init/Kconfig | 30 +++---
mm/Makefile |2 +-
mm/oom_kill.c|2 +-
mm/vmscan.c |4 ++--
8 files changed, 30 insertions(+), 26 deletions(-)
diff -puN Documentation/controllers/memory.txt~memory-controller-naming-fixes
Documentation/controllers/memory.txt
---
linux-2.6.25-rc3/Documentation/controllers/memory.txt~memory-controller-naming-fixes
2008-02-25 14:22:36.0 +0530
+++ linux-2.6.25-rc3-balbir/Documentation/controllers/memory.txt
2008-02-25 14:53:49.0 +0530
@@ -1,4 +1,8 @@
-Memory Controller
+Memory Resource Controller
+
+NOTE: The Memory Resource Controller has been generically been referred
+to as the memory controller in this document. Do not confuse memory controller
+used here with the memory controller that is used in hardware.
Salient features
@@ -152,7 +156,7 @@ The memory controller uses the following
a. Enable CONFIG_CGROUPS
b. Enable CONFIG_RESOURCE_COUNTERS
-c. Enable CONFIG_CGROUP_MEM_CONT
+c. Enable CONFIG_CGROUP_MEM_RES_CTLR
1. Prepare the cgroups
# mkdir -p /cgroups
diff -puN init/Kconfig~memory-controller-naming-fixes init/Kconfig
--- linux-2.6.25-rc3/init/Kconfig~memory-controller-naming-fixes
2008-02-25 14:22:36.0 +0530
+++ linux-2.6.25-rc3-balbir/init/Kconfig2008-02-25 15:03:43.0
+0530
@@ -366,6 +366,21 @@ config RESOURCE_COUNTERS
infrastructure that works with cgroups
depends on CGROUPS
+config CGROUP_MEM_RES_CTLR
+ bool "Memory Resource Controller for Control Groups"
+ depends on CGROUPS && RESOURCE_COUNTERS
+ help
+ Provides a memory resource controller that manages both page cache and
+ RSS memory.
+
+ Note that setting this option increases fixed memory overhead
+ associated with each page of memory in the system by 4/8 bytes
+ and also increases cache misses because struct page on many 64bit
+ systems will not fit into a single cache line anymore.
+
+ Only enable when you're ok with these trade offs and really
+ sure you need the memory resource controller.
+
config SYSFS_DEPRECATED
bool "Create deprecated sysfs files"
depends on SYSFS
@@ -387,21 +402,6 @@ config SYSFS_DEPRECATED
If you are using a distro that was released in 2006 or later,
it should be safe to say N here.
-config CGROUP_MEM_CONT
- bool "Memory controller for cgroups"
- depends on CGROUPS && RESOURCE_COUNTERS
- help
- Provides a memory controller that manages both page cache and
- RSS memory.
-
- Note that setting this option increases fixed memory overhead
- associated with each page of memory in the system by 4/8 bytes
- and also increases cache misses because struct page on many 64bit
- systems will not fit into a single cache line anymore.
-
- Only enable when you're ok with these trade offs and really
- sure you need the memory controller.
-
config PROC_PID_CPUSET
bool "Include legacy /proc//cpuset file"
depends on CPUSETS
diff -puN include/linux/memcontrol.h~memory-controller-naming-fixes
include/linux/memcontrol.h
--- linux-2.6.25-rc3/include/linux/memcontrol.h~memory-controller-naming-fixes
2008-02-25 14:22:36.0 +0530
+++ linux-2.6.25-rc3-balbir/include/linux/memcontrol.h 2008-02-25
15:55:44.0 +0530
@@ -25,7 +25,7 @@ struct page_cgroup;
struct page;
struct mm_struct;
-#ifdef CONFIG_CGROUP_MEM_CONT
+#ifdef CONFIG_CGROUP_MEM_RES_CTLR
extern void mm_init_cgroup(struct mm_struct *mm, struct task_struct *p);
extern void mm_free_cgroup(struct mm_struct *mm);
@@ -72,7 +72,7 @@ extern long mem_cgroup_calc_reclaim_acti
extern long mem_cgroup_calc_reclaim_inactive(struct mem_cgroup *mem,
struct zone *zone, int priority);
-#else /* CONFIG_CGROUP_MEM_CONT */
+#else /* CONFIG_CGROUP_MEM_RES_CTLR */
static inline void mm_init_cgroup(struct mm_struct *mm,
struct task_struct *p)
{
diff -puN mm/memcontrol.c~memory-controller-naming-fixes mm/memcontrol.c
diff -puN mm/vmscan.c~memory-controller-naming-fixes mm/vmscan.c
--- linux-2.6.25-rc3/mm/vmscan.c~memory-controller-naming-fixes 2008-02-25
14:22:36.000
[PATCH] Memory Resource Controller Add Boot Option
A boot option for the memory controller was discussed on lkml. It is a good
idea to add it, since it saves memory for people who want to turn off the
memory controller.
By default the option is on for the following two reasons
1. It provides compatibility with the current scheme where the memory
controller turns on if the config option is enabled
2. It allows for wider testing of the memory controller, once the config
option is enabled
We still allow the create, destroy callbacks to succeed, since they are
not aware of boot options. We do not populate the directory will
memory resource controller specific files.
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |2 ++
mm/memcontrol.c | 33 -
2 files changed, 34 insertions(+), 1 deletion(-)
diff -L mm/memcontrol.h -puN /dev/null /dev/null
diff -puN include/linux/memcontrol.h~memory-controller-add-boot-option
include/linux/memcontrol.h
diff -puN mm/memcontrol.c~memory-controller-add-boot-option mm/memcontrol.c
--- linux-2.6.25-rc3/mm/memcontrol.c~memory-controller-add-boot-option
2008-02-25 15:55:58.0 +0530
+++ linux-2.6.25-rc3-balbir/mm/memcontrol.c 2008-02-25 17:10:50.0
+0530
@@ -35,6 +35,7 @@
struct cgroup_subsys mem_cgroup_subsys;
static const int MEM_CGROUP_RECLAIM_RETRIES = 5;
+static int mem_cgroup_on __read_mostly = 1;/* turned on/off */
/*
* Statistics for memory cgroup.
@@ -578,6 +579,9 @@ static int mem_cgroup_charge_common(stru
unsigned long nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
struct mem_cgroup_per_zone *mz;
+ if (!mem_cgroup_on)
+ return 0;
+
/*
* Should page_cgroup's go to their own slab?
* One could optimize the performance of the charging routine
@@ -729,7 +733,7 @@ void mem_cgroup_uncharge(struct page_cgr
/*
* Check if our page_cgroup is valid
*/
- if (!pc)
+ if (!pc || !mem_cgroup_on)
return;
if (atomic_dec_and_test(&pc->ref_cnt)) {
@@ -755,6 +759,9 @@ void mem_cgroup_uncharge(struct page_cgr
void mem_cgroup_uncharge_page(struct page *page)
{
+ if (!mem_cgroup_on)
+ return;
+
lock_page_cgroup(page);
mem_cgroup_uncharge(page_get_page_cgroup(page));
unlock_page_cgroup(page);
@@ -769,6 +776,10 @@ int mem_cgroup_prepare_migration(struct
{
struct page_cgroup *pc;
int ret = 0;
+
+ if (!mem_cgroup_on)
+ return 0;
+
lock_page_cgroup(page);
pc = page_get_page_cgroup(page);
if (pc && atomic_inc_not_zero(&pc->ref_cnt))
@@ -781,6 +792,9 @@ void mem_cgroup_end_migration(struct pag
{
struct page_cgroup *pc;
+ if (!mem_cgroup_on)
+ return;
+
lock_page_cgroup(page);
pc = page_get_page_cgroup(page);
mem_cgroup_uncharge(pc);
@@ -881,6 +895,10 @@ int mem_cgroup_force_empty(struct mem_cg
{
int ret = -EBUSY;
int node, zid;
+
+ if (!mem_cgroup_on)
+ return 0;
+
css_get(&mem->css);
/*
* page reclaim code (kswapd etc..) will move pages between
@@ -1141,6 +1159,9 @@ static void mem_cgroup_destroy(struct cg
static int mem_cgroup_populate(struct cgroup_subsys *ss,
struct cgroup *cont)
{
+ if (!mem_cgroup_on)
+ return 0;
+
return cgroup_add_files(cont, ss, mem_cgroup_files,
ARRAY_SIZE(mem_cgroup_files));
}
@@ -1153,6 +1174,9 @@ static void mem_cgroup_move_task(struct
struct mm_struct *mm;
struct mem_cgroup *mem, *old_mem;
+ if (!mem_cgroup_on)
+ return;
+
mm = get_task_mm(p);
if (mm == NULL)
return;
@@ -1189,3 +1213,10 @@ struct cgroup_subsys mem_cgroup_subsys =
.attach = mem_cgroup_move_task,
.early_init = 0,
};
+
+static int __init mem_cgroup_startup_disable(char *str)
+{
+ mem_cgroup_on = 0;
+ return 1;
+}
+__setup("memcgroupoff", mem_cgroup_startup_disable);
diff -puN Documentation/kernel-parameters.txt~memory-controller-add-boot-option
Documentation/kernel-parameters.txt
---
linux-2.6.25-rc3/Documentation/kernel-parameters.txt~memory-controller-add-boot-option
2008-02-25 15:55:58.0 +0530
+++ linux-2.6.25-rc3-balbir/Documentation/kernel-parameters.txt 2008-02-25
15:56:01.0 +0530
@@ -1114,6 +1114,8 @@ and is between 256 and 4096 characters.
mem=nopentium [BUGS=X86-32] Disable usage of 4MB pages for kernel
memory.
+ memcgroupoff[KNL] Disable memory resource controller
+
memmap=exactmap [KNL,X86-32,X86_64] Enable setting of an exact
E820 memory map, as specified by the user.
Such memmap=exactmap lines can be constructed based on
_
--
using long instead of atomic_t when only set/read is required (was Re: [Bug 10030] Suspend doesn't work when SD card is inserted)
Hi! Alan thinks that `subj` is correct... > > > > At the very least, you'd need rmb() before reading it and wmb() after > > > > writing to it, but I'm not sure if that's enough on every obscure > > > > architecture out there. > > > > > > No, neither one is needed because of the way suspending_task is used. > > > > > > It's not necessary for a reader R to see the variable's actual value; > > > all R needs to know is whether or not suspending_task is equal to R. > > > Since the only process which can set suspending_task to R is R itself, > > > and since R will set suspending_task back to NULL before releasing the > > > write lock on pm_sleep_rwsem, there's never any ambiguity. > > > > Subtle. > > > > Very subtly wrong ;-). > > > > imagine suspending_task == 0xabcdef01. Now task "R" with current == > > 0xabcd reads suspending_task while the other cpu is writing to it, > > and sees 0xabcd (0xef01 was not yet written) -- and mistakenly > > believes that "R" == suspending_task. > > I always thought that reads and writes of pointers are atomic, just > like reads and writes of longs. Is that wrong? ...but I'm not that sure. Can someone clarify? I guess it only works as long as longs are aligned? Should it be written down to atomic_ops.txt? 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: bcm43xx regression in 2.6.24 (with patch)
On Mon, Feb 25, 2008 at 11:54 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > Isn't the resolution Michael is suggesting is, "use the different driver"? > > I have two resolutions. One being: > rmmod b44 > rmmod ssb > modprobe bcm43xx > modprobe b44 > > The other being: Wait for 2.6.25 and use the maintained b43 driver. Neither of which seem like acceptable solutions for a 2.6.23 -> 2.6.24 _regression_. Or maybe I am just too naive to believe Linus' statement on not letting the kernel regress... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] make /proc/pid/pagemap work with huge pages and return page size
On Sat, Feb 23, 2008 at 10:31:01AM -0800, Dave Hansen wrote:
> > > - 4 bits for the page size, with 0 meaning native page size (4k on x86,
> > > 8k on alpha, ...) and values 1-15 being specific to the architecture
> > > (I used 1 for 2M, 2 for 4M and 3 for 1G for x86)
>
> "Native page size" probably a bad idea. ppc64 can use 64k or 4k for its
> "native" page size and has 16MB large pages (as well as some others).
> To make it even more confusing, you can have a 64k kernel page size with
> 4k mmu mappings!
>
> That said, this is a decent idea as long as we know that nobody will
> ever have more than 16 page sizes.
Then a better way to encode the page size would be returning the page
shift. This would need 6 bits instead of 4, but it would probably be
enough for any 64 bit architecture.
> > This is ok-ish, but I can't say I like it much. Especially the page size
> > field.
> >
> > But I don't really have many ideas here. Perhaps having a bit saying
> > "this entry is really a continuation of the previous one". Then any page
> > size can be trivially represented. This might also make the code on both
> > sides simpler?
I don't like the idea of parsing thousands of entries just to find out
that I'm using a huge page. It would be much better to just get the page
size one way or the other in the first entry one reads.
> > > -static int add_to_pagemap(unsigned long addr, u64 pfn,
> > > +struct ppte {
> > > + uint64_t paddr:58;
> > > + uint64_t psize:4;
> > > + uint64_t swap:1;
> > > + uint64_t present:1;
> > > +};
>
> It'd be nice to keep the current convention, which is to stay away from
> bitfields.
I like them, they make the code much more readable.
> > > +#ifdef CONFIG_X86
> > > + if (pmd_huge(*pmd)) {
> > > + struct ppte ppte = {
> > > + .paddr = pmd_pfn(*pmd) << PAGE_SHIFT,
> > > + .psize = (HPAGE_SHIFT == 22 ?
> > > + PM_PSIZE_4M : PM_PSIZE_2M),
> > > + .swap = 0,
> > > + .present = 1,
> > > + };
> > > +
> > > + for(; addr != end; addr += PAGE_SIZE) {
> > > + err = add_to_pagemap(addr, ppte, pm);
> > > + if (err)
> > > + return err;
> > > + }
> > > + } else
> > > +#endif
>
> It's great to make this support huge pages, but things like this
> probably need their own function. Putting an #ifdef in the middle of
> here makes it a lot harder to read. Just think of when powerpc, ia64
> and x86_64 get their grubby mitts in here. ;)
AFAIK the way huge pages are used on x86 differs much from other
architectures. While on x86 the address translation stops at some upper
table for a huge page, other architectures encode the page size in the
pte (at least the ones I looked at did). So pmd_huge() (and soon
pud_huge()) are very x86-specific and return just 0 on other archs, and
this code would be optimized away for them. All that would be necessary
for other archs is to eventually get the page size from the pte and put
it in the psize field.
The #ifdef could go away if pmd_pfn() was defined as 0 for !x86, it
wouldn't make sense to use it anyway.
--
%SYSTEM-F-ANARCHISM, The operating system has been overthrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bcm43xx regression in 2.6.24 (with patch)
On Monday 25 February 2008 13:11:04 Pekka Enberg wrote: > On Mon, Feb 25, 2008 at 11:54 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > > Isn't the resolution Michael is suggesting is, "use the different > > driver"? > > > > I have two resolutions. One being: > > rmmod b44 > > rmmod ssb > > modprobe bcm43xx > > modprobe b44 > > > > The other being: Wait for 2.6.25 and use the maintained b43 driver. > > Neither of which seem like acceptable solutions for a 2.6.23 -> 2.6.24 > _regression_. Or maybe I am just too naive to believe Linus' statement > on not letting the kernel regress... So, please sign-off the patch that we have, if you think it's right and doesn't cause more regressions. -- Greetings Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched: revert load_balance_monitor()
Subject: sched: revert load_balance_monitor()
The following commit causes a number of serious regressions:
commit 6b2d7700266b9402e12824e11e0099ae6a4a6a79
Author: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
Date: Fri Jan 25 21:08:00 2008 +0100
sched: group scheduler, fix fairness of cpu bandwidth allocation for task
groups
Namely:
- very frequent wakeups on SMP, reported by PowerTop users.
- cacheline trashing on (large) SMP
- some latencies larger than 500ms
While there is a mergeable patch to fix the latter, the former issues
are IMHO not fixable in a manner suitable for .25 (we're at -rc3 now).
Hence I propose to revert this patch and try again for .26.
( minimal revert - leaves most of the code present, just removes the activation
and sysctl interface ).
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
CC: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
include/linux/sched.h |4
kernel/sched.c| 15 ---
kernel/sysctl.c | 18 --
3 files changed, 37 deletions(-)
Index: linux-2.6/include/linux/sched.h
===
--- linux-2.6.orig/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
@@ -1541,10 +1541,6 @@ extern unsigned int sysctl_sched_child_r
extern unsigned int sysctl_sched_features;
extern unsigned int sysctl_sched_migration_cost;
extern unsigned int sysctl_sched_nr_migrate;
-#if defined(CONFIG_FAIR_GROUP_SCHED) && defined(CONFIG_SMP)
-extern unsigned int sysctl_sched_min_bal_int_shares;
-extern unsigned int sysctl_sched_max_bal_int_shares;
-#endif
int sched_nr_latency_handler(struct ctl_table *table, int write,
struct file *file, void __user *buffer, size_t *length,
Index: linux-2.6/kernel/sched.c
===
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -7083,21 +7083,6 @@ void __init sched_init_smp(void)
if (set_cpus_allowed(current, non_isolated_cpus) < 0)
BUG();
sched_init_granularity();
-
-#ifdef CONFIG_FAIR_GROUP_SCHED
- if (nr_cpu_ids == 1)
- return;
-
- lb_monitor_task = kthread_create(load_balance_monitor, NULL,
-"group_balance");
- if (!IS_ERR(lb_monitor_task)) {
- lb_monitor_task->flags |= PF_NOFREEZE;
- wake_up_process(lb_monitor_task);
- } else {
- printk(KERN_ERR "Could not create load balance monitor thread"
- "(error = %ld) \n", PTR_ERR(lb_monitor_task));
- }
-#endif
}
#else
void __init sched_init_smp(void)
Index: linux-2.6/kernel/sysctl.c
===
--- linux-2.6.orig/kernel/sysctl.c
+++ linux-2.6/kernel/sysctl.c
@@ -311,24 +311,6 @@ static struct ctl_table kern_table[] = {
.mode = 0644,
.proc_handler = &proc_dointvec,
},
-#if defined(CONFIG_FAIR_GROUP_SCHED) && defined(CONFIG_SMP)
- {
- .ctl_name = CTL_UNNUMBERED,
- .procname = "sched_min_bal_int_shares",
- .data = &sysctl_sched_min_bal_int_shares,
- .maxlen = sizeof(unsigned int),
- .mode = 0644,
- .proc_handler = &proc_dointvec,
- },
- {
- .ctl_name = CTL_UNNUMBERED,
- .procname = "sched_max_bal_int_shares",
- .data = &sysctl_sched_max_bal_int_shares,
- .maxlen = sizeof(unsigned int),
- .mode = 0644,
- .proc_handler = &proc_dointvec,
- },
-#endif
#endif
{
.ctl_name = CTL_UNNUMBERED,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bcm43xx regression in 2.6.24 (with patch)
On Mon, 25 Feb 2008, Michael Buesch wrote:
> > Neither of which seem like acceptable solutions for a 2.6.23 -> 2.6.24
> > _regression_. Or maybe I am just too naive to believe Linus' statement
> > on not letting the kernel regress...
>
> So, please sign-off the patch that we have, if you think it's right
> and doesn't cause more regressions.
I did look at the patch and can gladly add a:
Reviewed-by: Pekka Enberg <[EMAIL PROTECTED]>
But this seems backwards. It was _your_ commit that broke the setup and
the patch touches a driver _you're_ maintaining.
So can we just revert commit 753f492093da7a40141bfe083073400f518f4c68
("[B44]: port to native ssb support") from 2.6.24 and you can add it back
to 2.6.25 if the problem indeed does go away?
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 12:50:22PM +0100, Ingo Molnar wrote: > > * Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > What i do against build breakage is randconfig testing. That catches > > > far more build breakage than a few limited number of defconfigs > > > would ever. > > > > How do you test whether a x86 merge might break the compilation of > > e.g. some ARM platform without using any defconfig? > > yes, we do test that too. (we added this recently) Really "without using any defconfig"? > > And building all defconfigs is the trivial way of having most > > reasonable configurations covered with only one day of compile time. > > the existing 32-bit and 64-bit defconfigs should be enough for that. For > better/full coverage, randconfig should be used. The two big problems with randconfigs are: - either you build each .config both with and without your patch or you have to manually check which of the failures are caused by your patch - you require at least an order of magnitude more builds for having the same amount of common configurations covered And any solution that only works on x86 (e.g. based on the expectation that all randconfig configurations normally build) is of zero value for me since x86 is only one out of 23 architectures. > > > More defconfigs would just be a constant maintenance drag, they are > > > rather pointless on PC hardware anyway (we'd have to have at least a > > > few hundred of them for it to be meaningful as a "default config") > > > and it does not really solve the problem either. > > > > My goal was "one per subarchitecture" which is not such a big number. > > at least on x86 subarchitectures are not at all that important (they are > a rather inflexible build-time concept), and as you have seen it in this > thread, we are working on reducing their count. 99% of the real hardware > is covered under the generic subarchitecture. > > they are more important on other (mostly embedded) platforms, with ARM > having 75 defconfigs. In my workflow defconfigs are an important part of testing my patches. But that noone cares whether I break other x86 subarchitectures is not really a problem for me. > Ingo cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 10030] Suspend doesn't work when SD card is inserted
On Monday, 25 of February 2008, Zdenek Kabelac wrote: > Hi Hi, [CCs restored, added CC to Dave] > I'm finally going to test some kernel - because I'd been trying it > against the HEAD - but unfortunately it looks like there is something > seriously broken with -rc3 and sata merge - anyway - I'm going to make > a test with this head commit 85b80ebfa4384b8ea30cc1af9617db30319a9ccd > which should be the last one before merge of SATA. > > So I'm going to check this tree with you patch: > pm-remove-locking-from-core.patch If that's the one from http://marc.info/?l=linux-acpi&m=120389632114090&w=2 , please do it. > --- > drivers/base/core.c |8 --- > drivers/base/power/main.c | 97 > +++--- > drivers/usb/core/usb.c|2 > 3 files changed, 8 insertions(+), 99 deletions(-) > > Do you wan to test also the other patch ? Yes. Please also test the patch that Alan asked you to test here: http://lkml.org/lkml/2008/2/23/402 It's experimantal, but it is important to us to know if you see the symptoms (and which ones if you do) with this patch applied. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PCI] duplicate sysfs symbols getting registered in current git
On Tue, 19 Feb 2008, Greg KH wrote: > On Mon, Feb 18, 2008 at 09:52:25PM +0100, Guennadi Liakhovetski wrote: > > Booting an x86 SMP PC with todays git-snapshot or just with 2.6.25-rc2 > > getting the following warnings (with a bit of context): > > Can you try enabling CONFIG_DEBUG_KOBJECT and sending the output at boot > time from this? dmesg output with CONFIG_LOG_BUF_SHIFT=19 sent privately to Greg as unpacked, as it would have to be sent to the list, is 408K big. Will see what Greg says. Thanks Guennadi --- Guennadi Liakhovetski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Add rdc321x defconfig file
* Adrian Bunk <[EMAIL PROTECTED]> wrote: > > the existing 32-bit and 64-bit defconfigs should be enough for that. > > For better/full coverage, randconfig should be used. > > The two big problems with randconfigs are: > - either you build each .config both with and without your patch or you > have to manually check which of the failures are caused by your patch > - you require at least an order of magnitude more builds for having the > same amount of common configurations covered > > And any solution that only works on x86 (e.g. based on the expectation > that all randconfig configurations normally build) is of zero value > for me since x86 is only one out of 23 architectures. so if an arguably sane testing method "only" works on x86 then the right solution is to fix the other architectures to be sanely testable too. I've seen architectures that were build-tested for the _first time_ at around 2.6.24-rc8... Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bcm43xx regression in 2.6.24 (with patch)
On Mon, Feb 25, 2008 at 3:25 PM, Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> On Mon, 25 Feb 2008, Michael Buesch wrote:
> > > Neither of which seem like acceptable solutions for a 2.6.23 -> 2.6.24
> > > _regression_. Or maybe I am just too naive to believe Linus' statement
> > > on not letting the kernel regress...
> >
> > So, please sign-off the patch that we have, if you think it's right
> > and doesn't cause more regressions.
>
> I did look at the patch and can gladly add a:
>
> Reviewed-by: Pekka Enberg <[EMAIL PROTECTED]>
>
Thanks for reviewing. Was it the patch I sent to Larry Finger
with the subject line "[PATCH] Fix the bcm43xx driver breakage in 2.6.24/25"
or the patch I sent with the first email in this thread? The patches are
generally the same, but the one sent to Larry was split into two pieces
and the condition on which the bcm43xx config option was hidden
changed a bit.
> But this seems backwards. It was _your_ commit that broke the setup and
> the patch touches a driver _you're_ maintaining.
>
> So can we just revert commit 753f492093da7a40141bfe083073400f518f4c68
> ("[B44]: port to native ssb support") from 2.6.24 and you can add it back
> to 2.6.25 if the problem indeed does go away?
I'm quite sure my patch won't cause any problems, but if Greg
wants to be 100% sure there won't be any regressions introduced
in -stable, reverting the said commit should be the right thing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 0/3] xen pvfb: Para-virtual framebuffer, keyboard and pointer
This is a pair of Xen para-virtual frontend device drivers: drivers/video/xen-fbfront.c provides a framebuffer, and drivers/input/xen-kbdfront provides keyboard and mouse. The backends run in dom0 user space. Differences since last post: * Required patch fixing 32-on-64 xen-blkfront included. * Cleanup when xenkbd_probe() fails fixed. * Don't store event channel in device info. I started with the Xen version at http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/ca05cf1a9bdc Differences to that Xen version, for those who care: * Rewritten on top of fb deferred I/O * IRQ handler names visible in /proc and /sys match the driver names. * Use framebuffer helper functions appropriate for framebuffer in system RAM. * write() refreshes the framebuffer properly. * off-by-one height of some screen refreshs fixed. * Crash when register_framebuffer() fails fixed. * Test for empty ring in input_handler() fixed. * Deadlock in xen-kbdfront resume fixed. * Cleanup when xenkbd_probe() fails fixed. * General clean up. I have a step-by-step patch series from that Xen version to my version, if anybody is interested. Might be useful for reviewers familiar with the Xen version. The patch consists of three parts: 1. xen: Make xen-blkfront write its protocol ABI to xenstore Could do without, but then I'd have to put the same bug in xen-fbfront and xen-kbdfront. 2. fbdev: Make deferred I/O work as advertized I need fb deferred I/O, but is utterly broken. A fix has been floating around on linux-fbdev-devel as part of a larger patch, which as far as I know has not been merged anywhere, yet. This is just the fix. 2. xen pvfb: Para-virtual framebuffer, keyboard and pointer driver The actual drivers. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] xen: Make xen-blkfront write its protocol ABI to xenstore
Frontends are expected to write their protocol ABI to xenstore. Since
the protocol ABI defaults to the backend's native ABI, things work
fine without that as long as the frontend's native ABI is identical to
the backend's native ABI. This is not the case for xen-blkfront
running 32-on-64, because its ABI differs between 32 and 64 bit, and
thus needs this fix.
Based on http://xenbits.xensource.com/xen-unstable.hg?rev/c545932a18f3
and http://xenbits.xensource.com/xen-unstable.hg?rev/ffe52263b430 by
Gerd Hoffmann <[EMAIL PROTECTED]>
Signed-off-by: Markus Armbruster <[EMAIL PROTECTED]>
---
drivers/block/xen-blkfront.c |7 +++
include/xen/interface/io/protocols.h | 21 +
2 files changed, 28 insertions(+), 0 deletions(-)
create mode 100644 include/xen/interface/io/protocols.h
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 8afce67..e69164a 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -46,6 +46,7 @@
#include
#include
+#include
#include
@@ -597,6 +598,12 @@ again:
message = "writing event-channel";
goto abort_transaction;
}
+ err = xenbus_printf(xbt, dev->nodename, "protocol", "%s",
+ XEN_IO_PROTO_ABI_NATIVE);
+ if (err) {
+ message = "writing protocol";
+ goto abort_transaction;
+ }
err = xenbus_transaction_end(xbt, 0);
if (err) {
diff --git a/include/xen/interface/io/protocols.h
b/include/xen/interface/io/protocols.h
new file mode 100644
index 000..01fc8ae
--- /dev/null
+++ b/include/xen/interface/io/protocols.h
@@ -0,0 +1,21 @@
+#ifndef __XEN_PROTOCOLS_H__
+#define __XEN_PROTOCOLS_H__
+
+#define XEN_IO_PROTO_ABI_X86_32 "x86_32-abi"
+#define XEN_IO_PROTO_ABI_X86_64 "x86_64-abi"
+#define XEN_IO_PROTO_ABI_IA64 "ia64-abi"
+#define XEN_IO_PROTO_ABI_POWERPC64 "powerpc64-abi"
+
+#if defined(__i386__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
+#elif defined(__x86_64__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_64
+#elif defined(__ia64__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
+#elif defined(__powerpc64__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_POWERPC64
+#else
+# error arch fixup needed here
+#endif
+
+#endif
--
1.5.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] fbdev: Make deferred I/O work as advertized
Deferred I/O was utterly broken. Reading the mmap()ed framebuffer
worked, but writing it made the VM endlessly invoke
vm_ops.page_mkwrite(). That happened because we failed to set
page->mapping and page->index.
The fix is to set them, and clean up properly before the framebuffer
gets released.
Fix extracted from this linux-fbdev-devel message:
Subject: [PATCH 1/1 2.6.24] fbdev: defio and Metronomefb
From: Jaya Kumar <[EMAIL PROTECTED]>
Date: 2008-02-18 13:41:26
Signed-off-by: Jaya Kumar <[EMAIL PROTECTED]>
Signed-off-by: Markus Armbruster <[EMAIL PROTECTED]>
---
drivers/video/fb_defio.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fb_defio.c b/drivers/video/fb_defio.c
index 0f8cfb9..24843fd 100644
--- a/drivers/video/fb_defio.c
+++ b/drivers/video/fb_defio.c
@@ -4,7 +4,7 @@
* Copyright (C) 2006 Jaya Kumar
*
* This file is subject to the terms and conditions of the GNU General Public
- * License. See the file COPYING in the main directory of this archive
+ * License. See the file COPYING in the main directory of this archive
* for more details.
*/
@@ -31,7 +31,7 @@ static int fb_deferred_io_fault(struct vm_area_struct *vma,
unsigned long offset;
struct page *page;
struct fb_info *info = vma->vm_private_data;
- /* info->screen_base is in System RAM */
+ /* info->screen_base is virtual memory */
void *screen_base = (void __force *) info->screen_base;
offset = vmf->pgoff << PAGE_SHIFT;
@@ -43,6 +43,15 @@ static int fb_deferred_io_fault(struct vm_area_struct *vma,
return VM_FAULT_SIGBUS;
get_page(page);
+
+ if (vma->vm_file)
+ page->mapping = vma->vm_file->f_mapping;
+ else
+ printk(KERN_ERR "no mapping available\n");
+
+ BUG_ON(!page->mapping);
+ page->index = vmf->pgoff;
+
vmf->page = page;
return 0;
}
@@ -138,11 +147,20 @@ EXPORT_SYMBOL_GPL(fb_deferred_io_init);
void fb_deferred_io_cleanup(struct fb_info *info)
{
+ void *screen_base = (void __force *) info->screen_base;
struct fb_deferred_io *fbdefio = info->fbdefio;
+ struct page *page;
+ int i;
BUG_ON(!fbdefio);
cancel_delayed_work(&info->deferred_work);
flush_scheduled_work();
+
+ /* clear out the mapping that we setup */
+ for (i = 0 ; i < info->fix.smem_len; i += PAGE_SIZE) {
+ page = vmalloc_to_page(screen_base + i);
+ page->mapping = NULL;
+ }
}
EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 3/3] xen pvfb: Para-virtual framebuffer, keyboard and pointer driver
This is a pair of Xen para-virtual frontend device drivers:
drivers/video/xen-fbfront.c provides a framebuffer, and
drivers/input/xen-kbdfront provides keyboard and mouse.
The backends run in dom0 user space.
The two drivers are not in two separate patches, because the
intermediate step (one driver, not the other) is somewhat problematic:
the backend in dom0 needs both drivers, and will refuse to complete
device initialization unless they're both present.
Signed-off-by: Markus Armbruster <[EMAIL PROTECTED]>
---
drivers/input/Kconfig|9
drivers/input/Makefile |2
drivers/input/xen-kbdfront.c | 340
drivers/video/Kconfig| 14
drivers/video/Makefile |1
drivers/video/xen-fbfront.c | 550 +++
include/xen/interface/io/fbif.h | 124
include/xen/interface/io/kbdif.h | 114
8 files changed, 1154 insertions(+)
diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig
index 9dea14d..5f9d860 100644
--- a/drivers/input/Kconfig
+++ b/drivers/input/Kconfig
@@ -149,6 +149,15 @@ config INPUT_APMPOWER
To compile this driver as a module, choose M here: the
module will be called apm-power.
+config XEN_KBDDEV_FRONTEND
+ tristate "Xen virtual keyboard and mouse support"
+ depends on XEN_FBDEV_FRONTEND
+ default y
+ help
+ This driver implements the front-end of the Xen virtual
+ keyboard and mouse device driver. It communicates with a back-end
+ in another domain.
+
comment "Input Device Drivers"
source "drivers/input/keyboard/Kconfig"
diff --git a/drivers/input/Makefile b/drivers/input/Makefile
index 2ae87b1..98c4f9a 100644
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -23,3 +23,5 @@ obj-$(CONFIG_INPUT_TOUCHSCREEN) += touchscreen/
obj-$(CONFIG_INPUT_MISC) += misc/
obj-$(CONFIG_INPUT_APMPOWER) += apm-power.o
+
+obj-$(CONFIG_XEN_KBDDEV_FRONTEND) += xen-kbdfront.o
diff --git a/drivers/input/xen-kbdfront.c b/drivers/input/xen-kbdfront.c
new file mode 100644
index 000..0f47f46
--- /dev/null
+++ b/drivers/input/xen-kbdfront.c
@@ -0,0 +1,340 @@
+/*
+ * Xen para-virtual input device
+ *
+ * Copyright (C) 2005 Anthony Liguori <[EMAIL PROTECTED]>
+ * Copyright (C) 2006-2008 Red Hat, Inc., Markus Armbruster <[EMAIL PROTECTED]>
+ *
+ * Based on linux/drivers/input/mouse/sermouse.c
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ */
+
+/*
+ * TODO:
+ *
+ * Switch to grant tables together with xen-fbfront.c.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct xenkbd_info {
+ struct input_dev *kbd;
+ struct input_dev *ptr;
+ struct xenkbd_page *page;
+ int irq;
+ struct xenbus_device *xbdev;
+ char phys[32];
+};
+
+static int xenkbd_remove(struct xenbus_device *);
+static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info
*);
+static void xenkbd_disconnect_backend(struct xenkbd_info *);
+
+/*
+ * Note: if you need to send out events, see xenfb_do_update() for how
+ * to do that.
+ */
+
+static irqreturn_t input_handler(int rq, void *dev_id)
+{
+ struct xenkbd_info *info = dev_id;
+ struct xenkbd_page *page = info->page;
+ __u32 cons, prod;
+
+ prod = page->in_prod;
+ if (prod == page->in_cons)
+ return IRQ_HANDLED;
+ rmb(); /* ensure we see ring contents up to prod */
+ for (cons = page->in_cons; cons != prod; cons++) {
+ union xenkbd_in_event *event;
+ struct input_dev *dev;
+ event = &XENKBD_IN_RING_REF(page, cons);
+
+ dev = info->ptr;
+ switch (event->type) {
+ case XENKBD_TYPE_MOTION:
+ input_report_rel(dev, REL_X, event->motion.rel_x);
+ input_report_rel(dev, REL_Y, event->motion.rel_y);
+ break;
+ case XENKBD_TYPE_KEY:
+ dev = NULL;
+ if (test_bit(event->key.keycode, info->kbd->keybit))
+ dev = info->kbd;
+ if (test_bit(event->key.keycode, info->ptr->keybit))
+ dev = info->ptr;
+ if (dev)
+ input_report_key(dev, event->key.keycode,
+event->key.pressed);
+ else
+ printk(KERN_WARNING
+ "xenkbd: unhandled keycode 0x%x\n",
+ event->key.keycode);
+ break;
+ case XENKBD_TYPE_POS:
+
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 01:57:07PM +0100, Ingo Molnar wrote: > > * Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > the existing 32-bit and 64-bit defconfigs should be enough for that. > > > For better/full coverage, randconfig should be used. > > > > The two big problems with randconfigs are: > > - either you build each .config both with and without your patch or you > > have to manually check which of the failures are caused by your patch > > - you require at least an order of magnitude more builds for having the > > same amount of common configurations covered > > > > And any solution that only works on x86 (e.g. based on the expectation > > that all randconfig configurations normally build) is of zero value > > for me since x86 is only one out of 23 architectures. > > so if an arguably sane testing method "only" works on x86 then the right > solution is to fix the other architectures to be sanely testable too. If you want to fix them I won't stop you... Until they are fixed I'm staying at using the defconfigs. But then there's still the other problem that at least I simply don't want to wait two weeks for having the test compiles of a patch finish. > I've seen architectures that were build-tested for the _first time_ at > around 2.6.24-rc8... That can't be true. Can you name what architectures you think of and why you think noone tried to compile them before? > Ingo cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.25-rc3] lockdep: add spin_lock_irq_nested()
On Mon, 2008-02-25 at 03:21 -0800, David Brownell wrote:
> > > > > > ==> LOCKDEP feature is evidently missing:
> > > > > > spin_lock_irq_nested(lock_ptr, lock_class)
> > > > >
> > > > > This rant is more lines than adding the API :-/ the reason for it not
> > > > > being there is simple, it wasn't needed up until now.
> > > >
> > > > I suspected that was the case, but for all I knew there was some
> > > > religious objection.
> > >
> > > Does this look about right? Or, I suppose it could just call
> > > the _spin_lock_irqsave_nested() routine and discard the result.
> >
> > Before I look at the code, and with a notice that I haven't had my
> > morning juice yet...
> >
> > It seems to me a spin_lock_irq_nested() thing is redundant, because:
> >
> > The lock must obviously be held hardirq safe and nested implies one is
> > already held.
>
> I thought the way to use the *_nested() calls was "consistently"!
Very much depends on your view of consistent :-)
> That is, if one instance of a lock access uses it, they all should,
> since that's the only way lockdep learns about equivalence classes.
> Also, locks shouldn't move between those equivalence classes... so
> the raw lockdep data stays correct.
Ah, see, you're missing a detail (see below for the full story). Its the
irq state that must be consistent. So if at any one point you take the
lock in an irq safe context, you must always take it irq safe.
> The IRQ framework uses spin_lock_irq() in only one place that I saw:
> in kernel/irq/autoprobe.c for the probe_irq_{on,off,mask}() calls.
>
> Those calls will grab locks at their "top level", and then the
> irqchip methods they call might need to grab locks for other irqs.
> Potential example: chip->startup() and chip->shutdown() could
> need to ensure a *parent* controller starts/stops, and that should
> involve mutual exclusion using the parent's irq lock (as well as
> the child's). So the chip and its parent should be in different
> lock classes, else lockdep will wrongly warn of recursion.
Quite, but we must also take note of the irq state.
> > Hence the context is already hardirq safe thus using
> > spin_lock_irq/spin_unlock_irq is wrong because it will enable irqs and
> > destroy the irqsafe guarantee for the parent lock.
>
> That's not how the autoprobe() stuff works. The other calls in
> the genirq framework don't use the *_irq() variants though, so
> your intuition is right there. (Only the autoprobe paths had
> the FIXME comments in that patch I sent earlier, related to the
> lack of the $SUBJECT primitive.)
Right, which is where I gleaned your usage from..
> > Obviously I'm missing something here.. otherwise you wouldn't need it.
> >
> > As I'm very much not familiar with the IRQ code, could you spell it out
> > to me?
>
> The probe_irq_*() calls are made from task context, not hardirq
> context, but they access the same locks involved in IRQ management
> and processing. So either they need to pass the same lock class
> annodations to lockdep, or there's something that's unusually
> counter-intuitive going on with respect to those annotations in
> simple tree data structures.
Ah, you can play tricks here :-) All you need to ensure are consisent
class uses. So if your normal usage is 0->1->2->3 etc.. all you need to
ensure is that the reverse never happens.
Also, have you looked at explicit lock_class_key usage per chip? That
way you can avoid using the _nested annotation. You can set a class on a
lock right after spin_lock_init() using lockdep_set_class*().
Look at it this way:
spin_lock_irq() := local_irq_disable(); spin_lock();
spin_unlock_irq() := spin_unlock(); local_irq_enable();
spin_lock_irq_nested() : local_irq_disable(); spin_lock_nested();
spin_lock_irq(&parent_desc->lock); local_irq_disable();
spin_lock(&parent_desc->lock);
spin_lock_irq_nested(&desc->lock, 1); local_irq_disable();
spin_lock_nested(&desc->lock, 1)
spin_unlock_irq(&desc->lock); spin_unlock(&desc->lock);
local_irq_enable(); <--- BUG!
spin_unlock_irq(&parent_desc->lock); spin_unlock(&parent_desc->lock);
local_irq_enable();
At the BUG site lockdep will warn because parent_desc->lock is still
held as hardirq-safe lock, but the context is hardirq-unsafe.
It will become an actual deadlock if at that point an IRQ happens and
tries to acquire parent_desc->lock.
The safe approach is using spin_lock_irqsave{,_nested}().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
device mapper not reporting no-barrier-support?
Hi, I'm currently stuck between Kernel LVM and DRBD, as I'm using Kernel 2.6.24.2 with DRBD 8.2.5 on top of an LVM2 device (LV). -LVM2/device mapper doesn't support write barriers -DRBD uses blkdev_issue_flush() to flush its metadata to disk. On a no-barrier-device, DRBD should receive EOPNOTSUPP, but it really does receive an EIO. Promptly, DRBD gives the error message "drbd0: local disk flush failed with status -5". The physical disk (in LVM speak) is a RAID1 on a 3ware 9650SE-2LP controller; the driver 3w-9xxx supports barriers and after moving my D RBD device from the LV to a single partition on the same RAID1, the error messages from DRBD vanished. I've posted a lengty summary of my findings to http://lists.linbit.com/pipermail/drbd-user/2008-February/008665.html ... where Lars Ellenberg from DRBD basically responded in http://lists.linbit.com/pipermail/drbd-user/2008-February/008666.html ... that DRBD does catch the EOPNOTSUPP for blkdev_issue_flush and BIO_RW_BARRIER, but the lvm implementation of blkdev_issue_flush in 2.6.24.2 aparently does return EIO for blkdev_issue_flush. So simply the question: how should a top-layer driver check wether a lower device does support barriers? md-raid does check this way differently than e.g. XFS does, while DRBD also adds a third way to check this. Or is this "merely" a bug in drivers/md/dm.c? Anders -- 1&1 Internet AG System Architect Brauerstrasse 48 v://49.721.91374.50 D-76135 Karlsruhef://49.721.91374.225 Amtsgericht Montabaur HRB 6484 Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Achim Weiss Aufsichtsratsvorsitzender: Michael Scheeren -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 cdrom problem with PLEXTOR DVDR PX-608AL
On Monday 25 February 2008, Brad Rosser wrote:
[...]
> Bart wrote:
>
> > Does the following patch help?
> >
> > [ It makes ireason handling for REQ_TYPE_ATA_PC requests be the same as
> > for other request types so "ireason == 1" quirk is used if needed. ]
>
> I tried to apply the patch but failed; I probably did something wrong.
> I deleted everything in your message above 'Index: b/drivers/ide/ide-cd.c'
> and ran 'patch --dry-run -b -p1 < ../bart_patch'. This is part of my script
> log:
>
> root:/usr/src/linux-2.6.25-rc2# pwd
> /usr/src/linux-2.6.25-rc2
> root:/usr/src/linux-2.6.25-rc2# cat ../bart_patch
> Index: b/drivers/ide/ide-cd.c
> ===
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
> @@ -670,8 +670,8 @@ static void cdrom_buffer_sectors (ide_dr
> * and attempt to recover if there are problems. Returns 0 if everything's
> ...
> ...
> root:/usr/src/linux-2.6.25-rc2# patch --dry-run -b -p1 < ../bart_patch
> patching file drivers/ide/ide-cd.c
> Hunk #1 FAILED at 670.
> Hunk #2 FAILED at 701.
> Hunk #3 FAILED at 1074.
> Hunk #4 FAILED at 1104.
> 4 out of 4 hunks FAILED -- saving rejects to file drivers/ide/ide-cd.c.rej
Same command works just fine for me with 2.6.25-rc2/3.
It could be that the patch got damaged somewhere on the way
(to eleminate this possibility I'm attaching it to this mail).
Thanks,
Bart
---
drivers/ide/ide-cd.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
Index: b/drivers/ide/ide-cd.c
===
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -670,8 +670,8 @@ static void cdrom_buffer_sectors (ide_dr
* and attempt to recover if there are problems. Returns 0 if everything's
* ok; nonzero if the request has been terminated.
*/
-static
-int ide_cd_check_ireason(ide_drive_t *drive, int len, int ireason, int rw)
+static int ide_cd_check_ireason(ide_drive_t *drive, struct request *rq,
+int len, int ireason, int rw)
{
/*
* ireason == 0: the drive wants to receive data from us
@@ -701,6 +701,9 @@ int ide_cd_check_ireason(ide_drive_t *dr
drive->name, __FUNCTION__, ireason);
}
+ if (rq->cmd_type == REQ_TYPE_ATA_PC)
+ rq->cmd_flags |= REQ_FAILED;
+
cdrom_end_request(drive, 0);
return -1;
}
@@ -1071,11 +1074,11 @@ static ide_startstop_t cdrom_newpc_intr(
/*
* check which way to transfer data
*/
- if (blk_fs_request(rq) || blk_pc_request(rq)) {
- if (ide_cd_check_ireason(drive, len, ireason, write))
- return ide_stopped;
+ if (ide_cd_check_ireason(drive, rq, len, ireason, write))
+ return ide_stopped;
- if (blk_fs_request(rq) && write == 0) {
+ if (blk_fs_request(rq)) {
+ if (write == 0) {
int nskip;
if (ide_cd_check_transfer_size(drive, len)) {
@@ -1101,16 +1104,9 @@ static ide_startstop_t cdrom_newpc_intr(
if (ireason == 0) {
write = 1;
xferfunc = HWIF(drive)->atapi_output_bytes;
- } else if (ireason == 2 || (ireason == 1 &&
- (blk_fs_request(rq) || blk_pc_request(rq {
+ } else {
write = 0;
xferfunc = HWIF(drive)->atapi_input_bytes;
- } else {
- printk(KERN_ERR "%s: %s: The drive "
-"appears confused (ireason = 0x%02x). "
-"Trying to recover by ending request.\n",
-drive->name, __FUNCTION__, ireason);
- goto end_request;
}
/*
[ugly patch] Save .15W-.5W by AHCI powersaving
Hi!
This is a patch (very ugly, assumes you have just one disk) to bring
powersaving to AHCI. You need Alan's SCSI autosuspend (attached) patch
as a base.
It saves .5W compared to config with disk spinning, and even .15W
compared to hdparm -y... on my thinkpad x60 anyway.
It is also mandatory first step towards sleepy linux ;-).
Pavel
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 29e71bd..0197b1f 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -259,8 +260,8 @@ static void ahci_fill_cmd_slot(struct ah
u32 opts);
#ifdef CONFIG_PM
static int ahci_port_suspend(struct ata_port *ap, pm_message_t mesg);
-static int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
-static int ahci_pci_device_resume(struct pci_dev *pdev);
+int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
+int ahci_pci_device_resume(struct pci_dev *pdev);
#endif
static struct class_device_attribute *ahci_shost_attrs[] = {
@@ -268,6 +269,35 @@ static struct class_device_attribute *ah
NULL
};
+struct pci_dev *my_pdev;
+int autosuspend_enabled;
+
+/* The host and its devices are all idle so we can autosuspend */
+static int autosuspend(struct Scsi_Host *host)
+{
+ if (my_pdev && autosuspend_enabled) {
+ printk("ahci: should autosuspend\n");
+ ahci_pci_device_suspend(my_pdev, PMSG_SUSPEND);
+ return 0;
+ }
+ printk("ahci: autosuspend disabled\n");
+ return -EINVAL;
+}
+
+/* The host needs to be autoresumed */
+static int autoresume(struct Scsi_Host *host)
+{
+ if (my_pdev && autosuspend_enabled) {
+ printk("ahci: should autoresume\n");
+ ahci_pci_device_resume(my_pdev);
+ return 0;
+ }
+ printk("ahci: autoresume disabled\n");
+ return -EINVAL;
+}
+
+
+
static struct scsi_host_template ahci_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
@@ -286,6 +322,8 @@ static struct scsi_host_template ahci_sh
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
.shost_attrs= ahci_shost_attrs,
+ .autosuspend= autosuspend,
+ .autoresume = autoresume,
};
static const struct ata_port_operations ahci_ops = {
@@ -2300,8 +2356,12 @@ static int ahci_init_one(struct pci_dev
ahci_print_info(host);
pci_set_master(pdev);
- return ata_host_activate(host, pdev->irq, ahci_interrupt, IRQF_SHARED,
+
+ rc = ata_host_activate(host, pdev->irq, ahci_interrupt, IRQF_SHARED,
&ahci_sht);
+ pci_save_state(pdev);
+ my_pdev = pdev;
+ return rc;
}
static int __init ahci_init(void)
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 4e31071..5c40ac2 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -380,7 +381,7 @@ enum scsi_eh_timer_return ata_scsi_timed
* Inherited from SCSI layer (none, can sleep)
*
* RETURNS:
- * Zero.
+ * Nothing.
*/
void ata_scsi_error(struct Scsi_Host *host)
{
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index c838e65..0edc25e 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -484,6 +484,8 @@ static int scsi_try_host_reset(struct sc
if (scsi_autoresume_host(shost) != 0)
return FAILED;
+ rtn = shost->hostt->eh_host_reset_handler(scmd);
+
if (rtn == SUCCESS) {
if (!shost->hostt->skip_settle_delay)
ssleep(HOST_RESET_SETTLE_TIME);
@@ -1577,7 +1579,11 @@ int scsi_error_handler(void *data)
* what we need to do to get it up and online again (if we can).
* If we fail, we end up taking the thing offline.
*/
+#if 0
+ /* libata uses scsi_error_handler to suspend its parts; we
deadlock
+ if we try to autoresume here */
autoresume_rc = scsi_autoresume_host(shost);
+#endif
if (shost->transportt->eh_strategy_handler)
shost->transportt->eh_strategy_handler(shost);
else
@@ -1591,8 +1597,10 @@ int scsi_error_handler(void *data)
* which are still online.
*/
scsi_restart_operations(shost);
+#if 0
if (autoresume_rc == 0)
scsi_autosuspend_host(shost);
+#endif
set_current_state(TASK_INTERRUPTIBLE);
}
__set_current_state(TASK_RUNNING);
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 233feee..3c598e0 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -67,6 +67,8 @@ #undef SP
static struct kmem_cache *scsi_bidi_sdb_cache;
+void scsi_run_
Re: [PATCH] Add rdc321x defconfig file
* Adrian Bunk <[EMAIL PROTECTED]> wrote: > > so if an arguably sane testing method "only" works on x86 then the > > right solution is to fix the other architectures to be sanely > > testable too. > > If you want to fix them I won't stop you... > > Until they are fixed I'm staying at using the defconfigs. As i said it before, it's totally senseless to add zillions of defconfigs to x86. The two that are there should be enough for a sniff-test - and much more than that has to be done to ensure that a patch doesnt break anything. Not even a 100 defconfigs would match proper randconfig coverage. according to one particular arbitrary piece of metrics [1], ~99.15% of our testers use x86 - and the oopses collected on kerneloops.org show a similar proportion. > > I've seen architectures that were build-tested for the _first time_ > > at around 2.6.24-rc8... > > That can't be true. > > Can you name what architectures you think of and why you think noone > tried to compile them before? sorry, s/build-tested/boot-tested. there's been only 6 commits to arch/v850 between v2.6.23 and v2.6.24. None of them seems to suggest that anyone ever tested v850 in the last year or so. Ingo [1] http://smolt.fedoraproject.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Misc, phantom, fix poll
Return ERR even if there are pending data, but hw is not running. Do not
decrement count in poll, do it in ioctl, where data are actually read.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
drivers/misc/phantom.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/phantom.c b/drivers/misc/phantom.c
index 5447a60..71d1c84 100644
--- a/drivers/misc/phantom.c
+++ b/drivers/misc/phantom.c
@@ -169,6 +169,7 @@ static long phantom_ioctl(struct file *file, unsigned int
cmd,
for (i = 0; i < m; i++)
if (rs.mask & BIT(i))
rs.values[i] = ioread32(dev->iaddr + i);
+ atomic_set(&dev->counter, 0);
spin_unlock_irqrestore(&dev->regs_lock, flags);
if (copy_to_user(argp, &rs, sizeof(rs)))
@@ -254,11 +255,12 @@ static unsigned int phantom_poll(struct file *file,
poll_table *wait)
pr_debug("phantom_poll: %d\n", atomic_read(&dev->counter));
poll_wait(file, &dev->wait, wait);
- if (atomic_read(&dev->counter)) {
+
+ if (!(dev->status & PHB_RUNNING))
+ mask = POLLERR;
+ else if (atomic_read(&dev->counter))
mask = POLLIN | POLLRDNORM;
- atomic_dec(&dev->counter);
- } else if ((dev->status & PHB_RUNNING) == 0)
- mask = POLLIN | POLLRDNORM | POLLERR;
+
pr_debug("phantom_poll end: %x/%d\n", mask, atomic_read(&dev->counter));
return mask;
--
1.5.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Misc: phantom, add compat ioctl
Openhaptics uses pointers in _IOC() macros, implement compat for them. Also
add _IOC alternatives which are not 32/64 bit dependent (structures
passed through aren't yet) -- libphantom will use them.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
drivers/misc/phantom.c | 24
include/linux/phantom.h |5 -
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/phantom.c b/drivers/misc/phantom.c
index 7fa61e9..5447a60 100644
--- a/drivers/misc/phantom.c
+++ b/drivers/misc/phantom.c
@@ -12,6 +12,7 @@
* or alternatively, you might use OpenHaptics provided by Sensable.
*/
+#include
#include
#include
#include
@@ -91,11 +92,8 @@ static long phantom_ioctl(struct file *file, unsigned int
cmd,
unsigned long flags;
unsigned int i;
- if (_IOC_TYPE(cmd) != PH_IOC_MAGIC ||
- _IOC_NR(cmd) > PH_IOC_MAXNR)
- return -ENOTTY;
-
switch (cmd) {
+ case PHN_SETREG:
case PHN_SET_REG:
if (copy_from_user(&r, argp, sizeof(r)))
return -EFAULT;
@@ -126,6 +124,7 @@ static long phantom_ioctl(struct file *file, unsigned int
cmd,
phantom_status(dev, dev->status & ~PHB_RUNNING);
spin_unlock_irqrestore(&dev->regs_lock, flags);
break;
+ case PHN_SETREGS:
case PHN_SET_REGS:
if (copy_from_user(&rs, argp, sizeof(rs)))
return -EFAULT;
@@ -143,6 +142,7 @@ static long phantom_ioctl(struct file *file, unsigned int
cmd,
}
spin_unlock_irqrestore(&dev->regs_lock, flags);
break;
+ case PHN_GETREG:
case PHN_GET_REG:
if (copy_from_user(&r, argp, sizeof(r)))
return -EFAULT;
@@ -155,6 +155,7 @@ static long phantom_ioctl(struct file *file, unsigned int
cmd,
if (copy_to_user(argp, &r, sizeof(r)))
return -EFAULT;
break;
+ case PHN_GETREGS:
case PHN_GET_REGS: {
u32 m;
@@ -191,6 +192,20 @@ static long phantom_ioctl(struct file *file, unsigned int
cmd,
return 0;
}
+#ifdef CONFIG_COMPAT
+static long phantom_compat_ioctl(struct file *filp, unsigned int cmd,
+ unsigned long arg)
+{
+ if (_IOC_NR(cmd) <= 3 && _IOC_SIZE(cmd) == sizeof(compat_uptr_t)) {
+ cmd &= ~(_IOC_SIZEMASK << _IOC_SIZESHIFT);
+ cmd |= sizeof(void *) << _IOC_SIZESHIFT;
+ }
+ return phantom_ioctl(filp, cmd, (unsigned long)compat_ptr(arg));
+}
+#else
+#define phantom_compat_ioctl NULL
+#endif
+
static int phantom_open(struct inode *inode, struct file *file)
{
struct phantom_device *dev = container_of(inode->i_cdev,
@@ -253,6 +268,7 @@ static struct file_operations phantom_file_ops = {
.open = phantom_open,
.release = phantom_release,
.unlocked_ioctl = phantom_ioctl,
+ .compat_ioctl = phantom_compat_ioctl,
.poll = phantom_poll,
};
diff --git a/include/linux/phantom.h b/include/linux/phantom.h
index 96f4048..fc0a505 100644
--- a/include/linux/phantom.h
+++ b/include/linux/phantom.h
@@ -34,7 +34,10 @@ struct phm_regs {
* use improved registers update (no more phantom switchoffs when using
* libphantom) */
#define PHN_NOT_OH _IO (PH_IOC_MAGIC, 4)
-#define PH_IOC_MAXNR 4
+#define PHN_GETREG _IOWR(PH_IOC_MAGIC, 5, struct phm_reg)
+#define PHN_SETREG _IOW (PH_IOC_MAGIC, 6, struct phm_reg)
+#define PHN_GETREGS_IOWR(PH_IOC_MAGIC, 7, struct phm_regs)
+#define PHN_SETREGS_IOW (PH_IOC_MAGIC, 8, struct phm_regs)
#define PHN_CONTROL0x6 /* control byte in iaddr space */
#define PHN_CTL_AMP0x1 /* switch after torques change */
--
1.5.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
even though
i read that you shouldn't write a testmail i need to see if this works.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + kthread-add-a-missing-memory-barrier-to-kthread_stop.patch added to -mm tree
Dmitry Adamushko <[EMAIL PROTECTED]> wrote: > (3) > > LOCK > > LOAD(a) > MODIFY(b) > > UNLOCK > > and this last one is a problem. No? I assume you meant: LOCK LOAD(b) MODIFY(a) UNLOCK David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add rdc321x defconfig file
On Mon, Feb 25, 2008 at 02:45:49PM +0100, Ingo Molnar wrote: >... > > > I've seen architectures that were build-tested for the _first time_ > > > at around 2.6.24-rc8... > > > > That can't be true. > > > > Can you name what architectures you think of and why you think noone > > tried to compile them before? > > sorry, s/build-tested/boot-tested. That's quite a difference. > there's been only 6 commits to arch/v850 between v2.6.23 and v2.6.24. > None of them seems to suggest that anyone ever tested v850 in the last > year or so. Even longer, see http://lkml.org/lkml/2008/2/13/539 It's the only port we have that is completely unmaintained and broken for ages. But the fact that the v850 port does not even compile is known for a long time, and nothing about this fact changed around 2.6.24-rc8. > Ingo >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC, PATCH 0/2] sched: add multiple hierarchy support to the CFS group scheduler
Hi Ingo, These patches change the fairness model as discussed in http://lkml.org/lkml/2008/1/30/634 Patch 1 -> Changes the fairness model Patch 2 -> Allows one to create multiple levels of cgroups The second patch is not very good with SMP yet, that is the next TODO. Also it changes the behaviour of fair user. The root task group is the parent task group and the other users are its children. Thanks, -- regards, Dhaval -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC, PATCH 1/2] sched: change the fairness model of the CFS group scheduler
This patch allows tasks and groups to exist in the same cfs_rq. With this
change the CFS group scheduling follows a 1/(M+N) model from a 1/(1+N)
fairness model where M tasks and N groups exist at the cfs_rq level.
Signed-off-by: Dhaval Giani <[EMAIL PROTECTED]>
Signed-off-by: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
kernel/sched.c | 46 +
kernel/sched_fair.c | 113 +---
2 files changed, 137 insertions(+), 22 deletions(-)
Index: linux-2.6.25-rc2/kernel/sched.c
===
--- linux-2.6.25-rc2.orig/kernel/sched.c
+++ linux-2.6.25-rc2/kernel/sched.c
@@ -224,10 +224,13 @@ struct task_group {
};
#ifdef CONFIG_FAIR_GROUP_SCHED
+
+#ifdef CONFIG_USER_SCHED
/* Default task group's sched entity on each cpu */
static DEFINE_PER_CPU(struct sched_entity, init_sched_entity);
/* Default task group's cfs_rq on each cpu */
static DEFINE_PER_CPU(struct cfs_rq, init_cfs_rq) cacheline_aligned_in_smp;
+#endif
static struct sched_entity *init_sched_entity_p[NR_CPUS];
static struct cfs_rq *init_cfs_rq_p[NR_CPUS];
@@ -7163,6 +7166,10 @@ static void init_tg_cfs_entry(struct rq
list_add(&cfs_rq->leaf_cfs_rq_list, &rq->leaf_cfs_rq_list);
tg->se[cpu] = se;
+ /* se could be NULL for init_task_group */
+ if (!se)
+ return;
+
se->cfs_rq = &rq->cfs;
se->my_q = cfs_rq;
se->load.weight = tg->shares;
@@ -7217,11 +7224,46 @@ void __init sched_init(void)
#ifdef CONFIG_FAIR_GROUP_SCHED
init_task_group.shares = init_task_group_load;
INIT_LIST_HEAD(&rq->leaf_cfs_rq_list);
+#ifdef CONFIG_CGROUP_SCHED
+ /*
+* How much cpu bandwidth does init_task_group get?
+*
+* In case of task-groups formed thr' the cgroup filesystem, it
+* gets 100% of the cpu resources in the system. This overall
+* system cpu resource is divided among the tasks of
+* init_task_group and its child task-groups in a fair manner,
+* based on each entity's (task or task-group's) weight
+* (se->load.weight).
+*
+* In other words, if init_task_group has 10 tasks of weight
+* 1024) and two child groups A0 and A1 (of weight 1024 each),
+* then A0's share of the cpu resource is:
+*
+* A0's bandwidth = 1024 / (10*1024 + 1024 + 1024) = 8.33%
+*
+* We achieve this by letting init_task_group's tasks sit
+* directly in rq->cfs (i.e init_task_group->se[] = NULL).
+*/
+ init_tg_cfs_entry(rq, &init_task_group, &rq->cfs, NULL, i, 1);
+ init_tg_rt_entry(rq, &init_task_group, &rq->rt, NULL, i, 1);
+#elif defined CONFIG_USER_SCHED
+ /*
+* In case of task-groups formed thr' the user id of tasks,
+* init_task_group represents tasks belonging to root user.
+* Hence it forms a sibling of all subsequent groups formed.
+* In this case, init_task_group gets only a fraction of overall
+* system cpu resource, based on the weight assigned to root
+* user's cpu share (INIT_TASK_GROUP_LOAD). This is accomplished
+* by letting tasks of init_task_group sit in a separate cfs_rq
+* (init_cfs_rq) and having one entity represent this group of
+* tasks in rq->cfs (i.e init_task_group->se[] != NULL).
+*/
init_tg_cfs_entry(rq, &init_task_group,
&per_cpu(init_cfs_rq, i),
&per_cpu(init_sched_entity, i), i, 1);
#endif
+#endif /* CONFIG_FAIR_GROUP_SCHED */
#ifdef CONFIG_RT_GROUP_SCHED
init_task_group.rt_runtime =
sysctl_sched_rt_runtime * NSEC_PER_USEC;
@@ -7435,6 +7477,10 @@ static int rebalance_shares(struct sched
unsigned long total_load = 0, total_shares;
struct task_group *tg = cfs_rq->tg;
+ /* Skip this group if there is no associated group entity */
+ if (unlikely(!tg->se[this_cpu]))
+ continue;
+
/* Gather total task load of this group across cpus */
for_each_cpu_mask(i, sdspan)
total_load += tg->cfs_rq[i]->load.weight;
Index: linux-2.6.25-rc2/kernel/sched_fair.c
===
--- linux-2.6.25-rc2.orig/kernel/sched_fair.c
+++ linux-2.6.25-rc2/kernel/sched_fair.c
@@ -732,6 +732,21 @@ static inline struct sched_entity *paren
return se->parent;
}
+/* return the cpu load contributed by a given group on a given cpu */
+static inline unsign
