Re: kernel 2.6 speed
- Original Message - From: "Florin Malita" <[EMAIL PROTECTED]> To: "Linux Kernel Mailing List" Sent: Monday, July 25, 2005 12:10 AM Subject: Re: kernel 2.6 speed > On 7/24/05, Alan Cox <[EMAIL PROTECTED]> wrote: > > time() isn't a hot > > path in the real world. > > That's what you would expect but I've straced stuff calling > gettimeofday() in huge bursts every other second. Obviously braindead > stuff but so is "the real world" most of the time() ... :) Anything time stamping things it processes many of will call some sort of time function pretty often. Could happen frequently with certain classes of applications.OS/2's "infoseg" approach was a pretty "high speed low drag" way to eliminate a trip into the kernel for all but the most esoteric time requirements. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: fix suspend/resume irq request free for yenta..
>On Sat, Jul 23, 2005 at 02:29:24AM +0200, Pavel Machek wrote: >> > Is it necessary to do free_irq for suspend? Shouldn't disable_irq >> > be enough? >> >> Due to recent changes in ACPI, yes, it is neccessary. > >What if some other driver is sharing the IRQ, and requires IRQs to be >enabled for the resume to complete? IRQ sharing is an excellent example, not a counter-example, of why it is necessary to disable devices and free IRQs on suspend, and acquire them again on resume. eg. if a device is suspended, but the hardware still causes an interrupt on a shared IRQ, another device can suffer a screaming IRQ failure. Documentation/power/pci.txt has as much as we know about how to address this -- but I'm certainly open to suggestions on how to be less invasive to the drivers while having some chance of being robust. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZyXEL Kernel /BusyBox GPL violation?
On 7/25/05, Lee Revell <[EMAIL PROTECTED]> wrote: > On Mon, 2005-07-25 at 23:21 -0400, Mace Moneta wrote: > > The response seems meaningless; does this constitute a violation of > > GPL? > > If so what, if any, action needs to be taken? http://gpl-violations.org/ http://www.fsf.org/licensing/licenses/gpl-faq.html#ReportingViolation http://www.fsf.org/licensing/licenses/gpl-violation.html [[[You should report it. First, check the facts as best you can. Then tell the publisher or copyright holder of the specific GPL-covered program. If that is the Free Software Foundation, write to <[EMAIL PROTECTED]>. Otherwise, the program's maintainer may be the copyright holder, or else could tell you how to contact the copyright holder, so report it to the maintainer.]]] > Also if they didn't modify the kernel, they don't have to give you > source, they can just refer you to kernel.org. Wrong. http://www.fsf.org/licensing/licenses/gpl-faq.html#DistributeWithSourceOnInternet [[[I want to distribute binaries without accompanying sources. Can I provide source code by FTP instead of by mail order? You're supposed to provide the source code by mail-order on a physical medium, if someone orders it. You are welcome to offer people a way to copy the corresponding source code by FTP, in addition to the mail-order option, but FTP access to the source is not sufficient to satisfy section 3 of the GPL. When a user orders the source, you have to make sure to get the source to that user. If a particular user can conveniently get the source from you by anonymous FTP, fine--that does the job. But not every user can do such a download. The rest of the users are just as entitled to get the source code from you, which means you must be prepared to send it to them by post. If the FTP access is convenient enough, perhaps no one will choose to mail-order a copy. If so, you will never have to ship one. But you cannot assume that. Of course, it's easiest to just send the source with the binary in the first place. ]]] http://www.fsf.org/licensing/licenses/gpl-faq.html#TOCSourceAndBinaryOnDifferentSites [[[Can I put the binaries on my Internet server and put the source on a different Internet site? The GPL says you must offer access to copy the source code "from the same place"; that is, next to the binaries. However, if you make arrangements with another site to keep the necessary source code available, and put a link or cross-reference to the source code next to the binaries, we think that qualifies as "from the same place". Note, however, that it is not enough to find some site that happens to have the appropriate source code today, and tell people to look there. Tomorrow that site may have deleted that source code, or simply replaced it with a newer version of the same program. Then you would no longer be complying with the GPL requirements. To make a reasonable effort to comply, you need to make a positive arrangement with the other site, and thus ensure that the source will be available there for as long as you keep the binaries available. ]]] http://www.fsf.org/licensing/licenses/gpl.html Section 3 mentions three choices of what you must do to copy and distribute: a) Have it from the same location. They have not. b) Have written offer good for three years None such mentioned. c) Be noncommercial plus send some information. zyxel.com "seller of routers" sounds like a commercial enterprise to me. So no they must assume responsibility to have the sources availible even if they didn't modify them. -- http://dmoz.org/profiles/pollei.html http://sourceforge.net/users/stephen_pollei/ http://www.orkut.com/Profile.aspx?uid=2455954990164098214 http://stephen_pollei.home.comcast.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: Yamaha OPL3SA2 does not work with ALSA on 2.6 kernels.
On 7/25/05, Adrian Bunk <[EMAIL PROTECTED]> wrote: > Does the OSS driver work in 2.6? I was able to get the OSS module (opl3sa2) installed in 2.6 and I was able to get some nice hiss when doing 'cat /dev/urandom > /dev/dsp'. I used the following modprobe line: modprobe opl3sa2 io=0x370 irq=11 dma=0 dma2=1 mss_io=0x530 isapnp=0 the isapnp=0 part appeared to be required. The following showed up in dmesg upon inserting the OSS module: opl3sa2: Chipset version = 0x7 opl3sa2: Found OPL3-SA3 (YMF715E or YMF719E) However, when I try to rmmod the opl3sa2 module, I get an Oops: Unable to handle kernel NULL pointer dereference at virtual address printing eip: c037ae01 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: opl3sa2 ad1848 mpu401 sound soundcore vfat fat sd_mod usb_storage lp parport ide_scsi rtc CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010046 (2.6.12.2) EIP is at wait_for_completion+0x71/0xf0 eax: cca91180 ebx: c52ea000 ecx: c52ebf20 edx: esi: c52ea000 edi: cca9117c ebp: c52ebf40 esp: c52ebef4 ds: 007b es: 007b ss: 0068 Process rmmod (pid: 11277, threadinfo=c52ea000 task=c79ce550) Stack: c79ce550 c0113cf0 c52ea000 c0e899e0 c0209ffe 0001 c79ce550 c0113cf0 cca91180 0114 0001 cca91174 0114 0001 c52ea000 cca8f964 cca91174 cca91200 Call Trace: [] default_wake_function+0x0/0x20 [] kobject_put+0x1e/0x30 [] default_wake_function+0x0/0x20 [] cleanup_opl3sa2+0x74/0x8c [opl3sa2] [] sys_delete_module+0x178/0x1b0 [] sys_munmap+0x50/0x80 [] syscall_call+0x7/0xb Code: 00 00 8b 03 c7 45 d4 01 00 00 00 c7 45 bc f0 3c 11 c0 c7 45 dc f0 3c 11 c0 89 45 b8 89 45 d8 8d 47 04 8b 50 04 89 45 e0 89 48 04 <89> 0a 89 55 e4 8d 76 00 8d bc 27 00 00 00 00 8b 03 c7 00 02 00 <6>note: rmmod[11277] exited with preempt_count 1 and now when I try to rmmod the module again, I get: ERROR: Removing 'opl3sa2': Device or resource busy So, yes, given the correct parameters, the OSS module (just like the ALSA module) works with the occasional Oops. I guess the Oopses are acceptable for now; it's the ALSA detection routines that are broken themselves or that are broken by something in the 2.6 kernel (remember that they work fine in 2.4). Thanks. -Andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Kernel doesn't free Cached Memory
Bill Davidsen wrote: {
Al Boldi wrote:
> Dick Johnson wrote: {
>
>>On Fri, 2005-07-22 at 08:27 -0300, Vinicius wrote:
>>[...]
>>
>>> I have a server with 2 Pentium 4 HT processors and 32 GB of RAM,
>>>this server runs lots of applications that consume lots of memory to.
>>>When I stop this applications, the kernel doesn't free memory (the
>>>memory still in use) and the server cache lots of memory (~27GB).
>>>When I start this applications, the kernel sends "Out of Memory"
>>>messages and kill some random applications.
>
>
> ...you might even need to turn memory over-commit off:
> echo "0" > /proc/sys/vm/overcommit_memory
> }
>
> That's in 2.4. In 2.6 it's:
> echo "2" > /proc/sys/vm/overcommit_memory
RHEL3 *is* a 2.4 kernel.
>
> But the kernel doesn't honor no-overcommit in either version, i.e. it
still
> overcommits/pages-out loaded/running procs, thus invoking OOM!
>
> Is there a way to make the kernel strictly honor the no-overcommit
request?
>
Don't have swap?
}
Turn off swap and things get worse!
Paolo Ornati wrote:{
Bill Davidsen <[EMAIL PROTECTED]> wrote:
> And IMHO Linux is *way* too willing to evicy clean pages of my
> programs to use as disk buffer, so that when system memory is full I
> pay the overhead of TWO disk i/o's, one to finally write the data to
> the disk and one to read my program back in. If free software is
> about choice, I wish there was more in the area of how memory is
> used.
isn't this tuned enough by "/proc/sys/vm/swappiness" ?
}
Swappiness tunes but does not inhibit overcommit!
So the question remains:
Why Is there no way to make the kernel _strictly_ honor the
no-overcommit request?
--
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: kernel optimization
Dr. Horst H. von Brand wrote: {
Al Boldi <[EMAIL PROTECTED]> wrote:
> Adrian Bunk wrote: {
> On Fri, Jul 22, 2005 at 07:55:48PM +0100, christos gentsis wrote:
> > i would like to ask if it possible to change the optimization of the
> > kernel from -O2 to -O3 :D, how can i do that? if i change it to the
> > top level Makefile does it change to all the Makefiles?
> And since it's larger, it's also slower.
> }
> It's faster but it's flawed. Root-NFS boot failed!
How do you know that it is faster if it is busted?
}
The -O3 compile produces a faster kernel, which seems to work perfectly,
albeit the Root-NFS boot flaw!
--
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.13-rc3 Battery times at 100/250/1000 Hz = Zero difference
>>>Digging up this patch from last month regarding C2 >>>on a AMD K7 implies >>>that the whole blame can be put on kernel acpi: >>> >>>http://marc.theaimsgroup.com/?l=linux-kernel=111933745131301=2 The current Linus tree includes generic ACPI support for deep C-states on SMP machines. (deep means higher than C1) I don't have any problem with people having platform specific modules to handle platform specific features. However, if the system really intends to support SMP ACPI C-states deeper than C1 and the generic ACPI code doesn't support it, then it is either a Linux/ACPI bug or a BIOS bug -- file away:-) I.e. The whole concept of ACPI is that you shoulud _not_ need a platform specific driver to accomplish this. cheers, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ppc32: Fix building of radstone_ppc7d
Updated radstone_ppc7d_defconfig to include the ds1337 driver which is used by the platform code. This fixes the link error when building. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- commit dc5a25603c1f8984f10f9e93d91b4d95b2ce6d9d tree 84b86f1b54b4d703a447aa6650ffe4a3e398ed13 parent b9540327726da964f8ac27185d01ccf244ea8e46 author Kumar K. Gala <[EMAIL PROTECTED]> Tue, 26 Jul 2005 00:08:58 -0500 committer Kumar K. Gala <[EMAIL PROTECTED]> Tue, 26 Jul 2005 00:08:58 -0500 arch/ppc/configs/radstone_ppc7d_defconfig | 234 + 1 files changed, 135 insertions(+), 99 deletions(-) diff --git a/arch/ppc/configs/radstone_ppc7d_defconfig b/arch/ppc/configs/radstone_ppc7d_defconfig --- a/arch/ppc/configs/radstone_ppc7d_defconfig +++ b/arch/ppc/configs/radstone_ppc7d_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.11 -# Tue Mar 15 14:31:19 2005 +# Linux kernel version: 2.6.13-rc3 +# Tue Jul 26 00:02:09 2005 # CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y @@ -11,6 +11,7 @@ CONFIG_HAVE_DEC_LOCK=y CONFIG_PPC=y CONFIG_PPC32=y CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # # Code maturity level options @@ -18,6 +19,7 @@ CONFIG_GENERIC_NVRAM=y CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup @@ -35,6 +37,8 @@ CONFIG_KOBJECT_UEVENT=y CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_PRINTK=y +CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y @@ -67,9 +71,12 @@ CONFIG_6xx=y # CONFIG_POWER3 is not set # CONFIG_POWER4 is not set # CONFIG_8xx is not set +# CONFIG_E200 is not set # CONFIG_E500 is not set +CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y # CONFIG_TAU is not set +# CONFIG_KEXEC is not set # CONFIG_CPU_FREQ is not set CONFIG_PPC_GEN550=y # CONFIG_PM is not set @@ -84,21 +91,18 @@ CONFIG_PPC_STD_MMU=y # CONFIG_KATANA is not set # CONFIG_WILLOW is not set # CONFIG_CPCI690 is not set -# CONFIG_PCORE is not set # CONFIG_POWERPMC250 is not set # CONFIG_CHESTNUT is not set # CONFIG_SPRUCE is not set +# CONFIG_HDPU is not set # CONFIG_EV64260 is not set # CONFIG_LOPEC is not set -# CONFIG_MCPN765 is not set # CONFIG_MVME5100 is not set # CONFIG_PPLUS is not set # CONFIG_PRPMC750 is not set # CONFIG_PRPMC800 is not set # CONFIG_SANDPOINT is not set CONFIG_RADSTONE_PPC7D=y -# CONFIG_ADIR is not set -# CONFIG_K2 is not set # CONFIG_PAL4 is not set # CONFIG_GEMINI is not set # CONFIG_EST8260 is not set @@ -121,10 +125,18 @@ CONFIG_MV64X60_NEW_BASE=0xfef0 # CONFIG_SMP is not set # CONFIG_PREEMPT is not set # CONFIG_HIGHMEM is not set +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="console=ttyS0,9600" +CONFIG_SECCOMP=y +CONFIG_ISA_DMA_API=y # # Bus options @@ -155,6 +167,69 @@ CONFIG_TASK_SIZE=0x8000 CONFIG_BOOT_LOAD=0x0080 # +# Networking +# +CONFIG_NET=y + +# +# Networking options +# +CONFIG_PACKET=y +# CONFIG_PACKET_MMAP is not set +CONFIG_UNIX=y +# CONFIG_NET_KEY is not set +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_FIB_HASH=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +# CONFIG_IP_PNP_RARP is not set +# CONFIG_NET_IPIP is not set +# CONFIG_NET_IPGRE is not set +# CONFIG_IP_MROUTE is not set +# CONFIG_ARPD is not set +CONFIG_SYN_COOKIES=y +# CONFIG_INET_AH is not set +# CONFIG_INET_ESP is not set +# CONFIG_INET_IPCOMP is not set +# CONFIG_INET_TUNNEL is not set +CONFIG_IP_TCPDIAG=y +# CONFIG_IP_TCPDIAG_IPV6 is not set +# CONFIG_TCP_CONG_ADVANCED is not set +CONFIG_TCP_CONG_BIC=y +# CONFIG_IPV6 is not set +# CONFIG_NETFILTER is not set + +# +# SCTP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_SCTP is not set +# CONFIG_ATM is not set +CONFIG_BRIDGE=y +# CONFIG_VLAN_8021Q is not set +# CONFIG_DECNET is not set +# CONFIG_LLC2 is not set +# CONFIG_IPX is not set +# CONFIG_ATALK is not set +# CONFIG_X25 is not set +# CONFIG_LAPB is not set +# CONFIG_NET_DIVERT is not set +# CONFIG_ECONET is not set +# CONFIG_WAN_ROUTER is not set +# CONFIG_NET_SCHED is not set +# CONFIG_NET_CLS_ROUTE is not set + +# +# Network testing +# +# CONFIG_NET_PKTGEN is not set +# CONFIG_HAMRADIO is not set +# CONFIG_IRDA is not set +# CONFIG_BT is not set + +# # Device Drivers # @@ -203,6 +278,7 @@ CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set +# CONFIG_MTD_OTP is not set CONFIG_MTD_CFI_INTELEXT=y # CONFIG_MTD_CFI_AMDSTD is not set # CONFIG_MTD_CFI_STAA is not set @@ -210,13 +286,13 @@ CONFIG_MTD_CFI_UTIL=y # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set -# CONFIG_MTD_XIP is not set # # Mapping drivers
[PATCH] ppc32: Fix building of prpmc750
Updated prpmc750 platform code to include serial_reg.h to fix building. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- commit c6d47b85a4f5743a0328ab6388a085744e00ac48 tree 41a83749e10e4dc70feefcd75396c8c5385b8fb1 parent dc5a25603c1f8984f10f9e93d91b4d95b2ce6d9d author Kumar K. Gala <[EMAIL PROTECTED]> Tue, 26 Jul 2005 00:12:37 -0500 committer Kumar K. Gala <[EMAIL PROTECTED]> Tue, 26 Jul 2005 00:12:37 -0500 arch/ppc/platforms/prpmc750.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/ppc/platforms/prpmc750.c b/arch/ppc/platforms/prpmc750.c --- a/arch/ppc/platforms/prpmc750.c +++ b/arch/ppc/platforms/prpmc750.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: relayfs documentation sucks?
On Mon, Jul 25, 2005 at 07:47:45PM -0400, Karim Yaghmour wrote: > Now if only I could remember what I talked about after I left the Black > Thorn at 2h45am and the guy in the elevator at Les Suites pressed on a > button and said "'M' for more beer" ... I bet in involved 'M' for more markers, Karim :-) -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM:Machine hangs on pulling out USB cd writer on laptop.
On Monday 25 July 2005 9:31 pm, Puneet Vyas wrote: > Alejandro Bonilla wrote: > > Puneet Vyas wrote: > >> PS : I am not even sure if I am "allowed" to pull out the writer > >> like this. Am I supposed to "stop" the device first or something? > > > > You are supoused to unmount the volume. Try it. umount /dev/cdrom ? > > Make sure that is it not in use, then unload it. > > New versions of gnome and so have the option to right click the > > loaded device and then to unmount. > > > > It should never hang. Does it hang with the floppy when removed? > > 1. When I did umount /dev/cdrom it says - "umount: /dev/hdc is not > mounted (according to mtab)" at present, you cannot unmount a device, you have to unmount the mountpoint. Although 'unmount by device' might be a useful feature, it isn't currently supported. it probably is something like /mnt/cdrom. however, this varies by distro and other factors. > 2. Yes > > Thanks, > Puneet -- * Overfiend ponders doing an NMU of asclock, in which he simply changes the extended description to "If you bend over and put your head between your legs, you can read the time off your assclock." Overfiend: go to bed. pgpGIJRjnDSmM.pgp Description: PGP signature
RE: Power consumption HZ250 vs. HZ1000
yes, this approach is valid. I've done the exact same measurements for 100HZ vs 1000HZ. For currently shipping laptops, I didn't see a significant difference., Note that the quality of the instrumentation on the battery can vary widely, and so if you really want the best numbers you need to start from a fully charged battery and run it until the battery dies. Also, for the most controlled experiment, you can run in single user mode with no network, no USB plugged in, and either "performance" or "powersave" governors. If you don't get into C3 on this box nearly all the time then something is wrong. cheers, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Netlink connector
On Mon, Jul 25, 2005 at 09:56:56PM -0700, Stephen Hemminger ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov wrote: > > >On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy > >([EMAIL PROTECTED]) wrote: > > > > > >>Evgeniy Polyakov wrote: > >> > >> > >>>On Mon, Jul 25, 2005 at 04:32:32PM +0200, Patrick McHardy > >>>([EMAIL PROTECTED]) wrote: > >>> > >>> > >>> > If I understand correctly it tries to workaround some netlink > limitations (limited number of netlink families and multicast groups) > by sending everything to userspace and demultiplexing it there. > Same in the other direction, an additional layer on top of netlink > does basically the same thing netlink already does. This looks like > a step in the wrong direction to me, netlink should instead be fixed > to support what is needed. > > > >>>Not only it. > >>>The main _first_ idea was to simplify userspace mesasge handling as much > >>>as possible. > >>>In first releases I called it ioctl-ng - any module that want ot > >>>communicate with userspace in the way ioctl does, > >>> > >>> > >>Usually netlink is easily extendable by using nested TLVs. By hiding > >>this you basically remove this extensibility. > >> > >> > > > >Current netlink is not extensible for _many_ different users. > >It has only 32 sockets. > > > > > > > >>>requires skb allocation/freeing/handling. > >>>Does RTC driver writer need to know what is the difference between > >>>shared and cloned skb? Should kernel user of such message bus > >>>have to know about skb at all? > >>> > >>> > >>Netlink users don't have to care about shared or cloned skbs. I don't > >>think its a big issue to use alloc_skb and then the usual netlink > >>macros. Thomas added a number of macros that simplfiy use a lot. > >> > >> > > > >Kernel user also must know about difference between unicast/broadcast, > >how to dequeue the skb, how to free it and in what context. > >ioctl users do not need to know how file_operations is bound to file. > > > > > > > >>But my main objection is that it sends everything to userspace even > >>if noone is listening. This can't be used for things that generate > >>lots of events, and also will get problematic is the number of users > >>increases. > >> > >> > > > >It is a problem for existing netlink - either check in bind time, > >what could be done for connector, or in socket creation time. > > > >Actually it is not even a problem, since checking is being done, > >but after allocation and message filling, such check can be moved into > >cn_netlink_send() in connector, but different netlink users, > >who prefers to use different sockets, must perform it by itself in each > >place, where skb is allocated... > > > >Connector is a solution for current situation, > >it can be deployed with few casualties. > >Creating a new netlink2 socket for device, which wants to replace ioctl > >controlling or broadcast it's state is a wrong way. > >Different sockets/flows does not allow easy flow control. > > > >We have one pipe - ethernet, and many protocols inside this pipe > >with different headers - it is the same here - netlink is such a pipe, > >and with connector it allows to have different protocols in it. > > > > > > > >>>With char device I only need to register my callback - with kernel > >>>connector it is the same, but allows to use the whole power of netlink, > >>>especially without nice ioctl features like different pointer size > >>>in userspace and kernelspace. > >>> > >>> > >>You still have to take care of mixed 64/32 bit environments, u64 fields > >>for example are differently alligned. > >> > >> > > > >Connector has a size in it's header - ioctl does not. > > > > > > > >>>And number of free netlink sockets is _very_ small, especially > >>>if allocate new one for simple notifications, which can be easily done > >>>using connector. > >>> > >>> > >>Then fix it so we can use more families and groups. I started some work > >>on this, but I'm not sure if I have time to complete it. > >> > >> > > > >It does not "fix" the "problem" of skb management knowledge, which I > >described. > >Netlink is a transport protocol, some general logic must be created on > >top of it, like it is done in TCP/IP. > > > > > > > >>>And netlink can be extended to support it - netlink is a transport > >>>protocol, it should not care about higher layer message handling, > >>>connector instead will deliver message to the end user in a very > >>>convenient form. > >>> > >>> > >>You can still built this stuff on top, but the workarounds for netlink > >>limitations need to be fixed in netlink. > >> > >> > > > >I could not call it workaround, I think it is a management layer, > >which allows : > >1. easy usage. Just register a callback and that is all. Callback will > >be invoced each time new message arrives. No need to > >dequeue/free/anything. > >2. easy usage. Call one function for message
Re: Kernel cached memory
John Pearson wrote: Wouldn't having (practically) all your memory used for cache slow down starting a new program? First it would have to free up that space, and then put stuff in that space, taking potentially twice as long. If the cache pages are clean (not been modified since they were read from the disk), then evicting that data will not take very long. If the program you are just starting is not in the cache, then the time taken to load it from disk will dwarf the time needed to evict cached pages. And there's also the possibility that the cache contains the data you are loading, which definitely will speed things up.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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: ACPI oddity
>On a HT system, why does ACPI recognize CPU0 and CPU1, refer >to them as such in dmesg This is the Linux CPU number. ie the namespace where 0 is the boot processor and the others are numbered in the order that they were started. > and then call them CPU1 and CPU2 in >/proc/acpi/processor? These are arbitrary device identifiers written by the BIOS developer and foolishly advertised to the user by Linux. The BIOS writer could have also called them ABC9 and XYZ4 and it would be equally valid. We're planning to get rid of all the ACPI stuff in /proc and move to sysfs. At that time we'll use device identifies that are deterministic, like cpu%d that /sys/devices/system uses today. cheers, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Netlink connector
Evgeniy Polyakov wrote: On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: Evgeniy Polyakov wrote: On Mon, Jul 25, 2005 at 04:32:32PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: If I understand correctly it tries to workaround some netlink limitations (limited number of netlink families and multicast groups) by sending everything to userspace and demultiplexing it there. Same in the other direction, an additional layer on top of netlink does basically the same thing netlink already does. This looks like a step in the wrong direction to me, netlink should instead be fixed to support what is needed. Not only it. The main _first_ idea was to simplify userspace mesasge handling as much as possible. In first releases I called it ioctl-ng - any module that want ot communicate with userspace in the way ioctl does, Usually netlink is easily extendable by using nested TLVs. By hiding this you basically remove this extensibility. Current netlink is not extensible for _many_ different users. It has only 32 sockets. requires skb allocation/freeing/handling. Does RTC driver writer need to know what is the difference between shared and cloned skb? Should kernel user of such message bus have to know about skb at all? Netlink users don't have to care about shared or cloned skbs. I don't think its a big issue to use alloc_skb and then the usual netlink macros. Thomas added a number of macros that simplfiy use a lot. Kernel user also must know about difference between unicast/broadcast, how to dequeue the skb, how to free it and in what context. ioctl users do not need to know how file_operations is bound to file. But my main objection is that it sends everything to userspace even if noone is listening. This can't be used for things that generate lots of events, and also will get problematic is the number of users increases. It is a problem for existing netlink - either check in bind time, what could be done for connector, or in socket creation time. Actually it is not even a problem, since checking is being done, but after allocation and message filling, such check can be moved into cn_netlink_send() in connector, but different netlink users, who prefers to use different sockets, must perform it by itself in each place, where skb is allocated... Connector is a solution for current situation, it can be deployed with few casualties. Creating a new netlink2 socket for device, which wants to replace ioctl controlling or broadcast it's state is a wrong way. Different sockets/flows does not allow easy flow control. We have one pipe - ethernet, and many protocols inside this pipe with different headers - it is the same here - netlink is such a pipe, and with connector it allows to have different protocols in it. With char device I only need to register my callback - with kernel connector it is the same, but allows to use the whole power of netlink, especially without nice ioctl features like different pointer size in userspace and kernelspace. You still have to take care of mixed 64/32 bit environments, u64 fields for example are differently alligned. Connector has a size in it's header - ioctl does not. And number of free netlink sockets is _very_ small, especially if allocate new one for simple notifications, which can be easily done using connector. Then fix it so we can use more families and groups. I started some work on this, but I'm not sure if I have time to complete it. It does not "fix" the "problem" of skb management knowledge, which I described. Netlink is a transport protocol, some general logic must be created on top of it, like it is done in TCP/IP. And netlink can be extended to support it - netlink is a transport protocol, it should not care about higher layer message handling, connector instead will deliver message to the end user in a very convenient form. You can still built this stuff on top, but the workarounds for netlink limitations need to be fixed in netlink. I could not call it workaround, I think it is a management layer, which allows : 1. easy usage. Just register a callback and that is all. Callback will be invoced each time new message arrives. No need to dequeue/free/anything. 2. easy usage. Call one function for message delivering, which can care of nonexistent users, perform flow control, congestion control, guarantee delivery and any other. 3. Easily deployable - current implementation is so simple, and it does work with existing netlink. 4. It is logical level on top of transport protocol, it is UDP/IP over ethernet :) If it is a transport, then it should be in the kernel. Otherwise, it becomes painful for applications with multiple input sources. Think of epoll/poll/select and threads, doing the demultiplexing in user space would be a pain for applications and libraries. The other way to go is
PCI: fix up errors after dma bursting patch and CONFIG_PCI=n -- bug?
Andrew,
In the patch from:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0506.3/0985.html
Is the the following line suppose inside the if CONFIG_PCI=n
#define pci_dma_burst_advice(pdev, strat, strategy_parameter) do { } while (0)
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
diff --git a/include/linux/pci.h b/include/linux/pci.h
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -971,6 +971,8 @@ static inline int pci_enable_wake(struct
#defineisa_bridge ((struct pci_dev *)NULL)
+#define pci_dma_burst_advice(pdev, strat, strategy_parameter) do { } while (0)
+
#else
/*
@@ -985,9 +987,6 @@ static inline int pci_proc_domain(struct
return 0;
}
#endif
-
-#define pci_dma_burst_advice(pdev, strat, strategy_parameter) do { } while (0)
-
#endif /* !CONFIG_PCI */
/* these helpers provide future and backwards compatibility
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Netlink connector
On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov wrote: > >On Mon, Jul 25, 2005 at 04:32:32PM +0200, Patrick McHardy > >([EMAIL PROTECTED]) wrote: > > > >>If I understand correctly it tries to workaround some netlink > >>limitations (limited number of netlink families and multicast groups) > >>by sending everything to userspace and demultiplexing it there. > >>Same in the other direction, an additional layer on top of netlink > >>does basically the same thing netlink already does. This looks like > >>a step in the wrong direction to me, netlink should instead be fixed > >>to support what is needed. > > > >Not only it. > >The main _first_ idea was to simplify userspace mesasge handling as much > >as possible. > >In first releases I called it ioctl-ng - any module that want ot > >communicate with userspace in the way ioctl does, > > Usually netlink is easily extendable by using nested TLVs. By hiding > this you basically remove this extensibility. Current netlink is not extensible for _many_ different users. It has only 32 sockets. > >requires skb allocation/freeing/handling. > >Does RTC driver writer need to know what is the difference between > >shared and cloned skb? Should kernel user of such message bus > >have to know about skb at all? > > Netlink users don't have to care about shared or cloned skbs. I don't > think its a big issue to use alloc_skb and then the usual netlink > macros. Thomas added a number of macros that simplfiy use a lot. Kernel user also must know about difference between unicast/broadcast, how to dequeue the skb, how to free it and in what context. ioctl users do not need to know how file_operations is bound to file. > But my main objection is that it sends everything to userspace even > if noone is listening. This can't be used for things that generate > lots of events, and also will get problematic is the number of users > increases. It is a problem for existing netlink - either check in bind time, what could be done for connector, or in socket creation time. Actually it is not even a problem, since checking is being done, but after allocation and message filling, such check can be moved into cn_netlink_send() in connector, but different netlink users, who prefers to use different sockets, must perform it by itself in each place, where skb is allocated... Connector is a solution for current situation, it can be deployed with few casualties. Creating a new netlink2 socket for device, which wants to replace ioctl controlling or broadcast it's state is a wrong way. Different sockets/flows does not allow easy flow control. We have one pipe - ethernet, and many protocols inside this pipe with different headers - it is the same here - netlink is such a pipe, and with connector it allows to have different protocols in it. > >With char device I only need to register my callback - with kernel > >connector it is the same, but allows to use the whole power of netlink, > >especially without nice ioctl features like different pointer size > >in userspace and kernelspace. > > You still have to take care of mixed 64/32 bit environments, u64 fields > for example are differently alligned. Connector has a size in it's header - ioctl does not. > >And number of free netlink sockets is _very_ small, especially > >if allocate new one for simple notifications, which can be easily done > >using connector. > > Then fix it so we can use more families and groups. I started some work > on this, but I'm not sure if I have time to complete it. It does not "fix" the "problem" of skb management knowledge, which I described. Netlink is a transport protocol, some general logic must be created on top of it, like it is done in TCP/IP. > >And netlink can be extended to support it - netlink is a transport > >protocol, it should not care about higher layer message handling, > >connector instead will deliver message to the end user in a very > >convenient form. > > You can still built this stuff on top, but the workarounds for netlink > limitations need to be fixed in netlink. I could not call it workaround, I think it is a management layer, which allows : 1. easy usage. Just register a callback and that is all. Callback will be invoced each time new message arrives. No need to dequeue/free/anything. 2. easy usage. Call one function for message delivering, which can care of nonexistent users, perform flow control, congestion control, guarantee delivery and any other. 3. Easily deployable - current implementation is so simple, and it does work with existing netlink. 4. It is logical level on top of transport protocol, it is UDP/IP over ethernet :) > >P.S. I've removed [EMAIL PROTECTED] - please do not add subscribers-only > >private mail lists. > > Wasn't me :) Yep :) -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info
setting task->ioprio from a kernel thread
In OCFS2 there is currently an in-kernel heartbeat thread that really wants to communicate liveness to other nodes as quickly as possible by writing to a block device. Setting aside the specific wisdom of a kernel heartbeat thread for a bit, has it been considered that kernel threads might want to set their io priority with the task->ioprio bits? Neither set_task_ioprio() nor sys_ioprio_set() seem to be accessible to modules and open-coding it is clearly a bad idea. Would the universe be opposed to a _GPL() export of, say, the sys_() interface? - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 missing tvaudio try_to_freeze.
Nigel Cunningham wrote: On Tue, 2005-07-26 at 03:34, Mauro Carvalho Chehab wrote: Nigel Cunningham wrote: The .c gives Gerd Knorr as the maintainer of this file, but no email address. The MAINTAINERS file doesn't have his name or make it clear who owns the file. I haven't therefore been able to cc the maintainer. I'm current maintainer of V4L. The patch was tested and it looks ok. Thanks! Would you consider sending a patch to the maintainers file too? As you can see below, this has already been done. [PATCH] V4L maintainer patch authorMauro Carvalho Chehab <[EMAIL PROTECTED]> Wed, 29 Jun 2005 03:45:20 + (20:45 -0700) committerLinus Torvalds <[EMAIL PROTECTED]> Wed, 29 Jun 2005 04:20:36 + (21:20 -0700) commit96b6aba08762f09e5dfa616854cb80ce054a7bf8 tree788823ba3676e17b5f376ec6718dcf60662eaf87tree parent200803dfe4ff772740d63db725ab2f1b185ccf92commit | commitdiff [PATCH] V4L maintainer patch This patch updates maintainer info for BTTV and V4L. Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]> Acked-by: Gerd Knorr <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> -- Michael Krufky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 missing tvaudio try_to_freeze.
Hi. On Tue, 2005-07-26 at 03:34, Mauro Carvalho Chehab wrote: > Nigel, > > Nigel Cunningham wrote: > > Hi. > > > > The .c gives Gerd Knorr as the maintainer of this file, but no email > > address. The MAINTAINERS file doesn't have his name or make it clear who > > owns the file. I haven't therefore been able to cc the maintainer. > > I'm current maintainer of V4L. The patch was tested and it looks ok. Thanks! Would you consider sending a patch to the maintainers file too? Regards, Nigel > > > > Tvaudio lacks a refrigerator call. This patch fixes that. > > > > Regards, > > > > Nigel > > > > Signed-off by: Nigel Cunningham <[EMAIL PROTECTED]> > Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]> -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Incorrect driver getting loaded for Qlogic FC-HBA
On 7/26/05, Greg KH <[EMAIL PROTECTED]> wrote: > On Mon, Jul 25, 2005 at 11:02:39AM +0900, Rajat Jain wrote: > > I'm using Kernel 2.6.9 and am having a Qlogic QLE2362 FC-HBA in my > > system. I selected all the Qlogic SCSI drivers while buiding the > > kernel. Now the problem is that every time I reboot, I have to > > MANUALLY modprobe the qla2322.ko module in the kernel and only then my > > HBA works. By default, the kernel loads qla2300.ko, which is not the > > correct driver for the card, and hence the HBA does not work. Here is > > the lspci output: > > "by default" the kernel does not load any modules. That's up to the > hotplug system, or some other package. > > thanks, > > greg k-h > Thanks. I just checked .. that is right. So let me put it this way. When ever I hot-plug my HBA into the system, the driver "qla2300" gets loaded. Where as the correct driver is "qla2322". This evident from the output of "modules.pcimap" file and "lspci". The PCI device number of HBA is 2322. and in modules.pcimap file, qla2322 is supposed to be loaded when this HBA is hot-plugged. But module qla2300 is getting loaded. Any pointers on where could the problem be? Or how should I approach this problem? Thanks a lot. Rajat PS: For reference I am attaching the modules.pcimap file and lspci output here again: - 0d:07.1 Fibre Channel: QLogic Corp.: Unknown device 2322 (rev 03) Subsystem: QLogic Corp.: Unknown device 0118 Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 185 I/O ports at 6400 [size=256] Memory at d0401000 (64-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 Capabilities: [4c] PCI-X non-bridge device. Capabilities: [54] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- --- Here is the relevant extract from modules.pcimap: --- #module vendor device subvendor subdevice class class_mask driver_data qla2300 0x1077 0x2300 0x 0x 0x 0x 0x0 qla2300 0x1077 0x2312 0x 0x 0x 0x 0x0 qla2322 0x1077 0x2322 0x 0x 0x 0x 0x0 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: Oops in hidinput_hid_event
On Mon, 25 Jul 2005 20:52:26 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > Do you expect this patch: > > > --- linux-2.6.12/drivers/usb/input/hid-input.c 2005-06-21 > > 12:58:47.0 -0700 > > - struct input_dev *input = >hidinput->input; > > + struct input_dev *input; > > - if (!input) > > + if (!field->hidinput) > > return; > > + input = >hidinput->input; > To actually fix the above oops? It sure looks like it will. > But I worry whether it is the correct fix? It is a correct fix, safe to apply. However, Vojtech wrote me that he will look how exactly an event can be reported without associated infrastructure. Personally, I suspect that this has something to do with the motherboard in question. Perhas the PS/2 port is disabled somehow... -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: Oops in hidinput_hid_event
Pete Zaitcev <[EMAIL PROTECTED]> wrote:
>
> I think this patch is rather obvious, so maybe I should ask Andrew to
> apply it to -mm for now, to get some testing. Would that help to verify
> it for acceptance?
>
> -- Pete
>
> Begin forwarded message:
>
> Date: Tue, 28 Jun 2005 15:00:23 -0700
> From: Pete Zaitcev <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED], linux-usb-devel@lists.sourceforge.net
> Subject: Oops in hidinput_hid_event
>
> Hi, Vojtech:
>
> Someone reported a bug in Fedora, which runs a largely unmodified upstream
> kernel in this area. Whenever the user hits a key which switches LED,
> the system oopses. Here's a trace:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00c8
> EFLAGS: 00010006 (2.6.11-1.1369_FC4smp)
> EIP is at hidinput_hid_event+0x2d/0x292
> Call Trace:
> [] hid_process_event+0x57/0x5f
> [] hid_input_field+0x2a2/0x2ac
> [] hid_input_report+0x9e/0xb8
> [] hid_ctrl+0x14c/0x151
> [] uhci_destroy_urb_priv+0xb5/0x10a [uhci_hcd]
> [] usb_hcd_giveback_urb+0x24/0x67
> [] uhci_finish_urb+0x2d/0x38 [uhci_hcd]
> [] uhci_finish_completion+0x44/0x56 [uhci_hcd]
> [] uhci_scan_schedule+0xaa/0x13a [uhci_hcd]
> [] i8042_interrupt+0x121/0x234
> [] uhci_irq+0x47/0x10d [uhci_hcd]
>
> Full trace at
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160709
>
> Any ideas?
>
> By the way, it seems that I see a bug in hidinput_hid_event.
> The check for NULL can never work, becaue >input
> is nonzero at all times. How about this?
Do you expect this patch:
> --- linux-2.6.12/drivers/usb/input/hid-input.c2005-06-21
> 12:58:47.0 -0700
> +++ linux-2.6.12-lem/drivers/usb/input/hid-input.c2005-06-28
> 14:57:22.0 -0700
> @@ -397,11 +397,12 @@
>
> void hidinput_hid_event(struct hid_device *hid, struct hid_field *field,
> struct hid_usage *usage, __s32 value, struct pt_regs *regs)
> {
> - struct input_dev *input = >hidinput->input;
> + struct input_dev *input;
> int *quirks = >quirks;
>
> - if (!input)
> + if (!field->hidinput)
> return;
> + input = >hidinput->input;
>
> input_regs(input, regs);
To actually fix the above oops? It sure looks like it will. But I worry
whether it is the correct fix?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Fw: [PATCH] x86_64: fix SMP boot lockup on some machines
People who are experiencing early-boot lockups on x86_64
might find this useful..
Don't compare linux processor index with APICID
Fixes boot up lockups on some machines where CPU apic ids
don't start with 0
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/arch/x86_64/kernel/smpboot.c
===
--- linux.orig/arch/x86_64/kernel/smpboot.c
+++ linux/arch/x86_64/kernel/smpboot.c
@@ -211,7 +211,7 @@ static __cpuinit void sync_master(void *
{
unsigned long flags, i;
- if (smp_processor_id() != boot_cpu_id)
+ if (smp_processor_id() != 0)
return;
go[MASTER] = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: Add the ability to unbind drivers to devices from userspace
On Monday 25 July 2005 22:15, Jon Smirl wrote:
> + while( isspace(*x) && (x - buffer->page < count))
> + x++;
> +
> + /* locate trailng white space */
> + z = y = x;
> + while (y - buffer->page < count) {
> + y++;
> + z = y;
> + while( isspace(*y) && (y - buffer->page < count)) {
> + y++;
Can we have consistent space vs. paren placement, pretty please?
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ZyXEL Kernel /BusyBox GPL violation?
On Mon, 2005-07-25 at 23:21 -0400, Mace Moneta wrote: > The response seems meaningless; does this constitute a violation of > GPL? > If so what, if any, action needs to be taken? It sounds like they think you are asking for their userspace source code, or that support rep does not know the difference. Also if they didn't modify the kernel, they don't have to give you source, they can just refer you to kernel.org. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ZyXEL Kernel /BusyBox GPL violation?
I purchased a ZyXEL router, and noted in its log: 0day 00:00:16 klogd started: BusyBox v1.00-pre8 (2005.06.02-02:19+) 0day 00:00:16 Linux version 2.4.18-MIPS-01.00 ([EMAIL PROTECTED]) (gcc version 3.3.3) #53 Fri Jun 10 16:13:48 CST 2005 ... I contacted the vendor to request source, since no mention of it is made on their website (http://www.zyxel.com), or documentation: --- Subject: Linux GPL software for P-330W Where can I obtain the Linux software for the P-330W, as required under Gnu Public Licence (Firmware Version: v4.2.1.6.6e.)? --- Their response: --- Sir, Our unit is only based on Linux. It is not necessarily built off the source code. The code was developed by our engineers in Taiwan. As this is the case, we do not have access to the code here, and it is not covered by the GPL. If you need more assistance, please call at 1-800-255-4101. Thank you, Scott Latimer Technicial Support Specialist ZyXEL Communications 1130 N Miller Street Anaheim, CA 92806 A+, Network+ --- The response seems meaningless; does this constitute a violation of GPL? If so what, if any, action needs to be taken? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] driver core: Add the ability to unbind drivers to devices from userspace
On 7/25/05, Greg KH <[EMAIL PROTECTED]> wrote:
> > I'll put one together to trim leading/trailing white space from the
> > buffer before it is passed into the attribute functions. Now that I
> > think about this I believe the attributes should have always had the
> > leading/trailing white space removed. If we don't do it in the sysfs
> > code then every driver has to do it.
>
> Ok, sounds good.
How does this look? This is a count based interface but a lot of
attributes don't work unless I add the terminating zero. This
interface should be documented: count or zero terminated, white space
stripped or not, etc. Are these strings ASCII, UTF8, Unicode?
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -207,6 +208,28 @@ flush_write_buffer(struct dentry * dentr
struct attribute * attr = to_attr(dentry);
struct kobject * kobj = to_kobj(dentry->d_parent);
struct sysfs_ops * ops = buffer->ops;
+ char *x, *y, *z;
+
+ /* locate leading white space */
+ x = buffer->page;
+ while( isspace(*x) && (x - buffer->page < count))
+ x++;
+
+ /* locate trailng white space */
+ z = y = x;
+ while (y - buffer->page < count) {
+ y++;
+ z = y;
+ while( isspace(*y) && (y - buffer->page < count)) {
+ y++;
+ }
+ }
+ count = z - x;
+
+ /* strip the white space */
+ if (buffer->page != x)
+ memmove(buffer->page, x, count);
+ buffer->page[count] = '\0';
return ops->store(kobj,attr,buffer->page,count);
}
--
Jon Smirl
[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: [swsusp] encrypt suspend data for easy wiping
Andreas Steinmetz <[EMAIL PROTECTED]> wrote: > > the attached patches are acked by Pavel and signed off by me OK, well I queued this up, without a changelog. Because you didn't send one. Please do so. As it adds a new feature, quite a bit of info is relevant. It should include a description of what the patch tries to do, and how it does it. It should include a description of any known shortcomings. If any user configuration is needed then that should be placed somewhere under Documentation/ Take a look at how other people document their feature additions and you'll get the idea. Please don't send multiple patches per email. In this case I did the handwork and put both diffs into the same patch. Personally, I don't like this: +config SWSUSP_ENCRYPT + bool "Encrypt suspend image" + depends on SOFTWARE_SUSPEND && CRYPTO=y && (CRYPTO_AES=y || CRYPTO_AES_586=y || CRYPTO_AES_X86_64=y) This requires the user to hunt around in config until all the right options are enabled to permit SWSUSP_ENCRYPT to appear in config. That can be quite frustrating and is very poor UI. For a top-level feature such as this it is much better to always offer the feature to the user and to then use `select' to turn on all the infrastructure bits which the user will need. Make the computer do the work rather than the user. Yes, it might be a bit tricky in this case because you have a dependency on one of the AES encryption types, but it would be good if you can come up with something which doesn't force the user into a game of hide-and-seek. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM:Machine hangs on pulling out USB cd writer on laptop.
Puneet Vyas wrote: Alejandro Bonilla wrote: Puneet Vyas wrote: PS : I am not even sure if I am "allowed" to pull out the writer like this. Am I supposed to "stop" the device first or something? You are supoused to unmount the volume. Try it. umount /dev/cdrom ? Make sure that is it not in use, then unload it. New versions of gnome and so have the option to right click the loaded device and then to unmount. It should never hang. Does it hang with the floppy when removed? 1. When I did umount /dev/cdrom it says - "umount: /dev/hdc is not mounted (according to mtab)" 2. Yes Thanks, Puneet You are trying to unmount a /dev/hdc? hdc is an IDE Hard Drive, you have a CD burner, I would doubt that it is /de/hdc. type mount and that will tell you what is mounted, try umount /dev/cdrom. You need the hardware unloaded. Try /etc/init.d/hotplug stop and unplugg the hardware. See if that hangs the PC. Figure out on how to unload the module, then you will need to get us more info here for this problem to be looked... anyone has more suggestions? .Alejandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mlock oops
On Tue, 2005-07-26 at 04:43 +0200, Benoit Dejean wrote: > Hi, > i'm using Debian SID kernel-image-2.6.11-powerpc [1] (which is not > tainted). I've unfortunately started sysutils [2] memtest as user (no caps, no > sticky bit). > > /usr/sbin/memtest all > As expected, a few minutes later, my system was back. But an oops occured. That's not an Oops... > I was expecting the OOMK to rescue my system by killing memtest. > This is exactly what happened: > Out of Memory: Killed process 2386 (memtest). > memtest: page allocation failure. order:0, mode:0xd2 > Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: supposed to be shared subtree patches.
On Mon, 2005-07-25 at 15:44, Ram Pai wrote: > , [EMAIL PROTECTED], Janak Desai <[EMAIL PROTECTED]>, > linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org > Subject: [PATCH 0/7] shared subtree > > Hi Andrew/Al Viro, > > Enclosing a final set of well tested patches that implement my apologies. I screwed up sending the patches through quilt. anyway I have received the following comments from Andrew Morton, which I will incorporate before sending out saner looking patches. sorry again, RP Andrew's comments follows: Frankly, I don't even know what these patches _do_, and haven't spent the time to try to find out. If these patches are merged, how do we expect end-users to find out how to use the new capabilities? A few paragraphs in the patch #1 changelog would help. A high-level description of the new capability which explains what it does and why it would be a useful thing for Linux. And maybe some deeper information in a Documentation/ file. Right now, there might well be a lot of people who could use these new features, but they don't even know that these patches provide them! It's all a bit of a mystery, really. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.13-rc3] i386: clean up user_mode macros
On Mon, 2005-07-25 at 20:20 -0400, Steven Rostedt wrote: > And I > would also assume that you prefer x *= 2 over x <<= 1 (also since the > first person to show this example used x <<= 2. Right Lee? :-) Let us never speak of that again. These aren't the droids you're looking for. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mlock oops
Hi, i'm using Debian SID kernel-image-2.6.11-powerpc [1] (which is not tainted). I've unfortunately started sysutils [2] memtest as user (no caps, no sticky bit). /usr/sbin/memtest all I was expecting the OOMK to rescue my system by killing memtest. As expected, a few minutes later, my system was back. But an oops occured. Here's dmesg output : oom-killer: gfp_mask=0xd2 DMA per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 Normal per-cpu: empty HighMem per-cpu: empty Free pages:2856kB (0kB HighMem) Active:57185 inactive:57079 dirty:0 writeback:0 unstable:0 free:714 slab:3825 mapped:114890 pagetables:822 DMA free:2856kB min:2896kB low:3620kB high:4344kB active:228740kB inactive:228316kB present:524288kB pages_scanned:538055 all_unreclaimable? yes lowmem_reserve[]: 0 0 0 Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 0*4kB 1*8kB 32*16kB 23*32kB 3*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 2856kB Normal: empty HighMem: empty Swap cache: add 332526, delete 218150, find 72396/87670, race 0+0 Free swap = 219592kB Total swap = 976540kB Out of Memory: Killed process 2386 (memtest). memtest: page allocation failure. order:0, mode:0xd2 Call trace: [c0007450] dump_stack+0x18/0x28 [c003fa2c] __alloc_pages+0x2a4/0x3e4 [c004ce80] do_anonymous_page+0x98/0x4c8 [c004d320] do_no_page+0x70/0x798 [c004dc9c] handle_mm_fault+0xe8/0x1d8 [c004afa0] get_user_pages+0x124/0x4c4 [c004de20] make_pages_present+0x88/0xbc [c004e4ec] mlock_fixup+0xe4/0xe8 [c004e5f0] do_mlock+0x100/0x104 [c004e6b8] sys_mlock+0xc4/0x114 [c0004290] ret_from_syscall+0x0/0x4c Thanks. [1] http://packages.debian.org/unstable/base/kernel-image-2.6.11-powerpc [2] http://packages.debian.org/stable/utils/sysutils - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Merging relayfs?
Tom Zanussi wrote: > In userspace, the sub-buffer reading loop looks at the commit value in > the sub-buffer, and if it matches (sub-buffer size - padding), the > buffer has been completely written and can be saved, otherwise it's > not yet complete and is checked again the next time around. This way, > there's no need for a deliver() callback, the relay_commit() is > replaced with the increment of the reserved commit value, the arrays > aren't needed and you get the same result in the end in a much simpler > way, IMHO. Actually this has a much greater potential of loosing buffers because we have to poll the buffer for completion. Seen another way, the kernel- side has got to wait until the user-side has "figured out" that it needs to commit content to disk. As it was originally, it was relatively straightforward to dertermine why data was lost: ok, we've signaled it from kernel space, but the daemon never flushed it out. Without commit/ deliver, things are much less clear, and I still miss what gain we are making by removing them. I would very much like to see the commit/deliver functionality back. Such mechanisms are required for any sane producer-consumer model. Karim -- Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.13-rc3] i386: clean up user_mode macros
On Mon, 25 Jul 2005 18:34:13 -0700 Andrew Morton wrote: > Miles Bader <[EMAIL PROTECTED]> wrote: > > > > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > Ask a hundred random C programmers what "!!x" means, versus what "x != 0" > > > means, and time their replies. > > > > I've always thought of "!!" as the "canonicalize boolean" operator... > > Me too. Once you get used to it, it's just the "convert non-zero to 1" > operator. > > But whatever. I call it "truth value" (true or false), but once I got used to it, I thought it was OK too. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird USB errors on HD
Alistair John Strachan wrote: > You can get special USB cables that link two USB ports' 5Vs together in > parallel, which seems to help supply the necessary current; after the HD has > spun up you can remove the second "dummy" USB connector (my laptop only has > two USB ports and I require the second port). Yeah, there was one of these in the box with the drive, but the first time I saw it I remember thinking: what the hell is this thing? Then when I figured it out, I found myself wondering whether the USB interface was ever planed for such a such and whether it wouldn't have been better to just ship a real adapter with the thing ... Anyhow, I will not be using the drive anymore without a powered hub. Thanks for all those that helped, Karim -- Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: VIA KT400 + Kernel 2.6.12 + IO-APIC + uhci_hcd = IRQ trouble
> > Le Lundi 25 Juillet 2005 22:44, Alan Stern a écrit : > > > > > > Now that's strange. When you plug the high-speed device into the > > > integrated ports, which IRQ counter changes? Since > nothing is using > > > IRQ 21, it should be disabled and its counter should remain > > > constant. Does this mean the interrupts show up on IRQ > 19 (used by > > > ehci-hcd), or do they not show up at all (i.e., is the > USB connection just being polled)? > > > > I assume it's IRQ 19. > > > > cat /proc/interrupts doesn't show IRQ21 at all when uhci > isn't loaded. > > As it shouldn't, since nothing is supposed to be using that IRQ. > > > IRQ 19 being shared with 4 IDE controllers that controls my hard > > drives, that's hard to isolate interrupts counts due to USB > activity > > from interrupts counts due to disks activity... > > I was afraid you'd say that... > > Natalie, that's all I can think of. Now it's up to you to > invent a patch Michel can try out, to show just where the > IO-APIC code is going wrong. I will sure try... I'm keeping an eye on your exchange don't worry :) just have to get done with urgent work piled up here while on my trip :< ... --N > Alan Stern > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA KT400 + Kernel 2.6.12 + IO-APIC + uhci_hcd = IRQ trouble
On Tue, 26 Jul 2005, Michel Bouissou wrote: > Le Lundi 25 Juillet 2005 22:44, Alan Stern a écrit : > > > > Now that's strange. When you plug the high-speed device into the > > integrated ports, which IRQ counter changes? Since nothing is using IRQ > > 21, it should be disabled and its counter should remain constant. Does > > this mean the interrupts show up on IRQ 19 (used by ehci-hcd), or do they > > not show up at all (i.e., is the USB connection just being polled)? > > I assume it's IRQ 19. > > cat /proc/interrupts doesn't show IRQ21 at all when uhci isn't loaded. As it shouldn't, since nothing is supposed to be using that IRQ. > IRQ 19 being shared with 4 IDE controllers that controls my hard drives, > that's hard to isolate interrupts counts due to USB activity from interrupts > counts due to disks activity... I was afraid you'd say that... Natalie, that's all I can think of. Now it's up to you to invent a patch Michel can try out, to show just where the IO-APIC code is going wrong. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] driver core: Add the ability to unbind drivers to devices from userspace
On Mon, Jul 25, 2005 at 08:56:17PM -0400, Jon Smirl wrote: > On 7/25/05, Greg KH <[EMAIL PROTECTED]> wrote: > > On Mon, Jul 25, 2005 at 08:28:10PM -0400, Jon Smirl wrote: > > > I didn't realize that echo was adding the CR, I thought that it always > > > appeared on the end of a sysfs attribute set. So now I have to go add > > > white space stripping to a dozen fbdev/drm sysfs attribute > > > implementations. Given that the param is const I may have to allocate > > > new buffers and copy. I also wonder how many other people have made > > > the same mistake. > > > > Nah, just zero out that \n character :) > > The input buffer is "const char * buf". I will have to override the > const to zero it out. Yeah, hence the ":)" above. > > > Are you sure it would break other things? These are supposed to be > > > text attributes, not binary ones. > > > > I agree, I don't know what would break. Care to make a patch so we > > could find out? > > I'll put one together to trim leading/trailing white space from the > buffer before it is passed into the attribute functions. Now that I > think about this I believe the attributes should have always had the > leading/trailing white space removed. If we don't do it in the sysfs > code then every driver has to do it. Ok, sounds good. 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: "seeing minute plus hangs during boot" - 2.6.12 and 2.6.13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Haninger wrote: > On 7/22/05, Francisco Figueiredo Jr. <[EMAIL PROTECTED]> wrote: > >>Hangs appears just before mounting filesystems message and before configuring >>system to use udev. > > I don't know if this will help, but there were issues raised earlier > about older versions of udev causing hangs on newer kernels. Look for > the thread with the subject "2.6.12 udev hangs at boot". Actually, > look here: http://marc.theaimsgroup.com/?l=linux-kernel=111909806104523=2 > > Basically, upgrade to a newer udev if you're running an older one (I > think I had 0.30 at the time; installing 0.58 sped things up > noticeably). > Hi Andrew! Thanks! Indeed udev update solved my problem with "preparing system to use udev" hang. It now works like a charm. I had 030 version too. Only the "mounting filesystem" hangs persists :( May it have something about I have reiserfs 3.6 as my main filesystem? I think it may be some type of configuration or update too. Thank you very much. - -- Regards, Francisco Figueiredo Jr. Npgsql Lead Developer http://gborg.postgresql.org/project/npgsql MonoBrasil Project Founder Member http://monobrasil.softwarelivre.org - - "Science without religion is lame; religion without science is blind." ~ Albert Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQuWeDv7iFmsNzeXfAQJvCQf/Va27h0f9bD1l6c2pL8yaxL6McQABqhcw wy+Yh1pt1arltYfAuvvXkF9kHfYO9jkmDztm40r0nCI4EJ1Plr+mcSFm0MYOKEfP o1dCV3lsGHiLla7ObxO4DWjO7FqAanOj5VW2dWp8MBgatimDopPxrfdb3ciFyP/h HQBJ3rodotm8CnchqFS7sPERaxpG9Q32JyRrsUq4QNh+jcOLsIKjuq32qtQeO10B qpMqJ4S2fm5q+rdz5Z5iBIDgRZ0NHcXnwwQcYDkNRpNWN+K4Zk8/hXywd8uJ++lb stKOlKoafqWlDYRU3SylSdhY+gsnDfFpIV97o/+/1ekd1x4PlzkOUg== =2AMa -END PGP SIGNATURE- ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc3] i386: clean up user_mode macros
Miles Bader <[EMAIL PROTECTED]> wrote: > > Linus Torvalds <[EMAIL PROTECTED]> writes: > > Ask a hundred random C programmers what "!!x" means, versus what "x != 0" > > means, and time their replies. > > I've always thought of "!!" as the "canonicalize boolean" operator... Me too. Once you get used to it, it's just the "convert non-zero to 1" operator. But whatever. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM:Machine hangs on pulling out USB cd writer on laptop.
Alejandro Bonilla wrote: Puneet Vyas wrote: PS : I am not even sure if I am "allowed" to pull out the writer like this. Am I supposed to "stop" the device first or something? You are supoused to unmount the volume. Try it. umount /dev/cdrom ? Make sure that is it not in use, then unload it. New versions of gnome and so have the option to right click the loaded device and then to unmount. It should never hang. Does it hang with the floppy when removed? 1. When I did umount /dev/cdrom it says - "umount: /dev/hdc is not mounted (according to mtab)" 2. Yes Thanks, Puneet - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.13-rc3] i386: clean up user_mode macros
Linus Torvalds <[EMAIL PROTECTED]> writes: > Ask a hundred random C programmers what "!!x" means, versus what "x != 0" > means, and time their replies. I've always thought of "!!" as the "canonicalize boolean" operator... Vaguely ugly, but I think it's actually _more clear_ than != 0 in contexts where the value is already "boolean" in the C zero or not-zero sense, but you want a "proper" boolean (0 or 1) for some reason. -miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.13-rc3 test: finding compile errors with make randconfig
On Sun, 24 Jul 2005 23:27:22 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote: > >You should edit init/Kconfig to disallow CONFIG_CLEAN_COMPILE=n, since >any errors you see with CONFIG_BROKEN=y aren't interesting. Straight over the top of my head yesterday :) Is the following what you had in mind? (current script does retry if BROKEN) [EMAIL PROTECTED]:/opt/linux$ diff -u linux-2.6.13-rc3-git6/init/Kconfig~ linux-2.6.13-rc3-git6/init/Kconfig --- linux-2.6.13-rc3-git6/init/Kconfig~ 2005-07-25 08:23:04.0 +1000 +++ linux-2.6.13-rc3-git6/init/Kconfig 2005-07-26 10:25:59.0 +1000 @@ -42,7 +42,7 @@ config BROKEN bool - depends on !CLEAN_COMPILE + depends on !CLEAN_COMPILE && 0 default y config BROKEN_ON_SMP - - - results first run: -- Here http://scatter.mine.nu/test/scripts/counterror-2005-07-26.gz is post-processing script (work in progress) extracts errors and non-deprecated warnings, linked to first triggering .config like so: [EMAIL PROTECTED]:/opt/linux$ cat error-error-list trial1/run-004:arch/i386/mach-es7000/es7000.h trial1/run-004:arch/i386/mach-es7000/es7000plat.c trial1/run-009:drivers/char/ipmi/ipmi_msghandler.c trial2/run-082:drivers/mtd/maps/nettel.c trial3/run-018:drivers/pnp/pnpbios/rsparser.c trial2/run-044:include/asm-i386/mach-default/mach_apic.h trial1/run-008:include/asm-i386/mach-visws/do_timer.h trial2/run-081:ipc/shm.c trial1/run-015:net/rxrpc/main.c trial2/run-027:sound/core/memalloc.c then extracts compiler messages: [EMAIL PROTECTED]:/opt/linux$ head error-error-report |cut -c-78 trial1/run-004:arch/i386/mach-es7000/es7000.h:82: error: field `id' has incomp trial1/run-004:arch/i386/mach-es7000/es7000.h:88: error: field `Header' has in trial1/run-004:arch/i386/mach-es7000/es7000plat.c: In function `parse_unisys_o trial1/run-004:arch/i386/mach-es7000/es7000plat.c:154: error: `es7000_rename_g trial1/run-004:arch/i386/mach-es7000/es7000plat.c: In function `find_unisys_ac trial1/run-004:arch/i386/mach-es7000/es7000plat.c:168: warning: implicit decla trial1/run-004:arch/i386/mach-es7000/es7000plat.c:170: error: dereferencing po trial1/run-004:arch/i386/mach-es7000/es7000plat.c:172: error: dereferencing po trial1/run-004:arch/i386/mach-es7000/es7000plat.c:175: warning: implicit decla trial1/run-004:arch/i386/mach-es7000/es7000plat.c:175: error: invalid applicat ^^\ --> link to .config producing the error / warning: [EMAIL PROTECTED]:/opt/linux$ head trial1/run-004-config # # Automatically generated make config: don't edit # Linux kernel version: 2.6.13-rc3 # Tue Jul 19 04:31:27 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y Current compile run is with linux-2.6.13-rc3-git6 Datastore is denormalised flat text. Query language: grep :) Thanks, Grant. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM:Machine hangs on pulling out USB cd writer on laptop.
Alejandro Bonilla wrote:
Also, go to a tty (ctrl+alt+f1), login and then unplug the device, If
it gives a kernel panic, show the output here.
.Alejandro
Thanks for looking into this.
I tried the tty and got the following messages in continuous loop (they
were scrolling past real fast but since there were only two messages
they kind of overlapped so I could write them down)
ide : failed opcode was : unknown
hdc : status error: status 0x00 { }
Is there anything else that I can provide?
~Puneet
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 - 0/12] NTP cleanup work (v. B4)
On Thu, 2005-07-21 at 12:39 +0200, Roman Zippel wrote: > Hi, > > On Wed, 20 Jul 2005, john stultz wrote: > > > I really don't think the NTP changes I've mailed is very complex. > > Please, be specific and point to something you think is an issue and > > I'll do my best to fix it. > > Maybe I should explain, in what direction I would take it. > Let's first only take tick based updates, one property I don't want to see > go away (and which you remove in the last patch), is to basically update > xtime at every tick by (tick_nsec+time_adj) (and maybe fold time_adjust > into time_adj), no multiply/divide just adds/shifts. Every second (or > maybe even less frequently) we update time_adj, where we even might > integrate a better to way to add previous errors due to SHIFT_HZ. Hmm. Ok, would something like ntp_static_interval_adjustment() or whatnot be a decent interface to provide a fixed single tick adjustment as precalculated by the NTP state machine? Similar to what I have in patch 10, but via a separate interface? > To add support for continous time sources, the generic ntp code would just > provide [tick,frequency,offset] values and the time source converts it > into its internal values. A tick based source calculates [tick_nsec, > time_adj] and a continous source calculates the [offset,multiplier]. These > values should be recalculated as infrequently as possible and not every > single tick as you do with ppc_adjtimex. This also means a continous > source updates xtime basically by calling gettimeofday (what ppc64 already > almost does) and doesn't use update_wall_time() at all. Yep, that sounds doable. Although yes, the ppc_adjtimex is more overhead, I went with the worse implementation to scratch out my idea adn see if the ppc folks might scream and suggest the proper way. > Maybe I'm missing something, but I don't see a reason to forcibly merge > both ways to update the clock, keep them seperate and let the generic ntp > code provide the basic parameters which the time source uses to update the > clock. The important thing is to precalculate as much as possible, so that > the runtime overhead is as low as possible and these precalculations > differ between time sources, so what your patches basically do is to > remove all of these precalculations and I can't convince myself to see > this as a good thing. I don't know if that's the case. I am precalculating things, but maybe we're misunderstanding each other. Regardless, yes, for the tick based systems that can't go continuous I can preserve the existing behavior (if not possibly improve it some). > BTW do you have any user space test code for this? This might be useful to > verify that the changes are really correct and a prototype might be a good > way to demonstrate the kernel changes. I do not right now, after seeing Rusty's talk at OLS this sounds like quite a nice idea. I was thinking of a simple simulator that has two files: the first a list of hardware time values and and the second a list of operations (gettimeofday, timer_interrupt, adjtimex). We can then generate time sequences and action sequences and run them through the simulator of both the current and old implementations. Not that this is completely trivial to do, but it did seem like a good idea. I'll see what I can do. thanks -john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Rename __lock_page to lock_page_slow
On Sun, Jul 24, 2005 at 11:36:34PM +0100, Christoph Hellwig wrote: > On Sun, Jul 24, 2005 at 11:17:02PM +0100, Christoph Hellwig wrote: > > On Mon, Jun 20, 2005 at 09:54:04PM +0530, Suparna Bhattacharya wrote: > > > In order to allow for interruptible and asynchronous versions of > > > lock_page in conjunction with the wait_on_bit changes, we need to > > > define low-level lock page routines which take an additional > > > argument, i.e a wait queue entry and may return non-zero status, > > > e.g -EINTR, -EIOCBRETRY, -EWOULDBLOCK etc. This patch renames > > > __lock_page to lock_page_slow, so that __lock_page and > > > __lock_page_slow can denote the versions which take a wait queue > > > parameter. > > > > How many users that don't use a waitqueue parameter will be left > > once all AIO patches go in? Since these patches are intended only for aio reads and (O_SYNC) writes, that still leaves most other users of regular lock_page() as they are. > > Actually looking at the later patches we always seem to pass > current->io_wait anyway, so is there a real point for having the > argument? > Having the parameter enables issual of synchronous lock_page() within an AIO path, overriding current->io_wait, (for example, consider the case of a page fault during AIO !), and thus avoids the need to convert and audit more paths to handle -EIOCBRETRY propagation (though it is possible to do so as and when the need arises). This is why I decided to keep this parameter explicit at the low level, and let the caller decide how to invoke it and handle the return value propagation. Does that make sense ? BTW, there is also a potential secondary benefit of a low level primitive for asynchronous page IO operations etc directly usable by kernel threads, without having to use the whole gamut of AIO interfaces. Thanks for reviewing the code ! Regards Suparna -- Suparna Bhattacharya ([EMAIL PROTECTED]) Linux Technology Center IBM Software Lab, India - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: Add the ability to unbind drivers to devices from userspace
On 7/25/05, Greg KH <[EMAIL PROTECTED]> wrote: > On Mon, Jul 25, 2005 at 08:28:10PM -0400, Jon Smirl wrote: > > I didn't realize that echo was adding the CR, I thought that it always > > appeared on the end of a sysfs attribute set. So now I have to go add > > white space stripping to a dozen fbdev/drm sysfs attribute > > implementations. Given that the param is const I may have to allocate > > new buffers and copy. I also wonder how many other people have made > > the same mistake. > > Nah, just zero out that \n character :) The input buffer is "const char * buf". I will have to override the const to zero it out. > > > Are you sure it would break other things? These are supposed to be > > text attributes, not binary ones. > > I agree, I don't know what would break. Care to make a patch so we > could find out? I'll put one together to trim leading/trailing white space from the buffer before it is passed into the attribute functions. Now that I think about this I believe the attributes should have always had the leading/trailing white space removed. If we don't do it in the sysfs code then every driver has to do it. -- Jon Smirl [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: PROBLEM:Machine hangs on pulling out USB cd writer on laptop.
Alejandro Bonilla wrote: Puneet Vyas wrote: Hi, My Dell 600m has a CD writer attached as a USB device. I need to use the same slot to connect my floppy drive. After pulling out the CD writer , the machine completely hangs and only hard boot works. I am new to reporting bugs so I attached all info as according to REPORTING-BUGS. Please let me know if more info is needed.Thanks. Warm regards, Puneet Vyas PS : I am not even sure if I am "allowed" to pull out the writer like this. Am I supposed to "stop" the device first or something? You are supoused to unmount the volume. Try it. umount /dev/cdrom ? Make sure that is it not in use, then unload it. New versions of gnome and so have the option to right click the loaded device and then to unmount. It should never hang. Does it hang with the floppy when removed? .Alejandro - Also, go to a tty (ctrl+alt+f1), login and then unplug the device, If it gives a kernel panic, show the output here. .Alejandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM:Machine hangs on pulling out USB cd writer on laptop.
Puneet Vyas wrote: Hi, My Dell 600m has a CD writer attached as a USB device. I need to use the same slot to connect my floppy drive. After pulling out the CD writer , the machine completely hangs and only hard boot works. I am new to reporting bugs so I attached all info as according to REPORTING-BUGS. Please let me know if more info is needed.Thanks. Warm regards, Puneet Vyas PS : I am not even sure if I am "allowed" to pull out the writer like this. Am I supposed to "stop" the device first or something? You are supoused to unmount the volume. Try it. umount /dev/cdrom ? Make sure that is it not in use, then unload it. New versions of gnome and so have the option to right click the loaded device and then to unmount. It should never hang. Does it hang with the floppy when removed? .Alejandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel cached memory
On Mon, 25 Jul 2005 at 12:47:50 -0400, Bill Davidsen wrote: > > It's a very - very - very old and bad logic (at least nowdays) from the > > stone age to free up memory. > > It's very Microsoft to claim that the OS always knows best, and not let > the user tune the system the way they want it tuned. Ironically, Microsoft offers a choice here. In the registry (NT and W2K at least, don't know about XP:) HKLM\SYSTEM\CurrentControlSet\Session Manager\Memory Management LargeSystemCache : REG_DWORD 0: prefer application code over cached data 1: prefer cached data Also: DisablePagingExecutive : REG_DWORD 1: don't allow kernel code to be paged out IOPageLockLimit : REG_DWORD controls the amount of memory that can be locked for I/O __ Chuck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] driver core: Add the ability to unbind drivers to devices from userspace
On Mon, Jul 25, 2005 at 08:28:10PM -0400, Jon Smirl wrote: > On 7/25/05, Greg KH <[EMAIL PROTECTED]> wrote: > > On Mon, Jul 25, 2005 at 12:30:43PM -0400, Jon Smirl wrote: > > > On 7/25/05, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > > > On 7/25/05, Jon Smirl <[EMAIL PROTECTED]> wrote: > > > > > On 7/25/05, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > > > > > On Sunday 24 July 2005 23:09, Jon Smirl wrote: > > > > > > > I just pulled from GIT to test bind/unbind. I couldn't get it to > > > > > > > work; > > > > > > > it isn't taking into account the CR on the end of the input value > > > > > > > of > > > > > > > the sysfs attribute. This patch will fix it but I'm sure there > > > > > > > is a > > > > > > > cleaner solution. > > > > > > > > > > > > > > > > > > > "echo -n" should take care of this problem I think. > > > > > > > > > > That will work around it but I think we should fix it. Changing to > > > > > strncmp() fixes most cases. > > > > > > > > > > - if (strcmp(name, dev->bus_id) == 0) > > > > > + if (strncmp(name, dev->bus_id, strlen(dev->bus_id)) == 0) > > > > > > > > > > > > > This will produce "interesting results" if you have both "blah-1" and > > > > "blah-10" devices on the bus. > > > > Yes, not a good thing for USB devices specifically. > > > > > Then the better solution is to fix the generic attribute set code to > > > strip leading and trailing white space. > > > > No, that might break other things as we have not been doing this from > > day one. I'd rather just change these two places, if it's that big of a > > deal. It was documented (in a lwn.net article) and the changelog entry, > > that you should use "echo -n". > > I didn't realize that echo was adding the CR, I thought that it always > appeared on the end of a sysfs attribute set. So now I have to go add > white space stripping to a dozen fbdev/drm sysfs attribute > implementations. Given that the param is const I may have to allocate > new buffers and copy. I also wonder how many other people have made > the same mistake. Nah, just zero out that \n character :) > Are you sure it would break other things? These are supposed to be > text attributes, not binary ones. I agree, I don't know what would break. Care to make a patch so we could find out? 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: Netlink connector
* Patrick McHardy <[EMAIL PROTECTED]> 2005-07-26 02:16 > Thomas Graf wrote: > >* Patrick McHardy <[EMAIL PROTECTED]> 2005-07-26 01:46 > > > >>You still have to take care of mixed 64/32 bit environments, u64 fields > >>for example are differently alligned. > > > >My solution to this (in the same patchset) is that we never > >derference u64s but instead copy them. > > I don't understand. The problem is mainly u64 embedded in structures, > the structs have different sizes if the u64 is not 8 byte aligned > and the structure size padded to a multiple of 8. Like in gnet_stats, yes. I thought you meant usages like *(u64 *) which we shouldn't do either. > I started working on it after the OLS party, so no postable code yet :) > The idea for more groups is basically to remove the fixed groups > bitmask from struct sockaddr_nl and use setsockopt to add/remove > multicast subscriptions. If we add the limitation that a packet > can only be multicasted to a single group we can support an arbitary > number of groups, otherwise we would still be limited by size of > skb->cb. I was thinking of subscription messages over netlink itself for the advantage that we could use it within the distributed netlink protocol that has to come up sometime soon. Well, both ways are ok I guess, the ease of distributive usage is my only argument. > This limitation shouldn't be a problem, AFAIK nothing is > multicasting to multiple groups at once right now and the increased > number of groups will allow a better granularity anyway. I'm not aware of any and I agree. We don't need n<->n subscriptions, 1<->n is perfectly fine as I see it. > The main > problem is keeping it backwards-compatible for current netlink users. > If this isn't possible we may need to call it netlink2. I think Jamal has a moral patent on the name netlink2 so be careful ;-> It should be possible to remain compatible, I don't see any unresolveable issues right now. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: Add the ability to unbind drivers to devices from userspace
On 7/25/05, Greg KH <[EMAIL PROTECTED]> wrote: > On Mon, Jul 25, 2005 at 12:30:43PM -0400, Jon Smirl wrote: > > On 7/25/05, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > > On 7/25/05, Jon Smirl <[EMAIL PROTECTED]> wrote: > > > > On 7/25/05, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > > > > On Sunday 24 July 2005 23:09, Jon Smirl wrote: > > > > > > I just pulled from GIT to test bind/unbind. I couldn't get it to > > > > > > work; > > > > > > it isn't taking into account the CR on the end of the input value of > > > > > > the sysfs attribute. This patch will fix it but I'm sure there is a > > > > > > cleaner solution. > > > > > > > > > > > > > > > > "echo -n" should take care of this problem I think. > > > > > > > > That will work around it but I think we should fix it. Changing to > > > > strncmp() fixes most cases. > > > > > > > > - if (strcmp(name, dev->bus_id) == 0) > > > > + if (strncmp(name, dev->bus_id, strlen(dev->bus_id)) == 0) > > > > > > > > > > This will produce "interesting results" if you have both "blah-1" and > > > "blah-10" devices on the bus. > > Yes, not a good thing for USB devices specifically. > > > Then the better solution is to fix the generic attribute set code to > > strip leading and trailing white space. > > No, that might break other things as we have not been doing this from > day one. I'd rather just change these two places, if it's that big of a > deal. It was documented (in a lwn.net article) and the changelog entry, > that you should use "echo -n". I didn't realize that echo was adding the CR, I thought that it always appeared on the end of a sysfs attribute set. So now I have to go add white space stripping to a dozen fbdev/drm sysfs attribute implementations. Given that the param is const I may have to allocate new buffers and copy. I also wonder how many other people have made the same mistake. Are you sure it would break other things? These are supposed to be text attributes, not binary ones. -- Jon Smirl [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/
[patch] make kmalloc() fail for swapped size / GFP flags
The patch below makes kmalloc() fail for swapped flags and size arguments
as mention in Dave Jones keynote at OLS. This is done by adding a new flag,
__GFP_VALID, which is checked for in kmalloc(), that results in the size
being too large. Please apply.
-ben
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -40,6 +40,7 @@ struct vm_area_struct;
#define __GFP_ZERO 0x8000u /* Return zeroed page on success */
#define __GFP_NOMEMALLOC 0x1u /* Don't use emergency reserves */
#define __GFP_NORECLAIM 0x2u /* No realy zone reclaim during allocation */
+#define __GFP_VALID0x8000u /* valid GFP flags */
#define __GFP_BITS_SHIFT 20/* Room for 20 __GFP_FOO bits */
#define __GFP_BITS_MASK ((1 << __GFP_BITS_SHIFT) - 1)
@@ -50,12 +51,12 @@ struct vm_area_struct;
__GFP_NOFAIL|__GFP_NORETRY|__GFP_NO_GROW|__GFP_COMP| \
__GFP_NOMEMALLOC|__GFP_NORECLAIM)
-#define GFP_ATOMIC (__GFP_HIGH)
-#define GFP_NOIO (__GFP_WAIT)
-#define GFP_NOFS (__GFP_WAIT | __GFP_IO)
-#define GFP_KERNEL (__GFP_WAIT | __GFP_IO | __GFP_FS)
-#define GFP_USER (__GFP_WAIT | __GFP_IO | __GFP_FS)
-#define GFP_HIGHUSER (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HIGHMEM)
+#define GFP_ATOMIC (__GFP_VALID | __GFP_HIGH)
+#define GFP_NOIO (__GFP_VALID | __GFP_WAIT)
+#define GFP_NOFS (__GFP_VALID | __GFP_WAIT | __GFP_IO)
+#define GFP_KERNEL (__GFP_VALID | __GFP_WAIT | __GFP_IO | __GFP_FS)
+#define GFP_USER (__GFP_VALID | __GFP_WAIT | __GFP_IO | __GFP_FS)
+#define GFP_HIGHUSER (__GFP_VALID | __GFP_WAIT | __GFP_IO | __GFP_FS |
__GFP_HIGHMEM)
/* Flag - indicates that the buffer will be suitable for DMA. Ignored on some
platforms, used as appropriate on others */
diff --git a/include/linux/slab.h b/include/linux/slab.h
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -78,6 +78,10 @@ extern void *__kmalloc(size_t, unsigned
static inline void *kmalloc(size_t size, unsigned int __nocast flags)
{
+ if (__builtin_constant_p(flags) && !(flags & __GFP_VALID)) {
+ extern void __your_kmalloc_flags_are_not_valid(void);
+ __your_kmalloc_flags_are_not_valid();
+ }
if (__builtin_constant_p(size)) {
int i = 0;
#define CACHE(x) \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.13-rc3] i386: clean up user_mode macros
On Mon, 2005-07-25 at 16:13 -0700, Linus Torvalds wrote: > I _really_ prefer > > x != 0 > > over > > !!x Good to hear. This means that you should have no problem accepting my previous patch for signal.c that changed the x ^ y to x != y. And I would also assume that you prefer x *= 2 over x <<= 1 (also since the first person to show this example used x <<= 2. Right Lee? :-) -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Netlink connector
Thomas Graf wrote: * Patrick McHardy <[EMAIL PROTECTED]> 2005-07-26 01:46 You still have to take care of mixed 64/32 bit environments, u64 fields for example are differently alligned. My solution to this (in the same patchset) is that we never derference u64s but instead copy them. I don't understand. The problem is mainly u64 embedded in structures, the structs have different sizes if the u64 is not 8 byte aligned and the structure size padded to a multiple of 8. Then fix it so we can use more families and groups. I started some work on this, but I'm not sure if I have time to complete it. Great, this is one of the remaining issues I haven't solved yet. If you want me to take over just hand over your unfinished work and I'll integrate it into my patchset. I started working on it after the OLS party, so no postable code yet :) The idea for more groups is basically to remove the fixed groups bitmask from struct sockaddr_nl and use setsockopt to add/remove multicast subscriptions. If we add the limitation that a packet can only be multicasted to a single group we can support an arbitary number of groups, otherwise we would still be limited by size of skb->cb. This limitation shouldn't be a problem, AFAIK nothing is multicasting to multiple groups at once right now and the increased number of groups will allow a better granularity anyway. The main problem is keeping it backwards-compatible for current netlink users. If this isn't possible we may need to call it netlink2. Regards Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Incorrect driver getting loaded for Qlogic FC-HBA
On Mon, Jul 25, 2005 at 11:02:39AM +0900, Rajat Jain wrote: > I'm using Kernel 2.6.9 and am having a Qlogic QLE2362 FC-HBA in my > system. I selected all the Qlogic SCSI drivers while buiding the > kernel. Now the problem is that every time I reboot, I have to > MANUALLY modprobe the qla2322.ko module in the kernel and only then my > HBA works. By default, the kernel loads qla2300.ko, which is not the > correct driver for the card, and hence the HBA does not work. Here is > the lspci output: "by default" the kernel does not load any modules. That's up to the hotplug system, or some other package. 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] driver core: Add the ability to unbind drivers to devices from userspace
On Mon, Jul 25, 2005 at 12:30:43PM -0400, Jon Smirl wrote: > On 7/25/05, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > On 7/25/05, Jon Smirl <[EMAIL PROTECTED]> wrote: > > > On 7/25/05, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > > > On Sunday 24 July 2005 23:09, Jon Smirl wrote: > > > > > I just pulled from GIT to test bind/unbind. I couldn't get it to work; > > > > > it isn't taking into account the CR on the end of the input value of > > > > > the sysfs attribute. This patch will fix it but I'm sure there is a > > > > > cleaner solution. > > > > > > > > > > > > > "echo -n" should take care of this problem I think. > > > > > > That will work around it but I think we should fix it. Changing to > > > strncmp() fixes most cases. > > > > > > - if (strcmp(name, dev->bus_id) == 0) > > > + if (strncmp(name, dev->bus_id, strlen(dev->bus_id)) == 0) > > > > > > > This will produce "interesting results" if you have both "blah-1" and > > "blah-10" devices on the bus. Yes, not a good thing for USB devices specifically. > Then the better solution is to fix the generic attribute set code to > strip leading and trailing white space. No, that might break other things as we have not been doing this from day one. I'd rather just change these two places, if it's that big of a deal. It was documented (in a lwn.net article) and the changelog entry, that you should use "echo -n". 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] kill bio->bi_set
Jens Axboe <[EMAIL PROTECTED]> writes:
> On Sat, Jul 23 2005, Peter Osterlund wrote:
> > Jens Axboe <[EMAIL PROTECTED]> writes:
> >
> > > Dunno why I didn't notice before, but ->bi_set is totally unnecessary
> > > bloat of struct bio. Just define a proper destructor for the bio and it
> > > already knows what bio_set it belongs too.
> >
> > This causes crashes on my computer.
>
> Did I neglect to mention it was untested? :)
...
> Thanks, I'll go over these and submit a fixed version.
I fixed this myself. The patch below is tested with dm-crypt on top of
pktcdvd on top of usb-storage, and worked fine in my tests.
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
---
drivers/md/dm-io.c |6 ++
drivers/md/dm.c |6 ++
fs/bio.c| 32 +---
include/linux/bio.h |2 +-
4 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/md/dm-io.c b/drivers/md/dm-io.c
--- a/drivers/md/dm-io.c
+++ b/drivers/md/dm-io.c
@@ -239,6 +239,11 @@ static void vm_dp_init(struct dpages *dp
dp->context_ptr = data;
}
+static void dm_bio_destructor(struct bio *bio)
+{
+ bio_free(bio, _bios);
+}
+
/*-
* IO routines that accept a list of pages.
*---*/
@@ -263,6 +268,7 @@ static void do_region(int rw, unsigned i
bio->bi_bdev = where->bdev;
bio->bi_end_io = endio;
bio->bi_private = io;
+ bio->bi_destructor = dm_bio_destructor;
bio_set_region(bio, region);
/*
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -399,6 +399,11 @@ struct clone_info {
unsigned short idx;
};
+static void dm_bio_destructor(struct bio *bio)
+{
+ bio_free(bio, dm_set);
+}
+
/*
* Creates a little bio that is just does part of a bvec.
*/
@@ -410,6 +415,7 @@ static struct bio *split_bvec(struct bio
struct bio_vec *bv = bio->bi_io_vec + idx;
clone = bio_alloc_bioset(GFP_NOIO, 1, dm_set);
+ clone->bi_destructor = dm_bio_destructor;
*clone->bi_io_vec = *bv;
clone->bi_sector = sector;
diff --git a/fs/bio.c b/fs/bio.c
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -104,18 +104,22 @@ static inline struct bio_vec *bvec_alloc
return bvl;
}
-/*
- * default destructor for a bio allocated with bio_alloc_bioset()
- */
-static void bio_destructor(struct bio *bio)
+void bio_free(struct bio *bio, struct bio_set *bio_set)
{
const int pool_idx = BIO_POOL_IDX(bio);
- struct bio_set *bs = bio->bi_set;
BIO_BUG_ON(pool_idx >= BIOVEC_NR_POOLS);
- mempool_free(bio->bi_io_vec, bs->bvec_pools[pool_idx]);
- mempool_free(bio, bs->bio_pool);
+ mempool_free(bio->bi_io_vec, bio_set->bvec_pools[pool_idx]);
+ mempool_free(bio, bio_set->bio_pool);
+}
+
+/*
+ * default destructor for a bio allocated with bio_alloc_bioset()
+ */
+static void bio_fs_destructor(struct bio *bio)
+{
+ bio_free(bio, fs_bio_set);
}
inline void bio_init(struct bio *bio)
@@ -171,8 +175,6 @@ struct bio *bio_alloc_bioset(unsigned in
bio->bi_max_vecs = bvec_slabs[idx].nr_vecs;
}
bio->bi_io_vec = bvl;
- bio->bi_destructor = bio_destructor;
- bio->bi_set = bs;
}
out:
return bio;
@@ -180,7 +182,12 @@ out:
struct bio *bio_alloc(unsigned int __nocast gfp_mask, int nr_iovecs)
{
- return bio_alloc_bioset(gfp_mask, nr_iovecs, fs_bio_set);
+ struct bio *bio = bio_alloc_bioset(gfp_mask, nr_iovecs, fs_bio_set);
+
+ if (bio)
+ bio->bi_destructor = bio_fs_destructor;
+
+ return bio;
}
void zero_fill_bio(struct bio *bio)
@@ -276,8 +283,10 @@ struct bio *bio_clone(struct bio *bio, u
{
struct bio *b = bio_alloc_bioset(gfp_mask, bio->bi_max_vecs,
fs_bio_set);
- if (b)
+ if (b) {
+ b->bi_destructor = bio_fs_destructor;
__bio_clone(b, bio);
+ }
return b;
}
@@ -1078,6 +1087,7 @@ subsys_initcall(init_bio);
EXPORT_SYMBOL(bio_alloc);
EXPORT_SYMBOL(bio_put);
+EXPORT_SYMBOL(bio_free);
EXPORT_SYMBOL(bio_endio);
EXPORT_SYMBOL(bio_init);
EXPORT_SYMBOL(__bio_clone);
diff --git a/include/linux/bio.h b/include/linux/bio.h
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -111,7 +111,6 @@ struct bio {
void*bi_private;
bio_destructor_t*bi_destructor; /* destructor */
- struct bio_set *bi_set;/* memory pools set */
};
/*
@@ -280,6 +279,7 @@ extern void bioset_free(struct bio_set *
extern struct bio *bio_alloc(unsigned int __nocast, int);
extern struct bio *bio_alloc_bioset(unsigned int __nocast, int, struct bio_set
*);
extern void
Re: Netlink connector
* Patrick McHardy <[EMAIL PROTECTED]> 2005-07-26 01:46 > Netlink users don't have to care about shared or cloned skbs. I don't > think its a big issue to use alloc_skb and then the usual netlink > macros. Thomas added a number of macros that simplfiy use a lot. Once I've finished the generic netlink attribute macros the usage will be even simpler. I wrote down all the things I want to do today in a park and I intend to write the code once I'm back from my vacation. > But my main objection is that it sends everything to userspace even > if noone is listening. This can't be used for things that generate > lots of events, and also will get problematic is the number of users > increases. My patches will include a new function netlink_nr_subscribers() taking the socket and a mask of groups. I posted something simliar during an earlier connector discussion already. > You still have to take care of mixed 64/32 bit environments, u64 fields > for example are differently alligned. My solution to this (in the same patchset) is that we never derference u64s but instead copy them. > Then fix it so we can use more families and groups. I started some work > on this, but I'm not sure if I have time to complete it. Great, this is one of the remaining issues I haven't solved yet. If you want me to take over just hand over your unfinished work and I'll integrate it into my patchset. I'm sorry to not being able to provide any code yet, it's one of the first things I'll do once I'm back. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: relayfs documentation sucks?
Christoph Hellwig wrote: > That beein said I wish LTT folks would make a little more progress so > we could actually include it. We're working on it. On the topic of revamping LTT, 3 different people came up with 3 different implementations. Following your feedback on the patch I sent a few weeks back, I headed out asking myself "what is the bare-minimum tracing functionality that will actually fly while still being flexible enough to add to it?" I spent some time at the OLS comparing notes with others interested in this area, and I think we've got something that should fit the bill. We should be able to post something sooner rather than later. Now if only I could remember what I talked about after I left the Black Thorn at 2h45am and the guy in the elevator at Les Suites pressed on a button and said "'M' for more beer" ... Thanks, Karim -- Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Netlink connector
Evgeniy Polyakov wrote: On Mon, Jul 25, 2005 at 04:32:32PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: If I understand correctly it tries to workaround some netlink limitations (limited number of netlink families and multicast groups) by sending everything to userspace and demultiplexing it there. Same in the other direction, an additional layer on top of netlink does basically the same thing netlink already does. This looks like a step in the wrong direction to me, netlink should instead be fixed to support what is needed. Not only it. The main _first_ idea was to simplify userspace mesasge handling as much as possible. In first releases I called it ioctl-ng - any module that want ot communicate with userspace in the way ioctl does, Usually netlink is easily extendable by using nested TLVs. By hiding this you basically remove this extensibility. requires skb allocation/freeing/handling. Does RTC driver writer need to know what is the difference between shared and cloned skb? Should kernel user of such message bus have to know about skb at all? Netlink users don't have to care about shared or cloned skbs. I don't think its a big issue to use alloc_skb and then the usual netlink macros. Thomas added a number of macros that simplfiy use a lot. But my main objection is that it sends everything to userspace even if noone is listening. This can't be used for things that generate lots of events, and also will get problematic is the number of users increases. With char device I only need to register my callback - with kernel connector it is the same, but allows to use the whole power of netlink, especially without nice ioctl features like different pointer size in userspace and kernelspace. You still have to take care of mixed 64/32 bit environments, u64 fields for example are differently alligned. And number of free netlink sockets is _very_ small, especially if allocate new one for simple notifications, which can be easily done using connector. Then fix it so we can use more families and groups. I started some work on this, but I'm not sure if I have time to complete it. And netlink can be extended to support it - netlink is a transport protocol, it should not care about higher layer message handling, connector instead will deliver message to the end user in a very convenient form. You can still built this stuff on top, but the workarounds for netlink limitations need to be fixed in netlink. P.S. I've removed [EMAIL PROTECTED] - please do not add subscribers-only private mail lists. Wasn't 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: BUG: Yamaha OPL3SA2 does not work with ALSA on 2.6 kernels.
On Mon, Jul 25, 2005 at 10:31:37AM -0400, Andrew Haninger wrote: > Hello. Hi Andrew, > I have a 5 year old Gateway Solo 2500 that is currently running Linux > 2.6.12.2. If I install ALSA and try to have alsaconf bruteforce-detect > the OPL3SA2 sound card, it will say that it has detected it, but > loading the modules will fail. If I install Linux 2.4 and > recompile/rerun alsaconf, the detection works fine and the card works. > Copying the configuration detected under 2.4 into a modprobe.conf on > 2.6 allows me to use the card in 2.6 with occasional crashes (which > might be due to suspend2). the ALSA people might be able to help you (Cc'ed). > Searching around the net, I find many other people having trouble with > these cards and the ALSA-Linux2.6 combination. On one page, someone > suggested that there were changes made between 2.4 and 2.6 to the ISA > code that broke ALSA's detection routines. > > I'm not sure what information might be needed in order to get this > card working well once and for all, but if someone will let me know, > I'd be happy to provide. Does the OSS driver work in 2.6? > Thanks. > > -Andy 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: topology api confusion
Matthew Dobson wrote: > Nathan Lynch wrote: > > We need some clarity on how asm-generic/topology.h is intended to be > > used. I suspect that it's supposed to be unconditionally included at > > the end of the architecture's topology.h so that any elements which > > are undefined by the arch have sensible default definitions. Looking > > at 2.6.13-rc3, this is what ppc64, ia64, and x86_64 currently do, > > however i386 does not (i386 pulls in the generic version only when > > !CONFIG_NUMA). > > > > The #ifndef guards around each element of the topology api > > cannot serve their apparent intended purpose when the architecture > > implements a given bit as a function instead of a macro > > (e.g. cpu_to_node in ppc64): > > When I originally wrote this all up, I had planned it to be used the way > i386 does: offer a full implementation of topology if appropriate, else > include the generic "sane" default. It has since changed to work more like > you described: implement some (or all) of the topology functions, then > include the generic one to define any you missed. OK. > You are correct in noticing that things should (though apparently don't?) > go wonky when arches define their topology functions as *functions*, rather > than macros. It hasn't really seemed to bite anyone yet, so I've left it > alone, though to be honest, it is as surprising to me that it works as it > is to you. I've resisted creating #ifdef ARCH_HAVE_XXX all over the place, > though maybe it is finally time? Things _do_ go wonky, but likely only on ppc64 -- all cpus show up in all nodes' cpumaps in sysfs. The other architectures which provide overrides and unconditionally include the generic topology.h define only macros iirc. If i386 were to include the generic topology.h it would have similar issues since it uses functions for some things too. > > Thought I'd ask for input first since this would involve a sweep of > > include/asm-*. > > It would indeed... I'd be more than happy to look at any patches you care > to generate. As I said, it seems to work, though I'm certain it's all held > together by GCC black magic & voodoo, and probably a little duct-tape. A > more obviously correct solution would not be a bad thing. :) I've got the changes ready, just need to test them a little more. Thanks. Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
, [EMAIL PROTECTED], Janak Desai <[EMAIL PROTECTED]>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/7] shared subtree Hi Andrew/Al Viro, Enclosing a final set of well tested patches that implement Al Viro's shared subtree proposal. These patches provide the ability to mark a mount tree as shared/private/slave/unclone, along with the ability to play with these trees with operations like bind/rbind/move/pivot_root/namespace-clone etc. I believe this powerful feature can help build features like per-user namespace. Couple of projects may benefit from shared subtrees. 1) automounter for the ability to automount across namespaces. 2) SeLinux for implementing polyinstantiated trees. 3) MVFS for providing versioning file system. 4) FUSE for per-user namespaces? Thanks to Avantika for developing about 100+ test cases that tests various combintation of private/shared/slave/unclonable trees. All these tests have passed. I feel pretty confident about the stability of the code. The patches have been broken into 7 units, for ease of review. I realize that patch-3 'rbind.patch' is a bit heavier than all the other patches. The reason being, most of the shared-subtree functionality gets manifestated during bind/rbind operation. Couple of work items to be done are: 1. modify the mount command to support this feature eg: mount --make-shared /tmp 2. a tool that can help visualize the propogation tree, maybe support in /proc? 3. some documentation on how to use all this functionality. Please consider the patches for inclusion in your tree. The footprint of this code is pretty small in the normal code path where shared-subtree functionality is not used. Any suggestions/comments to improve the code is welcome. Thanks, RP - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
, [EMAIL PROTECTED], Janak Desai <[EMAIL PROTECTED]>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 2/7] shared subtree
Content-Type: text/x-patch; name=unclone.patch
Content-Disposition: inline; filename=unclone.patch
Adds the ability to unclone a vfs tree. A uncloned vfs tree will not be
clonnable, and hence cannot be bind/rbind to any other mountpoint.
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 15 ++-
include/linux/fs.h|1 +
include/linux/mount.h | 15 +++
3 files changed, 30 insertions(+), 1 deletion(-)
Index: 2.6.12.work2/fs/namespace.c
===
--- 2.6.12.work2.orig/fs/namespace.c
+++ 2.6.12.work2/fs/namespace.c
@@ -673,6 +673,14 @@ static int do_make_private(struct vfsmou
return 0;
}
+static int do_make_unclone(struct vfsmount *mnt)
+{
+ if(mnt->mnt_pnode)
+ pnode_disassociate_mnt(mnt);
+ set_mnt_unclone(mnt);
+ return 0;
+}
+
/*
* recursively change the type of the mountpoint.
*/
@@ -682,6 +690,7 @@ static int do_change_type(struct nameida
int err=0;
if (!(flag & MS_SHARED) && !(flag & MS_PRIVATE)
+ && !(flag & MS_UNCLONE)
&& !(flag & MS_SLAVE))
return -EINVAL;
@@ -700,6 +709,9 @@ static int do_change_type(struct nameida
case MS_PRIVATE:
err = do_make_private(m);
break;
+ case MS_UNCLONE:
+ err = do_make_unclone(m);
+ break;
}
}
spin_unlock(_lock);
@@ -1140,7 +1152,8 @@ long do_mount(char * dev_name, char * di
data_page);
else if (flags & MS_BIND)
retval = do_loopback(, dev_name, flags & MS_REC);
- else if (flags & MS_SHARED || flags & MS_PRIVATE || flags & MS_SLAVE)
+ else if (flags & MS_SHARED || flags & MS_UNCLONE ||
+ flags & MS_PRIVATE || flags & MS_SLAVE)
retval = do_change_type(, flags);
else if (flags & MS_MOVE)
retval = do_move_mount(, dev_name);
Index: 2.6.12.work2/include/linux/fs.h
===
--- 2.6.12.work2.orig/include/linux/fs.h
+++ 2.6.12.work2/include/linux/fs.h
@@ -102,6 +102,7 @@ extern int dir_notify_enable;
#define MS_MOVE8192
#define MS_REC 16384
#define MS_VERBOSE 32768
+#define MS_UNCLONE (1<<17) /* recursively change to unclonnable */
#define MS_PRIVATE (1<<18) /* recursively change to private */
#define MS_SLAVE (1<<19) /* recursively change to slave */
#define MS_SHARED (1<<20) /* recursively change to shared */
Index: 2.6.12.work2/include/linux/mount.h
===
--- 2.6.12.work2.orig/include/linux/mount.h
+++ 2.6.12.work2/include/linux/mount.h
@@ -22,15 +22,18 @@
#define MNT_PRIVATE0x10 /* if the vfsmount is private, by default it is
private*/
#define MNT_SLAVE 0x20 /* if the vfsmount is a slave mount of its pnode
*/
#define MNT_SHARED 0x40 /* if the vfsmount is a slave mount of its pnode
*/
+#define MNT_UNCLONE0x80 /* if the vfsmount is unclonable */
#define MNT_PNODE_MASK 0xf0 /* propogation flag mask */
#define IS_MNT_SHARED(mnt) (mnt->mnt_flags & MNT_SHARED)
#define IS_MNT_SLAVE(mnt) (mnt->mnt_flags & MNT_SLAVE)
#define IS_MNT_PRIVATE(mnt) (mnt->mnt_flags & MNT_PRIVATE)
+#define IS_MNT_UNCLONE(mnt) (mnt->mnt_flags & MNT_UNCLONE)
#define CLEAR_MNT_SHARED(mnt) (mnt->mnt_flags &= ~(MNT_PNODE_MASK &
MNT_SHARED))
#define CLEAR_MNT_PRIVATE(mnt) (mnt->mnt_flags &= ~(MNT_PNODE_MASK &
MNT_PRIVATE))
#define CLEAR_MNT_SLAVE(mnt) (mnt->mnt_flags &= ~(MNT_PNODE_MASK & MNT_SLAVE))
+#define CLEAR_MNT_UNCLONE(mnt) (mnt->mnt_flags &= ~(MNT_PNODE_MASK &
MNT_UNCLONE))
struct vfsmount
{
@@ -59,6 +62,7 @@ static inline void set_mnt_shared(struct
mnt->mnt_flags |= MNT_PNODE_MASK & MNT_SHARED;
CLEAR_MNT_PRIVATE(mnt);
CLEAR_MNT_SLAVE(mnt);
+ CLEAR_MNT_UNCLONE(mnt);
}
static inline void set_mnt_private(struct vfsmount *mnt)
@@ -66,6 +70,16 @@ static inline void set_mnt_private(struc
mnt->mnt_flags |= MNT_PNODE_MASK & MNT_PRIVATE;
CLEAR_MNT_SLAVE(mnt);
CLEAR_MNT_SHARED(mnt);
+ CLEAR_MNT_UNCLONE(mnt);
+ mnt->mnt_pnode = NULL;
+}
+
+static inline void set_mnt_unclone(struct vfsmount *mnt)
+{
+ mnt->mnt_flags |= MNT_PNODE_MASK & MNT_UNCLONE;
+ CLEAR_MNT_SLAVE(mnt);
+ CLEAR_MNT_SHARED(mnt);
+ CLEAR_MNT_PRIVATE(mnt);
mnt->mnt_pnode = NULL;
}
@@ -74,6 +88,7 @@ static inline void set_mnt_slave(struct
mnt->mnt_flags |= MNT_PNODE_MASK & MNT_SLAVE;
CLEAR_MNT_PRIVATE(mnt);
CLEAR_MNT_SHARED(mnt);
+
[no subject]
, [EMAIL PROTECTED], Janak Desai <[EMAIL PROTECTED]>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 6/7] shared subtree
Content-Type: text/x-patch; name=namespace.patch
Content-Disposition: inline; filename=namespace.patch
Adds ability to clone a namespace that has shared/private/slave/unclone
subtrees in it.
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c |9 +
1 files changed, 9 insertions(+)
Index: 2.6.12-rc6.work1/fs/namespace.c
===
--- 2.6.12-rc6.work1.orig/fs/namespace.c
+++ 2.6.12-rc6.work1/fs/namespace.c
@@ -1894,6 +1894,13 @@ int copy_namespace(int flags, struct tas
q = new_ns->root;
while (p) {
q->mnt_namespace = new_ns;
+
+ if (IS_MNT_SHARED(q))
+ pnode_add_member_mnt(q->mnt_pnode, q);
+ else if (IS_MNT_SLAVE(q))
+ pnode_add_slave_mnt(q->mnt_pnode, q);
+ put_pnode(q->mnt_pnode);
+
if (fs) {
if (p == fs->rootmnt) {
rootmnt = p;
@@ -2271,6 +2278,8 @@ void __put_namespace(struct namespace *n
spin_lock(_lock);
list_for_each_entry(mnt, >list, mnt_list) {
+ if (mnt->mnt_pnode)
+ pnode_disassociate_mnt(mnt);
mnt->mnt_namespace = NULL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[no subject]
, [EMAIL PROTECTED], Janak Desai <[EMAIL PROTECTED]>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 1/7] shared subtree
Content-Type: text/x-patch; name=shared_private_slave.patch
Content-Disposition: inline; filename=shared_private_slave.patch
This patch adds the shared/private/slave support for VFS trees.
Signed by Ram Pai ([EMAIL PROTECTED])
fs/Makefile |2
fs/dcache.c |2
fs/namespace.c| 93 ++
fs/pnode.c| 441 ++
include/linux/fs.h|5
include/linux/mount.h | 44
include/linux/pnode.h | 90 ++
7 files changed, 673 insertions(+), 4 deletions(-)
Index: 2.6.12.work2/fs/namespace.c
===
--- 2.6.12.work2.orig/fs/namespace.c
+++ 2.6.12.work2/fs/namespace.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -62,6 +63,7 @@ struct vfsmount *alloc_vfsmnt(const char
INIT_LIST_HEAD(>mnt_mounts);
INIT_LIST_HEAD(>mnt_list);
INIT_LIST_HEAD(>mnt_fslink);
+ INIT_LIST_HEAD(>mnt_pnode_mntlist);
if (name) {
int size = strlen(name)+1;
char *newname = kmalloc(size, GFP_KERNEL);
@@ -615,6 +617,95 @@ out_unlock:
return err;
}
+static int do_make_shared(struct vfsmount *mnt)
+{
+ int err=0;
+ struct vfspnode *old_pnode = NULL;
+ /*
+* if the mount is already a slave mount,
+* allocate a new pnode and make it
+* a slave pnode of the original pnode.
+*/
+ if (IS_MNT_SLAVE(mnt)) {
+ old_pnode = mnt->mnt_pnode;
+ pnode_del_slave_mnt(mnt);
+ }
+ if(!IS_MNT_SHARED(mnt)) {
+ mnt->mnt_pnode = pnode_alloc();
+ if(!mnt->mnt_pnode) {
+ pnode_add_slave_mnt(old_pnode, mnt);
+ err = -ENOMEM;
+ goto out;
+ }
+ pnode_add_member_mnt(mnt->mnt_pnode, mnt);
+ }
+ if(old_pnode)
+ pnode_add_slave_pnode(old_pnode, mnt->mnt_pnode);
+ set_mnt_shared(mnt);
+out:
+ return err;
+}
+
+static int do_make_slave(struct vfsmount *mnt)
+{
+ int err=0;
+
+ if (IS_MNT_SLAVE(mnt))
+ goto out;
+ /*
+* only shared mounts can
+* be made slave
+*/
+ if (!IS_MNT_SHARED(mnt)) {
+ err = -EINVAL;
+ goto out;
+ }
+ pnode_member_to_slave(mnt);
+out:
+ return err;
+}
+
+static int do_make_private(struct vfsmount *mnt)
+{
+ if(mnt->mnt_pnode)
+ pnode_disassociate_mnt(mnt);
+ set_mnt_private(mnt);
+ return 0;
+}
+
+/*
+ * recursively change the type of the mountpoint.
+ */
+static int do_change_type(struct nameidata *nd, int flag)
+{
+ struct vfsmount *m, *mnt = nd->mnt;
+ int err=0;
+
+ if (!(flag & MS_SHARED) && !(flag & MS_PRIVATE)
+ && !(flag & MS_SLAVE))
+ return -EINVAL;
+
+ if (nd->dentry != nd->mnt->mnt_root)
+ return -EINVAL;
+
+ spin_lock(_lock);
+ for (m = mnt; m; m = next_mnt(m, mnt)) {
+ switch (flag) {
+ case MS_SHARED:
+ err = do_make_shared(m);
+ break;
+ case MS_SLAVE:
+ err = do_make_slave(m);
+ break;
+ case MS_PRIVATE:
+ err = do_make_private(m);
+ break;
+ }
+ }
+ spin_unlock(_lock);
+ return err;
+}
+
/*
* do loopback mount.
*/
@@ -1049,6 +1140,8 @@ long do_mount(char * dev_name, char * di
data_page);
else if (flags & MS_BIND)
retval = do_loopback(, dev_name, flags & MS_REC);
+ else if (flags & MS_SHARED || flags & MS_PRIVATE || flags & MS_SLAVE)
+ retval = do_change_type(, flags);
else if (flags & MS_MOVE)
retval = do_move_mount(, dev_name);
else
Index: 2.6.12.work2/fs/pnode.c
===
--- /dev/null
+++ 2.6.12.work2/fs/pnode.c
@@ -0,0 +1,441 @@
+/*
+ * linux/fs/pnode.c
+ *
+ * (C) Copyright IBM Corporation 2005.
+ * Released under GPL v2.
+ * Author : Ram Pai ([EMAIL PROTECTED])
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+static kmem_cache_t * pnode_cachep;
+
+/* spinlock for pnode related operations */
+ __cacheline_aligned_in_smp DEFINE_SPINLOCK(vfspnode_lock);
+
+enum pnode_vfs_type {
+ PNODE_MEMBER_VFS =
Re: [patch 2.6.13-rc3] i386: clean up user_mode macros
On Mon, 25 Jul 2005, Chuck Ebbert wrote: > > Recent patches from the Xen group changed the X86 user_mode macros. > > This patch does the following: > > 1. Makes the new user_mode() return 0 or 1 (same as x86_64) I _really_ prefer x != 0 over !!x since double negation is not only a bad habit in natural languages, it's a bad habit in computer languages too, for exactly the same reason. It's confusing. Ask a hundred random C programmers what "!!x" means, versus what "x != 0" means, and time their replies. I will bet you $5 USD that even if they all give the right answer (and I suspect you'll get a few wrogn answers in there too for the !! case), they'll take a _lot_ longer answering the "!!x" version than they will the "x != 0" question. And guess what? That means that the "!!x" version is worse. It means that people don't "see" what it means - they have to think about it. And you shouldn't have to think about something like that, you should write it in the obvious way in the first place. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
, [EMAIL PROTECTED], Janak Desai <[EMAIL PROTECTED]>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 7/7] shared subtree
Content-Type: text/x-patch; name=automount.patch
Content-Disposition: inline; filename=automount.patch
adds support for mount/umount propogation for autofs initiated operations,
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 176 +++---
fs/pnode.c| 12 +--
include/linux/pnode.h |3
3 files changed, 76 insertions(+), 115 deletions(-)
Index: 2.6.12.work2/fs/namespace.c
===
--- 2.6.12.work2.orig/fs/namespace.c
+++ 2.6.12.work2/fs/namespace.c
@@ -202,6 +202,9 @@ struct vfsmount *do_attach_prepare_mnt(s
if(!(child_mnt = clone_mnt(template_mnt,
template_mnt->mnt_root)))
return NULL;
+ spin_lock(_lock);
+ list_del_init(_mnt->mnt_fslink);
+ spin_unlock(_lock);
} else
child_mnt = template_mnt;
@@ -355,35 +358,14 @@ struct seq_operations mounts_op = {
*/
int may_umount_tree(struct vfsmount *mnt)
{
- struct list_head *next;
- struct vfsmount *this_parent = mnt;
- int actual_refs;
- int minimum_refs;
+ int actual_refs=0;
+ int minimum_refs=0;
+ struct vfsmount *p;
spin_lock(_lock);
- actual_refs = atomic_read(>mnt_count);
- minimum_refs = 2;
-repeat:
- next = this_parent->mnt_mounts.next;
-resume:
- while (next != _parent->mnt_mounts) {
- struct vfsmount *p = list_entry(next, struct vfsmount,
mnt_child);
-
- next = next->next;
-
+ for (p = mnt; p; p = next_mnt(p, mnt)) {
actual_refs += atomic_read(>mnt_count);
minimum_refs += 2;
-
- if (!list_empty(>mnt_mounts)) {
- this_parent = p;
- goto repeat;
- }
- }
-
- if (this_parent != mnt) {
- next = this_parent->mnt_child.next;
- this_parent = this_parent->mnt_parent;
- goto resume;
}
spin_unlock(_lock);
@@ -395,18 +377,18 @@ resume:
EXPORT_SYMBOL(may_umount_tree);
-int mount_busy(struct vfsmount *mnt)
+int mount_busy(struct vfsmount *mnt, int refcnt)
{
struct vfspnode *parent_pnode;
if (mnt == mnt->mnt_parent || !IS_MNT_SHARED(mnt->mnt_parent))
- return do_refcount_check(mnt, 2);
+ return do_refcount_check(mnt, refcnt);
parent_pnode = mnt->mnt_parent->mnt_pnode;
BUG_ON(!parent_pnode);
return pnode_mount_busy(parent_pnode,
mnt->mnt_mountpoint,
- mnt->mnt_root, mnt);
+ mnt->mnt_root, mnt, refcnt);
}
/**
@@ -424,9 +406,12 @@ int mount_busy(struct vfsmount *mnt)
*/
int may_umount(struct vfsmount *mnt)
{
- if (mount_busy(mnt))
- return -EBUSY;
- return 0;
+ int ret=0;
+ spin_lock(_lock);
+ if (mount_busy(mnt, 2))
+ ret = -EBUSY;
+ spin_unlock(_lock);
+ return ret;
}
EXPORT_SYMBOL(may_umount);
@@ -445,7 +430,26 @@ void do_detach_mount(struct vfsmount *mn
spin_lock(_lock);
}
-void __umount_tree(struct vfsmount *mnt, int propogate)
+void umount_mnt(struct vfsmount *mnt, int propogate)
+{
+ if (propogate && mnt->mnt_parent != mnt &&
+ IS_MNT_SHARED(mnt->mnt_parent)) {
+ struct vfspnode *parent_pnode
+ = mnt->mnt_parent->mnt_pnode;
+ BUG_ON(!parent_pnode);
+ pnode_umount(parent_pnode,
+ mnt->mnt_mountpoint,
+ mnt->mnt_root);
+ } else {
+ if (IS_MNT_SHARED(mnt) || IS_MNT_SLAVE(mnt)) {
+ BUG_ON(!mnt->mnt_pnode);
+ pnode_disassociate_mnt(mnt);
+ }
+ do_detach_mount(mnt);
+ }
+}
+
+static void __umount_tree(struct vfsmount *mnt, int propogate)
{
struct vfsmount *p;
LIST_HEAD(kill);
@@ -459,21 +463,7 @@ void __umount_tree(struct vfsmount *mnt,
mnt = list_entry(kill.next, struct vfsmount, mnt_list);
list_del_init(>mnt_list);
list_del_init(>mnt_fslink);
- if (propogate && mnt->mnt_parent != mnt &&
- IS_MNT_SHARED(mnt->mnt_parent)) {
- struct vfspnode *parent_pnode
- = mnt->mnt_parent->mnt_pnode;
- BUG_ON(!parent_pnode);
- pnode_umount(parent_pnode,
- mnt->mnt_mountpoint,
- mnt->mnt_root);
- } else {
- if (IS_MNT_SHARED(mnt) ||
[no subject]
, [EMAIL PROTECTED], Janak Desai <[EMAIL PROTECTED]>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 5/7] shared subtree
Content-Type: text/x-patch; name=umount.patch
Content-Disposition: inline; filename=umount.patch
Adds ability to unmount a shared/slave/unclone/private tree
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 76 --
fs/pnode.c| 66 +++
include/linux/fs.h|3 +
include/linux/pnode.h |9 -
4 files changed, 138 insertions(+), 16 deletions(-)
Index: 2.6.12.work2/fs/pnode.c
===
--- 2.6.12.work2.orig/fs/pnode.c
+++ 2.6.12.work2/fs/pnode.c
@@ -666,3 +666,69 @@ int pnode_abort_mount(struct vfspnode *p
NULL, (void *)NULL, NULL, NULL,
vfs_abort_mount_func, exception_mnt);
}
+
+static int vfs_busy(struct vfsmount *mnt, enum pnode_vfs_type flag,
+ void *indata, va_list args)
+{
+ struct dentry *dentry = va_arg(args, struct dentry *);
+ struct dentry *rootdentry = va_arg(args, struct dentry *);
+ struct vfsmount *origmnt = va_arg(args, struct vfsmount *);
+ struct vfsmount *child_mnt;
+ int ret=0;
+
+ spin_unlock(_lock);
+ child_mnt = __lookup_mnt(mnt, dentry, rootdentry);
+ spin_lock(_lock);
+
+ if (!child_mnt)
+ return 0;
+
+ if (list_empty(_mnt->mnt_mounts)) {
+ if (origmnt == child_mnt)
+ ret = do_refcount_check(child_mnt, 3);
+ else
+ ret = do_refcount_check(child_mnt, 2);
+ }
+ mntput(child_mnt);
+ return ret;
+}
+
+int pnode_mount_busy(struct vfspnode *pnode, struct dentry *mntpt,
+ struct dentry *root, struct vfsmount *mnt)
+{
+ return pnode_traverse(pnode, NULL, NULL,
+ NULL, NULL, vfs_busy, mntpt, root, mnt);
+}
+
+
+int vfs_umount(struct vfsmount *mnt, enum pnode_vfs_type flag,
+ void *indata, va_list args)
+{
+ struct vfsmount *child_mnt;
+ struct dentry *dentry, *rootdentry;
+
+
+ dentry = va_arg(args, struct dentry *);
+ rootdentry = va_arg(args, struct dentry *);
+
+ spin_unlock(_lock);
+ child_mnt = __lookup_mnt(mnt, dentry, rootdentry);
+ spin_lock(_lock);
+ mntput(child_mnt);
+ if (child_mnt && list_empty(_mnt->mnt_mounts)) {
+ if (IS_MNT_SHARED(child_mnt) ||
+ IS_MNT_SLAVE(child_mnt)) {
+ BUG_ON(!child_mnt->mnt_pnode);
+ pnode_disassociate_mnt(child_mnt);
+ }
+ do_detach_mount(child_mnt);
+ }
+ return 0;
+}
+
+int pnode_umount(struct vfspnode *pnode, struct dentry *dentry,
+ struct dentry *rootdentry)
+{
+ return pnode_traverse(pnode, NULL, (void *)NULL,
+ NULL, NULL, vfs_umount, dentry, rootdentry);
+}
Index: 2.6.12.work2/fs/namespace.c
===
--- 2.6.12.work2.orig/fs/namespace.c
+++ 2.6.12.work2/fs/namespace.c
@@ -395,6 +395,20 @@ resume:
EXPORT_SYMBOL(may_umount_tree);
+int mount_busy(struct vfsmount *mnt)
+{
+ struct vfspnode *parent_pnode;
+
+ if (mnt == mnt->mnt_parent || !IS_MNT_SHARED(mnt->mnt_parent))
+ return do_refcount_check(mnt, 2);
+
+ parent_pnode = mnt->mnt_parent->mnt_pnode;
+ BUG_ON(!parent_pnode);
+ return pnode_mount_busy(parent_pnode,
+ mnt->mnt_mountpoint,
+ mnt->mnt_root, mnt);
+}
+
/**
* may_umount - check if a mount point is busy
* @mnt: root of mount
@@ -410,14 +424,28 @@ EXPORT_SYMBOL(may_umount_tree);
*/
int may_umount(struct vfsmount *mnt)
{
- if (atomic_read(>mnt_count) > 2)
+ if (mount_busy(mnt))
return -EBUSY;
return 0;
}
EXPORT_SYMBOL(may_umount);
-void umount_tree(struct vfsmount *mnt)
+void do_detach_mount(struct vfsmount *mnt)
+{
+ struct nameidata old_nd;
+ if (mnt != mnt->mnt_parent) {
+ detach_mnt(mnt, _nd);
+ path_release(_nd);
+ }
+ list_del_init(>mnt_list);
+ list_del_init(>mnt_fslink);
+ spin_unlock(_lock);
+ mntput(mnt);
+ spin_lock(_lock);
+}
+
+void __umount_tree(struct vfsmount *mnt, int propogate)
{
struct vfsmount *p;
LIST_HEAD(kill);
@@ -431,20 +459,40 @@ void umount_tree(struct vfsmount *mnt)
mnt = list_entry(kill.next, struct vfsmount, mnt_list);
list_del_init(>mnt_list);
list_del_init(>mnt_fslink);
- if (mnt->mnt_parent == mnt) {
- spin_unlock(_lock);
+ if (propogate && mnt->mnt_parent != mnt &&
+
Re: [patch 1/2] Touchscreen support for sharp sl-5500
On Tue, Jul 26, 2005 at 12:06:59AM +0200, Pavel Machek wrote: > > > Also it looks to me like mcp.h should go into asm/arch-sa1100, so > > > that other drivers can use it... > > > > That doesn't make sense when you have other non-SA1100 devices using > > mcp-core.c. Whether that happens or not I've no idea - I can't see > > what everyone's using out there (just like I've absolutely zero > > idea what collie folk are doing or not doing.) > > set_telecom_divisor relies on CONFIG_SA1100 being set (otherwise it > breaks compilation, because struct members will not be available; at > least in this version), so I doubt it has many non-SA1100 users... That's not conclusive in itself - if it's only usable on SA1100 platforms, why was that ifdef added? > > So, if the collie folk would like to clean their changes up and send > > them to me as the driver author, I'll see about integrating them into > > my version and we'll take it from there. > > Okay, will do. [Is there chance to pull your tree using git? It would > help a bit...] My git usage is limited to the final stage of my development - iow providing an integration and test bed for merging upstream. My work prior to that is all patch based (as per the tarball of patches I posted previously) with scripts to manage them - I like the power to re-order, split, merge, insert and remove patches at random, which includes whole series of patches vs individual patches themselves. Consequently, if I were to publish my git trees, what you'll find is that they're indentical copies of Linus' tree except for maybe when Linus is away, or hasn't pulled that night, or... What you're actually seeing with the UCB stuff is the effect of me stopping maintaining the -rmk trees - code effectively got "dropped" from public view at that point, and I'm not going to start publishing such a tree any time soon. It completely detracts from the task of ensuring mainline kernels work for ARM - since the -rmk tree is/was seen as the tree for everything ARM to be merged into, and hence upstream merging became my problem. No, never again will I make a fool of myself like that. Hence, I'll never again publish a kernel tree myself, except maybe for very limited purposes. However, if the UCB stuff is going to get worked on, I don't mind setting up, maintaining and publishing a git tree for that that, provided it then vanishes once merged into mainline. That falls within the "very limited purposes" clause above. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.13-rc3] i386: clean up user_mode macros
Recent patches from the Xen group changed the X86 user_mode macros. This patch does the following: 1. Makes the new user_mode() return 0 or 1 (same as x86_64) 2. Removes conditional jump from user_mode_vm() (it's called every timer tick on each CPU on SMP) I've been running this patch for a while now. Please apply. Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]> Index: 2.6.13-rc3a/include/asm-i386/ptrace.h === --- 2.6.13-rc3a.orig/include/asm-i386/ptrace.h 2005-07-13 16:20:26.0 -0400 +++ 2.6.13-rc3a/include/asm-i386/ptrace.h 2005-07-14 02:47:51.0 -0400 @@ -57,8 +57,8 @@ #ifdef __KERNEL__ struct task_struct; extern void send_sigtrap(struct task_struct *tsk, struct pt_regs *regs, int error_code); -#define user_mode(regs)(3 & (regs)->xcs) -#define user_mode_vm(regs) ((VM_MASK & (regs)->eflags) || user_mode(regs)) +#define user_mode(regs)(!!(3 & (regs)->xcs)) +#define user_mode_vm(regs) (!!((VM_MASK & (regs)->eflags) | (3 & (regs)->xcs))) #define instruction_pointer(regs) ((regs)->eip) #if defined(CONFIG_SMP) && defined(CONFIG_FRAME_POINTER) extern unsigned long profile_pc(struct pt_regs *regs); __ Chuck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
, [EMAIL PROTECTED], Janak Desai <[EMAIL PROTECTED]>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 3/7] shared subtree
Content-Type: text/x-patch; name=rbind.patch
Content-Disposition: inline; filename=rbind.patch
Adds the ability to bind/rbind a shared/private/slave subtree and set up
propogation wherever needed.
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 660 --
fs/pnode.c| 235
include/linux/dcache.h|2
include/linux/fs.h|5
include/linux/namespace.h |1
5 files changed, 826 insertions(+), 77 deletions(-)
Index: 2.6.12.work2/fs/namespace.c
===
--- 2.6.12.work2.orig/fs/namespace.c
+++ 2.6.12.work2/fs/namespace.c
@@ -42,7 +42,8 @@ static inline int sysfs_init(void)
static struct list_head *mount_hashtable;
static int hash_mask, hash_bits;
-static kmem_cache_t *mnt_cache;
+static kmem_cache_t *mnt_cache;
+static struct rw_semaphore namespace_sem;
static inline unsigned long hash(struct vfsmount *mnt, struct dentry *dentry)
{
@@ -54,7 +55,7 @@ static inline unsigned long hash(struct
struct vfsmount *alloc_vfsmnt(const char *name)
{
- struct vfsmount *mnt = kmem_cache_alloc(mnt_cache, GFP_KERNEL);
+ struct vfsmount *mnt = kmem_cache_alloc(mnt_cache, GFP_KERNEL);
if (mnt) {
memset(mnt, 0, sizeof(struct vfsmount));
atomic_set(>mnt_count,1);
@@ -86,7 +87,8 @@ void free_vfsmnt(struct vfsmount *mnt)
* Now, lookup_mnt increments the ref count before returning
* the vfsmount struct.
*/
-struct vfsmount *lookup_mnt(struct vfsmount *mnt, struct dentry *dentry)
+struct vfsmount *__lookup_mnt(struct vfsmount *mnt, struct dentry *dentry,
+ struct dentry *root)
{
struct list_head * head = mount_hashtable + hash(mnt, dentry);
struct list_head * tmp = head;
@@ -99,7 +101,8 @@ struct vfsmount *lookup_mnt(struct vfsmo
if (tmp == head)
break;
p = list_entry(tmp, struct vfsmount, mnt_hash);
- if (p->mnt_parent == mnt && p->mnt_mountpoint == dentry) {
+ if (p->mnt_parent == mnt && p->mnt_mountpoint == dentry &&
+ (root == NULL || p->mnt_root == root)) {
found = mntget(p);
break;
}
@@ -108,6 +111,37 @@ struct vfsmount *lookup_mnt(struct vfsmo
return found;
}
+struct vfsmount *lookup_mnt(struct vfsmount *mnt, struct dentry *dentry)
+{
+ return __lookup_mnt(mnt, dentry, NULL);
+}
+
+static struct vfsmount *
+clone_mnt(struct vfsmount *old, struct dentry *root)
+{
+ struct super_block *sb = old->mnt_sb;
+ struct vfsmount *mnt = alloc_vfsmnt(old->mnt_devname);
+
+ if (mnt) {
+ mnt->mnt_flags = old->mnt_flags;
+ atomic_inc(>s_active);
+ mnt->mnt_sb = sb;
+ mnt->mnt_root = dget(root);
+ mnt->mnt_mountpoint = mnt->mnt_root;
+ mnt->mnt_parent = mnt;
+ mnt->mnt_namespace = old->mnt_namespace;
+ mnt->mnt_pnode = get_pnode(old->mnt_pnode);
+
+ /* stick the duplicate mount on the same expiry list
+* as the original if that was on one */
+ spin_lock(_lock);
+ if (!list_empty(>mnt_fslink))
+ list_add(>mnt_fslink, >mnt_fslink);
+ spin_unlock(_lock);
+ }
+ return mnt;
+}
+
static inline int check_mnt(struct vfsmount *mnt)
{
return mnt->mnt_namespace == current->namespace;
@@ -128,11 +162,71 @@ static void attach_mnt(struct vfsmount *
{
mnt->mnt_parent = mntget(nd->mnt);
mnt->mnt_mountpoint = dget(nd->dentry);
- list_add(>mnt_hash, mount_hashtable+hash(nd->mnt, nd->dentry));
+ mnt->mnt_namespace = nd->mnt->mnt_namespace;
+ list_add_tail(>mnt_hash,
+ mount_hashtable+hash(nd->mnt, nd->dentry));
list_add_tail(>mnt_child, >mnt->mnt_mounts);
nd->dentry->d_mounted++;
}
+static void attach_prepare_mnt(struct vfsmount *mnt, struct nameidata *nd)
+{
+ mnt->mnt_parent = mntget(nd->mnt);
+ mnt->mnt_mountpoint = dget(nd->dentry);
+ nd->dentry->d_mounted++;
+}
+
+
+void do_attach_commit_mnt(struct vfsmount *mnt)
+{
+ struct vfsmount *parent = mnt->mnt_parent;
+ BUG_ON(parent==mnt);
+ if(list_empty(>mnt_hash))
+ list_add_tail(>mnt_hash,
+ mount_hashtable+hash(parent, mnt->mnt_mountpoint));
+ if(list_empty(>mnt_child))
+ list_add_tail(>mnt_child, >mnt_mounts);
+ mnt->mnt_namespace = parent->mnt_namespace;
+ list_add_tail(>mnt_list, >mnt_namespace->list);
+}
+
+struct vfsmount *do_attach_prepare_mnt(struct vfsmount
[no subject]
, [EMAIL PROTECTED], Janak Desai <[EMAIL PROTECTED]>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 4/7] shared subtree
Content-Type: text/x-patch; name=move.patch
Content-Disposition: inline; filename=move.patch
Adds ability to move a shared/private/slave/unclone tree to any other
shared/private/slave/unclone tree. Also incorporates the same behavior
for pivot_root()
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 196 +++---
include/linux/mount.h |2
2 files changed, 173 insertions(+), 25 deletions(-)
Index: 2.6.12.work2/fs/namespace.c
===
--- 2.6.12.work2.orig/fs/namespace.c
+++ 2.6.12.work2/fs/namespace.c
@@ -772,9 +772,12 @@ static void abort_attach_recursive_mnt(s
list_del_init(head);
}
+
/*
* @source_mnt : mount tree to be attached
* @nd: place the mount tree @source_mnt is attached
+ * @move : use the move semantics if set, else use normal attach
semantics
+ *as explained below
*
* NOTE: in the table below explains the semantics when a source vfsmount
* of a given type is attached to a destination vfsmount of a give type.
@@ -801,12 +804,41 @@ static void abort_attach_recursive_mnt(s
* | | || | |
*
*
- * (++) the mount will be propogated to all the vfsmounts in the pnode tree
+ * (++) the mount is propogated to all the vfsmounts in the pnode tree
* of the destination vfsmount, and all the non-slave new mounts in
* destination vfsmount will be added the source vfsmount's pnode.
- * (+) the mount will be propogated to the destination vfsmount
+ * (+) the mount is propogated to the destination vfsmount
* and the new mount will be added to the source vfsmount's pnode.
*
+ * -
+ * | MOVE MOUNT OPERATION|
+ * |***|
+ * | dest --> | shared | private | slave |unclonable |
+ * | source | || | |
+ * | | | || | |
+ * | v | || | |
+ * |***|
+ * | | || | |
+ * | shared | shared (++) | shared (+)|shared (+)| shared (+)|
+ * | | || | |
+ * | | || | |
+ * | private | shared (+)| private | private | private |
+ * | | || | |
+ * | | || | |
+ * | slave| shared (+++) | slave | slave| slave |
+ * | | || | |
+ * | | || | |
+ * | unclonable| invalid | unclonable |unclonable| unclonable|
+ * | | || | |
+ * | | || | |
+ *
+ *
+ * (+++) the mount is propogated to all the vfsmounts in the pnode tree
+ * of the destination vfsmount, and all the new mounts is
+ * added to a new pnode , which is a slave pnode of the
+ * source vfsmount's pnode.
+ *
+ *
* if the source mount is a tree, the operations explained above is
* applied to each vfsmount in the tree.
*
@@ -815,7 +847,7 @@ static void abort_attach_recursive_mnt(s
*
*/
static int attach_recursive_mnt(struct vfsmount *source_mnt,
- struct nameidata *nd)
+ struct nameidata *nd, int move)
{
struct vfsmount *mntpt_mnt, *last, *m, *p;
struct vfspnode *src_pnode, *dest_pnode, *tmp_pnode;
@@ -849,8 +881,8 @@ static int attach_recursive_mnt(struct v
list_add_tail(_list_head, _mnt->mnt_list);
for (m = source_mnt; m; m = next_mnt(m, source_mnt)) {
-
- BUG_ON(IS_MNT_UNCLONE(m));
+ int unclone = IS_MNT_UNCLONE(m);
+ int slave = IS_MNT_SLAVE(m);
while (p && p != m->mnt_parent)
p = p->mnt_parent;
@@ -866,7 +898,7 @@ static int attach_recursive_mnt(struct v
dest_pnode = IS_MNT_SHARED(mntpt_mnt) ?
mntpt_mnt->mnt_pnode : NULL;
- src_pnode = (IS_MNT_SHARED(m))?
+ src_pnode =
Re: VIA KT400 + Kernel 2.6.12 + IO-APIC + uhci_hcd = IRQ trouble
Le Lundi 25 Juillet 2005 22:44, Alan Stern a écrit : > > Now that's strange. When you plug the high-speed device into the > integrated ports, which IRQ counter changes? Since nothing is using IRQ > 21, it should be disabled and its counter should remain constant. Does > this mean the interrupts show up on IRQ 19 (used by ehci-hcd), or do they > not show up at all (i.e., is the USB connection just being polled)? I assume it's IRQ 19. cat /proc/interrupts doesn't show IRQ21 at all when uhci isn't loaded. IRQ 19 being shared with 4 IDE controllers that controls my hard drives, that's hard to isolate interrupts counts due to USB activity from interrupts counts due to disks activity... -- Michel Bouissou <[EMAIL PROTECTED]> OpenPGP ID 0xDDE8AC6E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oz6812, yenta_socket and madwifi
On Monday 25 July 2005 21.38, Peter Staubach wrote:
> Daniel Ritz wrote:
[...]
>
> Shouldn't the two pairs of calls to config_writeb() be using
> "O2_RES_READ_PREFETCH | O2_RES_WRITE_BURST" instead of
> "O2_RES_READ_PREFETCH | O2_RES_READ_PREFETCH"?
>
yes, of course. thanks for noticing. updated patch attached.
dominik/akpm, please drop the other and use this one instead...
thx, rgds
-daniel
-
[PATCH 11/11] pcmcia: disable read prefetch/write burst on old O2Micro bridges
From: Daniel Ritz <[EMAIL PROTECTED]>
older O2Micro bridges have problems with both read prefetch and write burst
depending on the combination of the chipset, bridge, cardbus card. safest
is to disable read prefetch and write burst on those old bridges.
Signed-off-by: Daniel Ritz <[EMAIL PROTECTED]>
Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
--
diff --git a/drivers/pcmcia/o2micro.h b/drivers/pcmcia/o2micro.h
--- a/drivers/pcmcia/o2micro.h
+++ b/drivers/pcmcia/o2micro.h
@@ -120,11 +120,16 @@
#define O2_MODE_E_LED_OUT 0x08
#define O2_MODE_E_SKTA_ACTV 0x10
+#define O2_RESERVED1 0x94
+#define O2_RESERVED2 0xD4
+#define O2_RES_READ_PREFETCH 0x02
+#define O2_RES_WRITE_BURST 0x08
+
static int o2micro_override(struct yenta_socket *socket)
{
/*
-* 'reserved' register at 0x94/D4. chaning it to 0xCA (8 bit) enables
-* read prefetching which for example makes the RME Hammerfall DSP
+* 'reserved' register at 0x94/D4. allows setting read prefetch and
write
+* bursting. read prefetching for example makes the RME Hammerfall DSP
* working. for some bridges it is at 0x94, for others at 0xD4. it's
* ok to write to both registers on all O2 bridges.
* from Eric Still, 02Micro.
@@ -132,20 +137,35 @@ static int o2micro_override(struct yenta
u8 a, b;
if (PCI_FUNC(socket->dev->devfn) == 0) {
- a = config_readb(socket, 0x94);
- b = config_readb(socket, 0xD4);
+ a = config_readb(socket, O2_RESERVED1);
+ b = config_readb(socket, O2_RESERVED2);
printk(KERN_INFO "Yenta O2: res at 0x94/0xD4: %02x/%02x\n", a,
b);
switch (socket->dev->device) {
+ /*
+* older bridges have problems with both read prefetch and write
+* bursting depending on the combination of the chipset, bridge
+* and the cardbus card. so disable them to be on the safe side.
+*/
+ case PCI_DEVICE_ID_O2_6729:
+ case PCI_DEVICE_ID_O2_6730:
+ case PCI_DEVICE_ID_O2_6812:
case PCI_DEVICE_ID_O2_6832:
- printk(KERN_INFO "Yenta O2: old bridge, not enabling
read prefetch / write burst\n");
+ case PCI_DEVICE_ID_O2_6836:
+ printk(KERN_INFO "Yenta O2: old bridge, disabling read
prefetch/write burst\n");
+ config_writeb(socket, O2_RESERVED1,
+ a & ~(O2_RES_READ_PREFETCH |
O2_RES_WRITE_BURST));
+ config_writeb(socket, O2_RESERVED2,
+ b & ~(O2_RES_READ_PREFETCH |
O2_RES_WRITE_BURST));
break;
default:
printk(KERN_INFO "Yenta O2: enabling read
prefetch/write burst\n");
- config_writeb(socket, 0x94, a | 0x0a);
- config_writeb(socket, 0xD4, b | 0x0a);
+ config_writeb(socket, O2_RESERVED1,
+ a | O2_RES_READ_PREFETCH |
O2_RES_WRITE_BURST);
+ config_writeb(socket, O2_RESERVED2,
+ b | O2_RES_READ_PREFETCH |
O2_RES_WRITE_BURST);
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [IBM] RE: [BUG] Fusion MPT Base Driver initialization failure wit h kdum p
Vivek Goyal <[EMAIL PROTECTED]> wrote: > > > If you don't stop the DMA engines before you boot the new kernel, the > > addresses they have to send data to will now be random points in that > > kernel's memory, leading to potential corruption of the new kernel > > image. > > [Copying it to fastboot and linux-kernel mailing lists] > > We are booting second kernel (capture kernel) from a reserved memory location > to take care of on-going DMA issues. So even if some DMA transactions are > going > on after the crash they will not corrupt the new kernel. > > > > > The interrupt panic of the fusion is probably a symptom of this: I bet a > > DMA transfer has just completed and the interrupt is to inform us of > > this (however, in the new kernel we're not expecting any transfers). > > That might very well be the case. So driver should simply ignore the > interrupt > when it is not expecting it or it should reset the device if it finds that > some interrupts are pending when it should not have been there. > > Basically it is a matter of hardening the driver so that it can handle/ > initialize the device even if the device is not in reset state. I'd expect that a lot of these problems could be reduced by simply pausing for a while in the crash handler, wait for I/O to complete. Other times these failures point at flaws and dubious assumptions in drivers themselves, fixing of which tends to collaterally help platform power mangement operations. However, I expect that it will always be the case that setups which try to perform crashdumps to their main production disks will be less reliable than setups which set aside hardware for the dumping. If it was me, and if I really cared about reliable dumps, I'd make sure that each machine had a $6 NIC set aside for crashdumping, and the dump kernel uses that NIC for an NFS dump and has no other device drivers configured. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi! > > > The problem is that the parent doesn't actually know how many > > > devices to create nor what to call them, and they're logically > > > indistinguishable from each other so there's no logical naming > > > system. > > > > Then we should probably not try to force them into driver model. Have > > parent device register struct device and when sub-drivers register > > they could attach class devices (like input devices) directly to the > > "main" device thus hiding presence of sub-sections of the chip from > > sysfs completely. My point is that we should not be using > > class_interface here - its purpose is diferent. > > If you look at _my_ version, you'll notice that it doesn't use the > class interface stuff. A previous version of it did, and this seems > to be what the collie stuff is based upon. > > What I suggest is that the collie folk need to update their driver > to my version so that we don't have two different forks of the same Yep, will do, and sorry for the confusion. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi! > > > > This adds support for reading ADCs (etc), neccessary to operate touch > > > > screen on Sharp Zaurus sl-5500. > > > > > > I would like to know what the diffs are between my version (attached) > > > and this version before they get applied. > > > > Hmm, diff looks quite big (attached), and I got it from lenz for 99% > > part. > > It looks like John's version is actually based on a previous revision > of this driver. 8/ Oops. > > I have made quite a lot of cleanups to touchscreen part, and it seems > > to be acceptable by input people. I think it should go into > > drivers/input/touchscreen/collie_ts.c... > > Err, why should my assabet touchscreen be called "collie_ts" ? > collie is just a platform which happens to use it - it's got > no relevance to the driver naming at all. Okay, I did not quite realized it was shared. > > Also it looks to me like mcp.h should go into asm/arch-sa1100, so > > that other drivers can use it... > > That doesn't make sense when you have other non-SA1100 devices using > mcp-core.c. Whether that happens or not I've no idea - I can't see > what everyone's using out there (just like I've absolutely zero > idea what collie folk are doing or not doing.) set_telecom_divisor relies on CONFIG_SA1100 being set (otherwise it breaks compilation, because struct members will not be available; at least in this version), so I doubt it has many non-SA1100 users... > > > The only reason my version has not been submitted is because it lives > > > in the drivers/misc directory, and mainline kernel folk don't like > > > drivers which clutter up that directory. In fact, I had been told > > > that drivers/misc should remain completely empty - which makes this > > > set of miscellaneous drivers homeless. > > > > Could they simply live in arch/arm/mach-sa1100? Or is arch/arm/soc > > better place? > > arch/arm/soc? That means that (a) we end up with another directory to > accumulate crap, (b) it's not a SoC so doesn't belong in a directory > named as such, (c) it means that the MCP and UCB drivers get their > individual files scattered throughout the kernel tree, one in this > directory, one in that directory, one in another random directory. > That's far from ideal. Well, I believe that UCB layer is quite well define and it looks quite okay for touchscreen driver to be near other touchscreens... ucb-core still needs to go somewhere, if drivers/misc was vetoed, perhaps arch/arm/misc would be okay? > Anyway, summarising this, the results are that what we have here is > a complete and utter mess. ;( Yep :-(. > So, if the collie folk would like to clean their changes up and send > them to me as the driver author, I'll see about integrating them into > my version and we'll take it from there. Okay, will do. [Is there chance to pull your tree using git? It would help a bit...] Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.13-rc3 udev/hotplug use memory after free
Keith Owens <[EMAIL PROTECTED]> wrote: > > 2.6.13-rc3 + kdb (which does not touch udev/hotplug) on IA64 (Altix). > gcc version 3.3.3 (SuSE Linux). Compiled with DEBUG_SLAB, > DEBUG_PREEMPT, DEBUG_SPINLOCK, DEBUG_SPINLOCK_SLEEP, DEBUG_KOBJECT. > > There is a use after free somewhere above class_device_attr_show. Can we obtain a backtrace for this one, Keith? The function itself is pretty innocuous and is used by many callers. I'd be suspectng a bug in the caller. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question re the dot releases such as 2.6.12.3
On Monday 25 July 2005 12:38, Brian Gerst wrote: >Gene Heskett wrote: >> Greetings; >> >> I just built what I thought was 2.6.12.3, but my script got a >> tummy ache because I didn't check the Makefile's EXTRA_VERSION, >> which was set to .2 in the .2 patch. Now my 2.6.12 modules will >> need a refresh build. :( >> >> So whats the proper patching sequence to build a 2.6.12.3? > >The dot-release patches are not incremental. You apply each one to > the base 2.6.12 tree. > Thats what I thought, and I blew that tree away & rebuilt it again using the same script, and it worked. Go figure... Thanks Brian. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with Asus P4C800-DX and P4 -Northwood-
Bill Davidsen wrote: One other oddment about this motherboard, Forgive if I have over-snipped this trying to make it relevant... Andreas Baer wrote: Willy Tarreau wrote: On Mon, Jul 25, 2005 at 03:10:08PM +0200, Andreas Baer wrote: There clearly is a problem on the system installed on this machine. You should use strace to see what this machine does all the time, it is absolutely not expected that the user/system ratios change so much between two nearly identical systems. So there are system calls which eat all CPU. You may want to try strace -Tttt on the running process during a few tens of seconds. I guess you'll immediately find the culprit amongst the syscalls, and it might give you a clue. I hope you are talking about a hardware/kernel problem and not a software problem, because I tried it also with LiveCD's and they showed the same results on this machine. I'm not a linux expert, that means I've never done anything like that before, so it would be nice if you give me a hint what you see in this results. :) Am I misreading this, or is your program doing a bunch of seeks not followed by an i/o operation? I would doubt that's important, but your vmstat showed a lot of system time, and I just wonder if llseek() is more expensive in Linux than Windows. Or if your code is such that these calls are not optimized away by gcc. I don't know what exactly produces this _llseek calls, but I ran the compiled binaries on both machines (desktop + notebook) without any recompilation and so I think they should do the same (even if this is bad or not optimized), but I see a time difference of more than 2:30 :) This _llseek calls also don't seem to be faster or slower if you compare the times on the notebook and the desktop. strace output for desktop: <--snip--> [pid 1431] 1122318636.262578 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.17> [pid 1431] 1122318636.262654 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.17> [pid 1431] 1122318636.262732 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.17> [pid 1431] 1122318636.262809 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.262881 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.262952 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263023 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263094 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.263165 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263237 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.263310 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263381 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263452 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263523 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.263594 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263666 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.17> [pid 1431] 1122318636.263740 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.24> [pid 1431] 1122318636.263841 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263913 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263984 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.14> [pid 1431] 1122318636.264055 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264127 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264199 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264271 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264342 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.264414 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.264487 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264558 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.264630 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264710 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264788 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.264861 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264934 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.265006 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.265077 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.265149 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.14> [pid 1431] 1122318636.265220
Re: Kernel 2.6.12 and 2.6.13 hangs for a while on boot
"Francisco Figueiredo Jr." <[EMAIL PROTECTED]> wrote: > > I'm having little hangs while booting with kernels 2.6.12 and 2.6.13-rc1, rc2 > and rc3. > > It is strange that 2.6.12-rc1 booted ok without hangs. > > I saw a post of Alan Cox on rc-1 release notes: > > "Old ISA/VESA systems sometimes put tertiary IDE controllers at addresses > 0x1e8, 0x168, 0x1e0 or 0x160. Linux thus probes these addresses on x86 > systems. Unfortunately some PCI systems now use these addresses for > other > purposes which leads to users seeing minute plus hangs during boot or > even > crashes." > > I thought this could be my problem, but it still hangs on boot. > > Hangs appears just before mounting filesystems message and before configuring > system to use udev. Are these hangs temporary or permanent? If they are temporary (ie: the kernel recovers OK) then we should call them "stalls". Because a "hang" is considered to be a permanent state. Either way, we need to know where the kernel is stuck. Adding `initcall_debug' to your kernel boot command may help. And when the hang/stall occurs, hit the ALT-SSQRQ-P and ALT-SYSRQ-T key combinations and send us the resulting traces. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: topology api confusion
Nathan Lynch wrote: > We need some clarity on how asm-generic/topology.h is intended to be > used. I suspect that it's supposed to be unconditionally included at > the end of the architecture's topology.h so that any elements which > are undefined by the arch have sensible default definitions. Looking > at 2.6.13-rc3, this is what ppc64, ia64, and x86_64 currently do, > however i386 does not (i386 pulls in the generic version only when > !CONFIG_NUMA). > > The #ifndef guards around each element of the topology api > cannot serve their apparent intended purpose when the architecture > implements a given bit as a function instead of a macro > (e.g. cpu_to_node in ppc64): When I originally wrote this all up, I had planned it to be used the way i386 does: offer a full implementation of topology if appropriate, else include the generic "sane" default. It has since changed to work more like you described: implement some (or all) of the topology functions, then include the generic one to define any you missed. > Since ppc64 unconditionally includes asm-generic/topology.h, all uses > of cpu_to_node are preprocessed to (0). Similar damage occurs with > every other topology function which happens to be a real function > instead of a macro. I'm surprised my ppc64 numa systems even boot ;) > > If the intent is that the architecture is free to define only a subset > of the api and include the generic header for fallback definitions, > then we need to do the #ifndef __HAVE_ARCH_FOO thing, no? That is, > the code above would look like: You are correct in noticing that things should (though apparently don't?) go wonky when arches define their topology functions as *functions*, rather than macros. It hasn't really seemed to bite anyone yet, so I've left it alone, though to be honest, it is as surprising to me that it works as it is to you. I've resisted creating #ifdef ARCH_HAVE_XXX all over the place, though maybe it is finally time? > Thought I'd ask for input first since this would involve a sweep of > include/asm-*. It would indeed... I'd be more than happy to look at any patches you care to generate. As I said, it seems to work, though I'm certain it's all held together by GCC black magic & voodoo, and probably a little duct-tape. A more obviously correct solution would not be a bad thing. :) -Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi! > > Can we change this to "while (!kthread_should_stop())" to make me > > completely happy? > > I still ask, and I'll keep repeating this. What is the difference > between this and the reference implementation which is known to > work on other hardware. I think I posted diffs already, but they were rather big and against wrong version. I'll try to get better diffs. > Let's not go all out on one implementation for one set of hardware, > but try to work out what we need to do to the generic reference > implementation to make it work on this hardware. I did not know it is supposed to work on other devices, too. My fault. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] Touchscreen support for sharp sl-5500
Hi!
> > I have made quite a lot of cleanups to touchscreen part, and it seems
> > to be acceptable by input people. I think it should go into
> > drivers/input/touchscreen/collie_ts.c... Also it looks to me like
> > mcp.h should go into asm/arch-sa1100, so that other drivers can use it...
>
> I have couple of nitpicks (below) and one bigger concern - I am
> surprised that a driver for a physical device is implemented as an
> interface to a class device. This precludes implementing any kind of
> power management in the driver and pushes it into the parent and is
> generally speaking is a wrong thing to do (IMHO).
I'll port my changes to newer version of rmk's tree, that should solve
it.
> > +static int ucb1x00_thread(void *_ts)
> > +{
> > + struct ucb1x00_ts *ts = _ts;
> > + struct task_struct *tsk = current;
> > + int valid;
> > +
> > + ts->rtask = tsk;
>
> Just move that assignment into ucb1x00_input_open and kill all this
> "current" stuff.
It will still want to set the priority, but yes, it cleaned it.
> > + /*
> > +* We run as a real-time thread. However, thus far
> > +* this doesn't seem to be necessary.
> > +*/
> > + tsk->policy = SCHED_FIFO;
> > + tsk->rt_priority = 1;
> > +
> > + valid = 0;
> > + for (;;) {
>
> Can we change this to "while (!kthread_should_stop())" to make me
> completely happy?
:-) Ok.
[Just FYI, I'll post agregated patch when I solve file placement and
port to newer version.]
Cleanups suggested by Dmitri.
---
commit 60814924ed695d863fa226c24b3d4e96054c8b66
tree 0e88e8272c23926c5654ae10bfe14d4cb2af84ab
parent ff30d8505b88064a5f6e6e70bd42028150a864e2
author <[EMAIL PROTECTED](none)> Mon, 25 Jul 2005 23:35:21 +0200
committer <[EMAIL PROTECTED](none)> Mon, 25 Jul 2005 23:35:21 +0200
drivers/input/touchscreen/collie_ts.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/input/touchscreen/collie_ts.c
b/drivers/input/touchscreen/collie_ts.c
--- a/drivers/input/touchscreen/collie_ts.c
+++ b/drivers/input/touchscreen/collie_ts.c
@@ -158,8 +158,6 @@ static int ucb1x00_thread(void *_ts)
struct task_struct *tsk = current;
int valid;
- ts->rtask = tsk;
-
/*
* We run as a real-time thread. However, thus far
* this doesn't seem to be necessary.
@@ -168,7 +166,7 @@ static int ucb1x00_thread(void *_ts)
tsk->rt_priority = 1;
valid = 0;
- for (;;) {
+ while (!kthread_should_stop()) {
unsigned int x, y, p, val;
ts->restart = 0;
@@ -231,9 +229,6 @@ static int ucb1x00_thread(void *_ts)
msleep_interruptible(10);
}
-
- if (kthread_should_stop())
- break;
}
ts->rtask = NULL;
@@ -273,11 +268,12 @@ static int ucb1x00_ts_open(struct input_
ts->y_res = ucb1x00_ts_read_yres(ts);
ucb1x00_adc_disable(ts->ucb);
- task = kthread_run(ucb1x00_thread, ts, "ktsd");
- if (!IS_ERR(task)) {
+ ts->rtask = kthread_run(ucb1x00_thread, ts, "ktsd");
+ if (!IS_ERR(ts->task)) {
ret = 0;
} else {
ucb1x00_free_irq(ts->ucb, UCB_IRQ_TSPX, ts);
+ ts->rtask = NULL;
ret = -EFAULT;
}
--
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Variable ticks
On Mon, 2005-07-25 at 17:19 -0400, Brown, Len wrote: > >>>Question one, are there other actions to consider? > >> > >> > >> Yes. > >> Speaking for ACPI C3 state, note that DMA also > >> wakes up the CPU -- even if there was no device interrupt. > >> (aka, "the trouble with USB") > > > >Trouble? Why would USB do DMA unless there was a device activity? > > look here: > http://www.google.com/search?hl=en=usb+selective+suspend > > Linux is working on it too, but it is in development. What about audio? If there is a sound server running then you're going to have a constant stream of interrupts and DMA activity from the sound card even if the machine is idle and there aren't any sounds playing. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: data + pendrive + memory
On Mon, 25 Jul 2005, Rodrigo Ramos wrote: > > IMHO, if a lack of memory happens the Linux will start using swap, then > the file will end in the hard drive. When I am working with a file in a > pendrive any information of it is sent to the hard drive ? If it happens > what is/are the reason(s). If you always access the file only with mmap(..MAP_SHARED..) (or MAP_PRIVATE in a read-only manner), or if you always make sure that any programs that access the data use mlock() to protect it, you'll never hit the regular disk. mmap() is generally the better option, since locking down memory may not be available to normal users. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Variable ticks
>>>Question one, are there other actions to consider? >> >> >> Yes. >> Speaking for ACPI C3 state, note that DMA also >> wakes up the CPU -- even if there was no device interrupt. >> (aka, "the trouble with USB") > >Trouble? Why would USB do DMA unless there was a device activity? look here: http://www.google.com/search?hl=en=usb+selective+suspend Linux is working on it too, but it is in development. cheers, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ping^2: [PATCH] move /proc/ppc_htab creating self-contained in arch/ppc/ code
On Jul 25, 2005, at 1:12 PM, Paul Mackerras wrote: Christoph Hellwig writes: On Mon, Jun 27, 2005 at 11:05:02PM +0200, Christoph Hellwig wrote: On Wed, May 04, 2005 at 08:44:39PM +0200, Christoph Hellwig wrote: additional benefit is cleaning up the ifdef mess in ppc_htab.c Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> ping? I would actually rather get rid of /proc/ppc_htab altogether. What do we need to do to get rid of it completely? - kumar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: elvtune with 2.6 kernels (under FC3)
On Mon, Jul 25, 2005 at 04:31:56PM -0400, Gaspar Bakos wrote: > Hi, Hi Gaspar, > I am cc-ing this to the kernel list, a i have the suspicion that it may > be a kernel related feature. > > -- > I noticed that elvtune does not work on FC3 with a 2.6.12.3 > (self-compiled, pristine) kernel. I also tried it with other 2.6.* kernels. > > elvtune /dev/sde > ioctl get: Invalid argument > > In fact, I get the same message for all disks, either those on a 3ware > controller, or SATA disks directly attached to the motherboard. > The hw is a dual opteron mb with 4Gb RAM. > > Did this command become obsoleted? > Is there alternativ? util-linux >= 2.12h gives you a better error message: # elvtune /dev/hda ioctl get: Invalid argument elvtune is only useful on older kernels; for 2.6 use IO scheduler sysfs tunables instead.. # > Cheers > Gaspar 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/
ACPI oddity
On a HT system, why does ACPI recognize CPU0 and CPU1, refer to them as such in dmesg, and then call them CPU1 and CPU2 in /proc/acpi/processor? In uni kernels the single processor is CPU0. This is a 2.6.10 kernel, the machine has been up since then. I have other 2.6 machines and other SMP and/or HT machines, but all of the HT machines running 2.6 are behind a hard firewall except one. It's running the ASUS P4P800 board which is why I looked, BIOS 1086. -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -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: Problem with Asus P4C800-DX and P4 -Northwood-
On Mon, Jul 25, 2005 at 10:38:25PM +0200, Jesper Juhl wrote: > It's even more complex than that as far as I know, you also have the > issue of seek times - tracks near the middle of the platter will be > nearer the head more often (on average) then tracks at the edge. > > For people who like visuals, IBM has a nice little picture in their > AIX performance tuning guide : > http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/aixbman/prftungd/diskperf2.htm Quote from that document: "Data is more dense as it moves toward the center, resulting in less physical movement of the head. This results in faster overall throughput" This is not true. The whole idea of different recording zones with different sectors/track is to keep the overall data density (in bits/square mm) more or less constant. I'd say it's even the other way around from what IBM pictures: there are more sectors/track in outer zones, so that means there is simply more data in the outer zones. If you want less physical movement of the head, you should make sure the data is in the zone(s) with the largest number of sectors/track. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Variable ticks
Brown, Len wrote: I was thinking about variable tick times, and I can think of three classes of action needing CPU attention. - device interrupts, which occur at no predictable time but would pull the CPU out of a HLT or low power state. - process sleeps of various kinds, which have a known time of occurence. - polled devices... Question one, are there other actions to consider? Yes. Speaking for ACPI C3 state, note that DMA also wakes up the CPU -- even if there was no device interrupt. (aka, "the trouble with USB") Trouble? Why would USB do DMA unless there was a device activity? Question two, what about those polled devices? it is a real challenge to save power under such conditions, unless you can throttle the polling rate such that the processor can actually enters idle while polling is underway. I've been asked to give a high level overview of the recent discussion for a meeting, and while I want to keep it at the level of "slower clock, fewer interrupts" and "faster clock, better sleep resolution," I don't want to leave out any important issues, or be asked a question (like how to handle polling devices) when I have no idea what people are thinking in an area. From a power management point of view, what is important is what we do when idle. ie. on my laptop, from a power savings point of view, I wouldn't care much if HZ=1000 all the time if HZ=0 when in idle. That could hurt the polling performance, all right. ;-) Outside of idle, the tick rate is much less important to power savings, unless the change in tick rate was significant enough to change the load enough that we'd want to change the target non-idle MHz of the processor. Isn't that more or less what on demand does? Thanks for the feedback, I can probably just say that DMA wakes the CPU from C3 and let it ride, I don't want to skip it, but neither do I need to go into detail. -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -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: VIA KT400 + Kernel 2.6.12 + IO-APIC + uhci_hcd = IRQ trouble
On Mon, 25 Jul 2005, Michel Bouissou wrote: > Le Lundi 25 Juillet 2005 21:18, Alan Stern a écrit : > > > > It seems quite clear that the EHCI controller's IRQ line is causing the > > problems. Just out of curiousity, what happens if you really do remove > > the UHCI driver, keeping only the EHCI driver, and then plug in the mouse? > > Off hand I would expect nothing much to happen -- maybe a line or two in > > the system log, no change to the IRQ counters, and the mouse doesn't work > > (not even erratically). > > As you expect, in such a condition (with only ehci loaded), absolutely > nothing > happens when plugging the mouse. > > OTOH, a high-speed device is recognized, althouh it generates messages like: > > totor kernel: usb 1-5: device not accepting address 3, error -71 > totor kernel: usb 1-5: new high speed USB device using ehci_hcd and address 4 > totor kernel: usb 1-5: device not accepting address 4, error -71 > totor kernel: usb 1-5: new high speed USB device using ehci_hcd and address 5 > > If plugged to any USB socket, except the two integrated to the motherboard > connectors plate. There only it fully succeeds without such errors. Now that's strange. When you plug the high-speed device into the integrated ports, which IRQ counter changes? Since nothing is using IRQ 21, it should be disabled and its counter should remain constant. Does this mean the interrupts show up on IRQ 19 (used by ehci-hcd), or do they not show up at all (i.e., is the USB connection just being polled)? Those -71 errors do not indicate IRQ problems -- they indicate low-level errors in the USB data signals. They could be caused by problems in the cabling from the motherboard to the ports, problems in the electrical terminations, or other things. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with Asus P4C800-DX and P4 -Northwood-
One other oddment about this motherboard, Forgive if I have over-snipped this trying to make it relevant... Andreas Baer wrote: Willy Tarreau wrote: On Mon, Jul 25, 2005 at 03:10:08PM +0200, Andreas Baer wrote: There clearly is a problem on the system installed on this machine. You should use strace to see what this machine does all the time, it is absolutely not expected that the user/system ratios change so much between two nearly identical systems. So there are system calls which eat all CPU. You may want to try strace -Tttt on the running process during a few tens of seconds. I guess you'll immediately find the culprit amongst the syscalls, and it might give you a clue. I hope you are talking about a hardware/kernel problem and not a software problem, because I tried it also with LiveCD's and they showed the same results on this machine. I'm not a linux expert, that means I've never done anything like that before, so it would be nice if you give me a hint what you see in this results. :) Am I misreading this, or is your program doing a bunch of seeks not followed by an i/o operation? I would doubt that's important, but your vmstat showed a lot of system time, and I just wonder if llseek() is more expensive in Linux than Windows. Or if your code is such that these calls are not optimized away by gcc. strace output for desktop: <--snip--> [pid 1431] 1122318636.262578 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.17> [pid 1431] 1122318636.262654 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.17> [pid 1431] 1122318636.262732 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.17> [pid 1431] 1122318636.262809 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.262881 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.262952 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263023 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263094 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.263165 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263237 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.263310 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263381 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263452 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263523 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.263594 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263666 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.17> [pid 1431] 1122318636.263740 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.24> [pid 1431] 1122318636.263841 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263913 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.263984 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.14> [pid 1431] 1122318636.264055 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264127 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264199 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264271 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264342 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.264414 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.264487 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264558 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.264630 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264710 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264788 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.264861 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.264934 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.265006 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.265077 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.265149 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.14> [pid 1431] 1122318636.265220 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.265292 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.265363 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.16> [pid 1431] 1122318636.265436 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.265509 _llseek(3, 1761280, [1761280], SEEK_SET) = 0 <0.15> [pid 1431] 1122318636.265580
