Re: [PATCH 00/18] Make common x86 arch area for i386 and x86_64 - Take 2
On Mar 14 2007 01:08, Steven Rostedt wrote: > >So I spent last night hacking up something to try to make a common ground >for all code that is shared between x86_64 and i386. I called this > > arch/x86 > >Seems appropriate, but I really don't care what it's called. One thing about >this name, is that typing arch/x86 doesn't tab complete x86_64 anymore. >But if you can think of something better, I'd be happy to apply it. 80x86 8086 ia32 <- I'd go with this for lack of more entries on this list. i486 i86pc <- Solely listed for completes. No Solarisisms in Linux please :p ix86 x32<- Blame Microsoft for introducing "x64" x86_32 <- Will interfere with your tabbing. >So the moves are simply renames, with the slight exception >of files that hold the speedstep-lib.h file. This file was moved from the >arch/i386/kerne/cpu/cpufreq directory and put into the include/asm-i386 >directory. This was due to the fact that some of the moved files included >it, and some files that were not moved also included it. Instead of using >the #include "../../x86/" hack again, cd arch/i386/kernel/; ln -s ../../ia32 ia32; with obj-m += ia32/foo.c and #include "ia32/.../foo.h" a bit nicer IMO, but may not work as intended. > I just simply moved it to the global >i386 include directory. Only the arch/x86 will use the include/asm-i386 >change. But to make this change the move patches of the files that contain >this change also contain the changes to reference the change to locate this >file. > >With this change of having a single repo that holds both the x86_64 files >as well as the i386 code, it becomes obvious of what files are being shared. >This way we don't have to worry about someone changing a file in either >x86_64 or i386 and having it break the other arch, because they didn't >realize it was being shared. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Stolen and degraded time and schedulers
On Tue, 2007-03-13 at 23:52 -0700, Jeremy Fitzhardinge wrote: > Yep. But the tsc is just an example of a clocksource, and doesn't have > any real bearing on what I'm saying. [cut/snip/slash] > Well, it doesn't need to be a constant clock if its modelling a changing > rate. And it doesn't need to be an exact model; it just needs to be > better than the current situation. It's 2 AM so I don't know if I'm making sense, but I had an idea for the sort of clock I think you're looking for. Couldn't one of the CPU performance counters do this? I think you can set one to count cycles and trigger every 100,000, or 10,000 or 1,000, or whatever. Then when you get that interrupt hit the context switch. Then every time slice would be in cycles and not wall-clock, which is what I think you wanted. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: copy_one_pte()
Christoph Hellwig wrote: On Tue, Mar 13, 2007 at 08:15:25PM +0100, Zoltan Menyhart wrote: I had a look at copy_one_pte(). I cannot see any ioproc_update_page() call, not even for the COW pages. Is it intentional? There is no such thing as ioproc_update_page in any mainline tree. You must be looking at some vendor tree with braindead patches applied. It looks like this function exists as a part of patches to support Quadrics NICs / RDMA (HPC platforms). The patches are there so the driver doesn't need to pin pages, it can be informed of page updates directly. A patch was submitted to l-k sometime in 2005. 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: [RFC][PATCH 4/7] RSS accounting hooks over the code
Nick Piggin wrote: Balbir Singh wrote: Nick Piggin wrote: And strangely, this example does not go outside the parameters of what you asked for AFAIKS. In the worst case of one container getting _all_ the shared pages, they will still remain inside their maximum rss limit. When that does happen and if a container hits it limit, with a LRU per-container, if the container is not actually using those pages, they'll get thrown out of that container and get mapped into the container that is using those pages most frequently. Exactly. Statistically, first touch will work OK. It may mean some reclaim inefficiencies in corner cases, but things will tend to even out. Exactly! So they might get penalised a bit on reclaim, but maximum rss limits will work fine, and you can (almost) guarantee X amount of memory for a given container, and it will _work_. But I also take back my comments about this being the only design I have seen that gets everything, because the node-per-container idea is a really good one on the surface. And it could mean even less impact on the core VM than this patch. That is also a first-touch scheme. With the proposed node-per-container, we will need to make massive core VM changes to reorganize zones and nodes. We would want to allow 1. For sharing of nodes 2. Resizing nodes 3. May be more But a lot of that is happening anyway for other reasons (eg. memory plug/unplug). And I don't consider node/zone setup to be part of the "core VM" as such... it is _good_ if we can move extra work into setup rather than have it in the mm. That said, I don't think this patch is terribly intrusive either. Thanks, thats one of our goals, to keep it simple, understandable and non-intrusive. With the node-per-container idea, it will hard to control page cache limits, independent of RSS limits or mlock limits. NOTE: page cache == unmapped page cache here. I don't know that it would be particularly harder than any other first-touch scheme. If one container ends up being charged with too much pagecache, eventually they'll reclaim a bit of it and the pages will get charged to more frequent users. Yes, true, but what if a user does not want to control the page cache usage in a particular container or wants to turn off RSS control. However the messed up accounting that doesn't handle sharing between groups of processes properly really bugs me. Especially when we have the infrastructure to do it right. Does that make more sense? I think it is simplistic. Sure you could probably use some of the rmap stuff to account shared mapped _user_ pages once for each container that touches them. And this patchset isn't preventing that. But how do you account kernel allocations? How do you account unmapped pagecache? What's the big deal so many accounting people have with just RSS? I'm not a container person, this is an honest question. Because from my POV if you conveniently ignore everything else... you may as well just not do any accounting at all. We decided to implement accounting and control in phases 1. RSS control 2. unmapped page cache control 3. mlock control 4. Kernel accounting and limits This has several advantages 1. The limits can be individually set and controlled. 2. The code is broken down into simpler chunks for review and merging. But this patch gives the groundwork to handle 1-4, and it is in a small chunk, and one would be able to apply different limits to different types of pages with it. Just using rmap to handle 1 does not really seem like a viable alternative because it fundamentally isn't going to handle 2 or 4. For (2), we have the basic setup in the form of a per-container LRU list and a pointer from struct page to the container that first brought in the page. I'm not saying that you couldn't _later_ add something that uses rmap or our current RSS accounting to tweak container-RSS semantics. But isn't it sensible to lay the groundwork first? Get a clear path to something that is good (not perfect), but *works*? I agree with your development model suggestion. One of things we are going to do in the near future is to build (2) and then add (3) and (4). So far, we've not encountered any difficulties on building on top of (1). Vaidy, any comments? -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/13] ibmtr probe is __devinit, not __init
used by ->attach() in pcmcia analog
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/net/pcmcia/ibmtr_cs.c |4 ++--
drivers/net/tokenring/ibmtr.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/pcmcia/ibmtr_cs.c b/drivers/net/pcmcia/ibmtr_cs.c
index a956a51..1060154 100644
--- a/drivers/net/pcmcia/ibmtr_cs.c
+++ b/drivers/net/pcmcia/ibmtr_cs.c
@@ -138,7 +138,7 @@ static const struct ethtool_ops netdev_ethtool_ops = {
==*/
-static int ibmtr_attach(struct pcmcia_device *link)
+static int __devinit ibmtr_attach(struct pcmcia_device *link)
{
ibmtr_dev_t *info;
struct net_device *dev;
@@ -217,7 +217,7 @@ static void ibmtr_detach(struct pcmcia_device *link)
#define CS_CHECK(fn, ret) \
do { last_fn = (fn); if ((last_ret = (ret)) != 0) goto cs_failed; } while (0)
-static int ibmtr_config(struct pcmcia_device *link)
+static int __devinit ibmtr_config(struct pcmcia_device *link)
{
ibmtr_dev_t *info = link->priv;
struct net_device *dev = info->dev;
diff --git a/drivers/net/tokenring/ibmtr.c b/drivers/net/tokenring/ibmtr.c
index 36202e9..01d5531 100644
--- a/drivers/net/tokenring/ibmtr.c
+++ b/drivers/net/tokenring/ibmtr.c
@@ -346,7 +346,7 @@ static void ibmtr_cleanup_card(struct net_device *dev)
* which references it.
/
-static int __init ibmtr_probe(struct net_device *dev)
+static int __devinit ibmtr_probe(struct net_device *dev)
{
int i;
int base_addr = dev->base_addr;
@@ -366,7 +366,7 @@ static int __init ibmtr_probe(struct net_device *dev)
return -ENODEV;
}
-int __init ibmtr_probe_card(struct net_device *dev)
+int __devinit ibmtr_probe_card(struct net_device *dev)
{
int err = ibmtr_probe(dev);
if (!err) {
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/13] const file_operations fallout
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
sound/oss/dmasound/dmasound_core.c | 20
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/sound/oss/dmasound/dmasound_core.c
b/sound/oss/dmasound/dmasound_core.c
index a0ec886..f4056a9 100644
--- a/sound/oss/dmasound/dmasound_core.c
+++ b/sound/oss/dmasound/dmasound_core.c
@@ -1346,22 +1346,34 @@ static const struct file_operations sq_fops =
.ioctl = sq_ioctl,
.open = sq_open,
.release= sq_release,
+};
+
#ifdef HAS_RECORD
- .read = NULL /* default to no read for compat mode */
-#endif
+static const struct file_operations sq_fops_record =
+{
+ .owner = THIS_MODULE,
+ .llseek = no_llseek,
+ .write = sq_write,
+ .poll = sq_poll,
+ .ioctl = sq_ioctl,
+ .open = sq_open,
+ .release= sq_release,
+ .read = sq_read,
};
+#endif
static int sq_init(void)
{
+ const struct file_operations *fops = &sq_fops;
#ifndef MODULE
int sq_unit;
#endif
#ifdef HAS_RECORD
if (dmasound.mach.record)
- sq_fops.read = sq_read ;
+ fops = &sq_fops_record;
#endif
- sq_unit = register_sound_dsp(&sq_fops, -1);
+ sq_unit = register_sound_dsp(fops, -1);
if (sq_unit < 0) {
printk(KERN_ERR "dmasound_core: couldn't register fops\n") ;
return sq_unit ;
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/13] appldata build fix
PGALLOC_DMA is defined only if we have CONFIG_ZONE_DMA Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- arch/s390/appldata/appldata_mem.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/s390/appldata/appldata_mem.c b/arch/s390/appldata/appldata_mem.c index 4ca6157..697eb30 100644 --- a/arch/s390/appldata/appldata_mem.c +++ b/arch/s390/appldata/appldata_mem.c @@ -117,7 +117,10 @@ static void appldata_get_mem_data(void *data) mem_data->pgpgout= ev[PGPGOUT] >> 1; mem_data->pswpin = ev[PSWPIN]; mem_data->pswpout= ev[PSWPOUT]; - mem_data->pgalloc= ev[PGALLOC_NORMAL] + ev[PGALLOC_DMA]; + mem_data->pgalloc= ev[PGALLOC_NORMAL]; +#ifdef CONFIG_ZONE_DMA + mem_data->pgalloc+= ev[PGALLOC_DMA]; +#endif mem_data->pgfault= ev[PGFAULT]; mem_data->pgmajfault = ev[PGMAJFAULT]; -- 1.5.0-rc2.GIT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 5/13] zatm __init abuse
zatm_init() and zatm_start() should be __devinit (the former is
not module init, despite the name - it's a helper for PCI ->probe())
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/atm/zatm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/atm/zatm.c b/drivers/atm/zatm.c
index 0d7091e..2ad2527 100644
--- a/drivers/atm/zatm.c
+++ b/drivers/atm/zatm.c
@@ -1177,7 +1177,7 @@ static void __devinit eprom_get_esi(struct atm_dev *dev)
/*- entries -*/
-static int __init zatm_init(struct atm_dev *dev)
+static int __devinit zatm_init(struct atm_dev *dev)
{
struct zatm_dev *zatm_dev;
struct pci_dev *pci_dev;
@@ -1256,7 +1256,7 @@ static int __init zatm_init(struct atm_dev *dev)
}
-static int __init zatm_start(struct atm_dev *dev)
+static int __devinit zatm_start(struct atm_dev *dev)
{
struct zatm_dev *zatm_dev = ZATM_DEV(dev);
struct pci_dev *pdev = zatm_dev->pci_dev;
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 4/13] (uml) sparse flags for userland glue are missing $(CF)
Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- arch/um/scripts/Makefile.rules |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/um/scripts/Makefile.rules b/arch/um/scripts/Makefile.rules index 813077f..a9a4b85 100644 --- a/arch/um/scripts/Makefile.rules +++ b/arch/um/scripts/Makefile.rules @@ -10,7 +10,7 @@ USER_OBJS := $(foreach file,$(USER_OBJS),$(obj)/$(file)) $(USER_OBJS:.o=.%): \ c_flags = -Wp,-MD,$(depfile) $(USER_CFLAGS) $(CFLAGS_$(basetarget).o) $(USER_OBJS) : CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ \ - -Dunix -D__unix__ -D__$(SUBARCH)__ + -Dunix -D__unix__ -D__$(SUBARCH)__ $(CF) # These are like USER_OBJS but filter USER_CFLAGS through unprofile instead of # using it directly. @@ -19,7 +19,7 @@ UNPROFILE_OBJS := $(foreach file,$(UNPROFILE_OBJS),$(obj)/$(file)) $(UNPROFILE_OBJS:.o=.%): \ c_flags = -Wp,-MD,$(depfile) $(call unprofile,$(USER_CFLAGS)) $(CFLAGS_$(basetarget).o) $(UNPROFILE_OBJS) : CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ \ - -Dunix -D__unix__ -D__$(SUBARCH)__ + -Dunix -D__unix__ -D__$(SUBARCH)__ $(CF) # The stubs and unmap.o can't try to call mcount or update basic block data define unprofile -- 1.5.0-rc2.GIT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TESTED] tdfx framebuffer garbles display in 2.6.19.5
Hi Antonino :) NEW INFORMATION ABOUT THE PROBLEM * Antonino A. Daplas <[EMAIL PROTECTED]> dixit: > On Tue, 2007-03-06 at 07:25 +0100, DervishD wrote: > > > > With the patch, the scroll slows to a crawl and the system is > > > > unusable. The time to scroll 30 lines is about a minute or so > > > > (probably more, I just measured for a while). > > > > > > > > If you want me to test other patches, just tell :) > > > > > > Can you change the mdelay to udelay and use higher/lower delay values > > > to see if there's any improvement? > > > > Yes, as soon as I can build a new kernel and reboot. Any suggested > > value? > > You can start with 5 and increment by 5. So you need not reboot each > time, compile tdfxfb as a module, and set CONFIG_HW_CONSOLE_BINDING=y > (under drivers->char). Until I discovered how to reproduce the bug, I had to reboot for each test. But I discovered the real problem... The garbling doesn't happen, no matter the udelay, until I start X. Once X is started, even with an udelay(100) (which for me makes the display untolerably slow) the problem happens. This doesn't happen in latest 2.4.x, but I remember that some characters "dissappeared" from the screen at some 2.4.x when X was running. That was a known bug in the X driver of this card, so I'm not sure if the last X.Org driver has this problem or not. Unfortunately, I cannot test this directly, the most I can do is to test under Ubuntu, which uses an older 2.6.x kernel. If this new discovery doesn't ring any bell for you, I'll make a test under Ubuntu and after that I'll just wait until I can upgrade X (which I cannot do now) to latest X.Org (I'm now using 7.0.22). Thanks for all your help. I'll keep you informed of any change I notice, and (although I won't be very fast doing it...) you can count on me to test any patch you want. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/13] zatm __init abuse
Al Viro wrote: zatm_init() and zatm_start() should be __devinit (the former is not module init, despite the name - it's a helper for PCI ->probe()) Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- drivers/atm/zatm.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) ACK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/13] ibmtr probe is __devinit, not __init
Al Viro wrote: used by ->attach() in pcmcia analog Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- drivers/net/pcmcia/ibmtr_cs.c |4 ++-- drivers/net/tokenring/ibmtr.c |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) ACK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel BUG at mm/slab.c:610
Hello everybody. Sorry for posting to this list, but I'm pretty lost. I'm experimenting this kernel panic on 3 different slackware linux boxes. The harware is the same, and also the .config with vanilla 2.6.20 I don't think this is related to buggy hardware because it is happening on 3 different boxes with the same hardware config. Unfortunately the bug isn't reproducible but it is happening at least once a week. May anoybody point me the step to try to spot this bug? TIA ksymoops 2.4.10 on i686 2.6.20. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.6.20/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Error (regular_file): read_ksyms stat /proc/ksyms failed ksymoops: No such file or directory No modules in ksyms, skipping objects No ksyms, skipping lsmod Mar 14 03:42:25 Mimosa kernel: kernel BUG at mm/slab.c:610! Mar 14 03:42:25 Mimosa kernel: CPU:0 Mar 14 03:42:25 Mimosa kernel: EIP:0060:[] Not tainted VLI Using defaults from ksymoops -t elf32-i386 -a i386 Mar 14 03:42:25 Mimosa kernel: EFLAGS: 00010046 (2.6.20 #1) Mar 14 03:42:25 Mimosa kernel: eax: 0008 ebx: c100 ecx: c0e7d4e0 edx: c101cfa0 Mar 14 03:42:25 Mimosa kernel: esi: c121 edi: c1176560 ebp: esp: c119bef0 Mar 14 03:42:25 Mimosa kernel: ds: 007b es: 007b ss: 0068 Mar 14 03:42:25 Mimosa kernel: Stack: c1213a10 161c9ed5 c1210010 c1210010 c121 161c9ed5 c1176560 c014d201 Mar 14 03:42:25 Mimosa kernel: c1180420 c1176560 c1180d60 c014d220 c014d26b Mar 14 03:42:25 Mimosa kernel:c03b7ae0 c03b7ae0 0282 c0123d37 c118f13c 007b 508b Mar 14 03:42:25 Mimosa kernel: Call Trace: Mar 14 03:42:25 Mimosa kernel: [] drain_array+0x91/0xb0 Mar 14 03:42:25 Mimosa kernel: [] cache_reap+0x0/0xf0 Mar 14 03:42:25 Mimosa kernel: [] cache_reap+0x4b/0xf0 Mar 14 03:42:25 Mimosa kernel: [] run_workqueue+0x67/0x130 Mar 14 03:42:25 Mimosa kernel: [] worker_thread+0x13a/0x170 Mar 14 03:42:25 Mimosa kernel: [] default_wake_function+0x0/0x10 Mar 14 03:42:25 Mimosa kernel: [] __wake_up_common+0x37/0x70 Mar 14 03:42:25 Mimosa kernel: [] default_wake_function+0x0/0x10 Mar 14 03:42:25 Mimosa kernel: [] worker_thread+0x0/0x170 Mar 14 03:42:25 Mimosa kernel: [] kthread+0xb6/0xc0 Mar 14 03:42:25 Mimosa kernel: [] kthread+0x0/0xc0 Mar 14 03:42:25 Mimosa kernel: [] kernel_thread_helper+0x7/0x14 Mar 14 03:42:25 Mimosa kernel: Code: ff 83 c4 0c 5b 5e 5f 5d c3 8b 57 20 29 d0 89 da 89 46 18 89 f8 e8 78 f1 ff ff eb da 89 33 8b 46 04 89 5e 04 89 18 89 43 04 eb cb <0f> 0b 90 8d 74 26 00 eb fe 8b 52 0c e9 57 ff ff ff 8d b6 00 00 >>EIP; c014ca99<= >>ebx; c100 >>ecx; c0e7d4e0 >>edx; c101cfa0 >>esi; c121 >>edi; c1176560 >>esp; c119bef0 Trace; c014d201 Trace; c014d220 Trace; c014d26b Trace; c0123d37 Trace; c0123f3a Trace; c01123e0 Trace; c0112427 <__wake_up_common+37/70> Trace; c01123e0 Trace; c0123e00 Trace; c01271a6 Trace; c01270f0 Trace; c01036a3 This architecture has variable length instructions, decoding before eip is unreliable, take these instructions with a pinch of salt. Code; c014ca6e <_EIP>: Code; c014ca6e 0: ff 83 c4 0c 5b 5e incl 0x5e5b0cc4(%ebx) Code; c014ca74 6: 5fpop%edi Code; c014ca75 7: 5dpop%ebp Code; c014ca76 8: c3ret Code; c014ca77 9: 8b 57 20 mov0x20(%edi),%edx Code; c014ca7a c: 29 d0 sub%edx,%eax Code; c014ca7c e: 89 da mov%ebx,%edx Code; c014ca7e 10: 89 46 18 mov%eax,0x18(%esi) Code; c014ca81 13: 89 f8 mov%edi,%eax Code; c014ca83 15: e8 78 f1 ff ffcall f192 <_EIP+0xf192> Code; c014ca88 1a: eb da jmpfff6 <_EIP+0xfff6> Code; c014ca8a 1c: 89 33 mov%esi,(%ebx) Code; c014ca8c 1e: 8b 46 04 mov0x4(%esi),%eax Code; c014ca8f 21: 89 5e 04 mov%ebx,0x4(%esi) Code; c014ca92 24: 89 18 mov%ebx,(%eax) Code; c014ca94 26: 89 43 04 mov%eax,0x4(%ebx) Code; c014ca97 29: eb cb jmpfff6 <_EIP+0xfff6> This decode from eip onwards should be reliable Code; c014ca99 <_EIP>: Code; c014ca99<= 0:
Re: [PATCH] [RSDL-0.30] sched: rsdl improve latencies with differential nice
On Wed, 2007-03-14 at 02:31 +1100, Con Kolivas wrote: > Can you try the attached patch please Al and Mike? It "dithers" the priority > bitmap which tends to fluctuate the latency a lot more but in a cyclical > fashion. This tends to make the max latency bound to a smaller value and > should make it possible to run -nice tasks without killing the latency of the > non niced tasks. Eg you could possibly run X nice -10 at a guess like we used > to in 2.4 days. It's not essential of course, but is a workaround for Mike's > testcase. > Oh my. I thought I was all done staring mindlessly at gforce (chinese water torture). Oh well, a few more brain cells dying of boredom won't kill me I guess ;-) Will give it a shot. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 6/13] stacktrace doesn't work on uml
and no, it's not the case of "let's pull bits from underlying architecture" Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- arch/um/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/um/Kconfig b/arch/um/Kconfig index b3a21ba..354cc6b 100644 --- a/arch/um/Kconfig +++ b/arch/um/Kconfig @@ -44,7 +44,7 @@ config LOCKDEP_SUPPORT config STACKTRACE_SUPPORT bool - default y + default n config GENERIC_CALIBRATE_DELAY bool -- 1.5.0-rc2.GIT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 7/13] fix ipath_dma_free_coherent() prototype
method gets u64, not dma_addr_t
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ipath/ipath_dma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/ipath/ipath_dma.c
b/drivers/infiniband/hw/ipath/ipath_dma.c
index f6f9490..f87f003 100644
--- a/drivers/infiniband/hw/ipath/ipath_dma.c
+++ b/drivers/infiniband/hw/ipath/ipath_dma.c
@@ -167,7 +167,7 @@ static void *ipath_dma_alloc_coherent(struct ib_device
*dev, size_t size,
}
static void ipath_dma_free_coherent(struct ib_device *dev, size_t size,
- void *cpu_addr, dma_addr_t dma_handle)
+ void *cpu_addr, u64 dma_handle)
{
free_pages((unsigned long) cpu_addr, get_order(size));
}
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 8/13] m32r dma-mapping.h should simply include generic/dma-mapping-broken.h
... instead of trying to duplicate its bits
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
include/asm-m32r/dma-mapping.h | 19 +--
1 files changed, 1 insertions(+), 18 deletions(-)
diff --git a/include/asm-m32r/dma-mapping.h b/include/asm-m32r/dma-mapping.h
index a7fa030..f9b58eb 100644
--- a/include/asm-m32r/dma-mapping.h
+++ b/include/asm-m32r/dma-mapping.h
@@ -1,23 +1,6 @@
#ifndef _ASM_M32R_DMA_MAPPING_H
#define _ASM_M32R_DMA_MAPPING_H
-/*
- * NOTE: Do not include
- * Because it requires PCI stuffs, but current M32R don't provide these.
- */
-
-static inline void *
-dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_handle,
- gfp_t flag)
-{
- return (void *)NULL;
-}
-
-static inline void
-dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
- dma_addr_t dma_handle)
-{
- return;
-}
+#include
#endif /* _ASM_M32R_DMA_MAPPING_H */
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 10/13] BLK_DEV_IDE_CELLEB dependency fix
It's bool and it depends on IDE => should depend on IDE=y Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- drivers/ide/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig index 5d134bb..3f76987 100644 --- a/drivers/ide/Kconfig +++ b/drivers/ide/Kconfig @@ -802,7 +802,7 @@ config BLK_DEV_IDEDMA_PMAC config BLK_DEV_IDE_CELLEB bool "Toshiba's Cell Reference Set IDE support" - depends on PPC_CELLEB + depends on PPC_CELLEB && IDE=y help This driver provides support for the built-in IDE controller on Toshiba Cell Reference Board. -- 1.5.0-rc2.GIT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 9/13] include of asm/pgtable.h in nfsfh is bogus
not needed and actually breaks build on frv, while we are at it Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- fs/nfsd/nfsfh.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c index c2660cb..8d995bc 100644 --- a/fs/nfsd/nfsfh.c +++ b/fs/nfsd/nfsfh.c @@ -17,7 +17,6 @@ #include #include #include -#include #include #include -- 1.5.0-rc2.GIT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 11/13] sparc: have dma-mapping.h include generic/dma-mapping-broken in non-PCI case
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
include/asm-sparc/dma-mapping.h | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/include/asm-sparc/dma-mapping.h b/include/asm-sparc/dma-mapping.h
index 6db83dc..f3a641e 100644
--- a/include/asm-sparc/dma-mapping.h
+++ b/include/asm-sparc/dma-mapping.h
@@ -5,20 +5,7 @@
#ifdef CONFIG_PCI
#include
#else
-
-static inline void *dma_alloc_coherent(struct device *dev, size_t size,
-dma_addr_t *dma_handle, gfp_t flag)
-{
- BUG();
- return NULL;
-}
-
-static inline void dma_free_coherent(struct device *dev, size_t size,
- void *vaddr, dma_addr_t dma_handle)
-{
- BUG();
-}
-
+#include
#endif /* PCI */
#endif /* _ASM_SPARC_DMA_MAPPING_H */
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 12/13] rtc-cmos needs RTC_ALWAYS_BCD known
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
include/asm-m68k/mc146818rtc.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/asm-m68k/mc146818rtc.h b/include/asm-m68k/mc146818rtc.h
index 11fe12d..9f70a01 100644
--- a/include/asm-m68k/mc146818rtc.h
+++ b/include/asm-m68k/mc146818rtc.h
@@ -11,6 +11,7 @@
#include
#define RTC_PORT(x)(TT_RTC_BAS + 2*(x))
+#define RTC_ALWAYS_BCD 0
#define CMOS_READ(addr) ({ \
atari_outb_p((addr),RTC_PORT(0)); \
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 13/13] fix ps3fb glue allowing a modular build
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/ps3/htab.c |2 ++
drivers/video/Kconfig |2 +-
include/asm-powerpc/ps3fb.h |5 -
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/htab.c
b/arch/powerpc/platforms/ps3/htab.c
index e12e59f..67d6f58 100644
--- a/arch/powerpc/platforms/ps3/htab.c
+++ b/arch/powerpc/platforms/ps3/htab.c
@@ -235,7 +235,9 @@ static void ps3_hpte_invalidate(unsigned long slot,
unsigned long va,
static void ps3_hpte_clear(void)
{
/* Make sure to clean up the frame buffer device first */
+#ifdef CONFIG_PS3_FB
ps3fb_cleanup();
+#endif
lv1_unmap_htab(htab_addr);
}
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 7f5a598..ab43a32 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1615,7 +1615,7 @@ config FB_IBM_GXT4500
adaptor, found on some IBM System P (pSeries) machines.
config FB_PS3
- bool "PS3 GPU framebuffer driver"
+ tristate "PS3 GPU framebuffer driver"
depends on FB && PS3_PS3AV
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
diff --git a/include/asm-powerpc/ps3fb.h b/include/asm-powerpc/ps3fb.h
index ad81cf4..a447387 100644
--- a/include/asm-powerpc/ps3fb.h
+++ b/include/asm-powerpc/ps3fb.h
@@ -43,13 +43,8 @@ struct ps3fb_ioctl_res {
#ifdef __KERNEL__
-#ifdef CONFIG_FB_PS3
extern void ps3fb_flip_ctl(int on);
extern void ps3fb_cleanup(void);
-#else
-static inline void ps3fb_flip_ctl(int on) {}
-static inline void ps3fb_cleanup(void) {}
-#endif
#endif /* __KERNEL__ */
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/17] misc NULL noise
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/vsyscall.c |2 +-
drivers/acpi/events/evmisc.c |2 +-
drivers/ata/pata_mpc52xx.c |2 +-
drivers/char/watchdog/machzwd.c|2 +-
drivers/media/video/pvrusb2/pvrusb2-hdw.c |6 +++---
drivers/media/video/pvrusb2/pvrusb2-v4l2.c |6 +++---
drivers/ps3/vuart.c|4 ++--
drivers/video/backlight/progear_bl.c |4 ++--
8 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/x86_64/kernel/vsyscall.c b/arch/x86_64/kernel/vsyscall.c
index 180ff91..b43c698 100644
--- a/arch/x86_64/kernel/vsyscall.c
+++ b/arch/x86_64/kernel/vsyscall.c
@@ -112,7 +112,7 @@ static __always_inline void do_vgettimeofday(struct timeval
* tv)
vread = __vsyscall_gtod_data.clock.vread;
if (unlikely(!__vsyscall_gtod_data.sysctl_enabled || !vread)) {
- gettimeofday(tv,0);
+ gettimeofday(tv,NULL);
return;
}
now = vread();
diff --git a/drivers/acpi/events/evmisc.c b/drivers/acpi/events/evmisc.c
index 8dcade6..3a799b9 100644
--- a/drivers/acpi/events/evmisc.c
+++ b/drivers/acpi/events/evmisc.c
@@ -549,7 +549,7 @@ acpi_status acpi_ev_release_global_lock(void)
acpi_gbl_global_lock_acquired = FALSE;
/* Release the local GL mutex */
- acpi_ev_global_lock_thread_id = 0;
+ acpi_ev_global_lock_thread_id = NULL;
acpi_ev_global_lock_acquired = 0;
acpi_os_release_mutex(acpi_gbl_global_lock_mutex);
return_ACPI_STATUS(status);
diff --git a/drivers/ata/pata_mpc52xx.c b/drivers/ata/pata_mpc52xx.c
index f5d8872..882c36e 100644
--- a/drivers/ata/pata_mpc52xx.c
+++ b/drivers/ata/pata_mpc52xx.c
@@ -329,7 +329,7 @@ mpc52xx_ata_init_one(struct device *dev, struct
mpc52xx_ata_priv *priv)
ae->dev = dev;
ae->irq = priv->ata_irq;
- aio->cmd_addr = 0;/* Don't have a classic reg block */
+ aio->cmd_addr = NULL; /* Don't have a classic reg block */
aio->altstatus_addr = &priv->ata_regs->tf_control;
aio->ctl_addr = &priv->ata_regs->tf_control;
aio->data_addr = &priv->ata_regs->tf_data;
diff --git a/drivers/char/watchdog/machzwd.c b/drivers/char/watchdog/machzwd.c
index 4a328ba..81fb3de 100644
--- a/drivers/char/watchdog/machzwd.c
+++ b/drivers/char/watchdog/machzwd.c
@@ -324,7 +324,7 @@ static int zf_ioctl(struct inode *inode, struct file *file,
unsigned int cmd,
return put_user(0, p);
case WDIOC_KEEPALIVE:
- zf_ping(0);
+ zf_ping(NULL);
break;
default:
diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
index 1ff5138..9916cf3 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
@@ -1248,10 +1248,10 @@ int pvr2_upload_firmware2(struct pvr2_hdw *hdw)
ret |= pvr2_write_register(hdw, 0xaa18, 0x0084); /*unknown*/
LOCK_TAKE(hdw->ctl_lock); do {
hdw->cmd_buffer[0] = FX2CMD_FWPOST1;
- ret |= pvr2_send_request(hdw,hdw->cmd_buffer,1,0,0);
+ ret |= pvr2_send_request(hdw,hdw->cmd_buffer,1,NULL,0);
hdw->cmd_buffer[0] = FX2CMD_MEMSEL;
hdw->cmd_buffer[1] = 0;
- ret |= pvr2_send_request(hdw,hdw->cmd_buffer,2,0,0);
+ ret |= pvr2_send_request(hdw,hdw->cmd_buffer,2,NULL,0);
} while (0); LOCK_GIVE(hdw->ctl_lock);
if (ret) {
@@ -1320,7 +1320,7 @@ int pvr2_upload_firmware2(struct pvr2_hdw *hdw)
LOCK_TAKE(hdw->ctl_lock); do {
hdw->cmd_buffer[0] = FX2CMD_MEMSEL;
hdw->cmd_buffer[1] = 0;
- ret |= pvr2_send_request(hdw,hdw->cmd_buffer,2,0,0);
+ ret |= pvr2_send_request(hdw,hdw->cmd_buffer,2,NULL,0);
} while (0); LOCK_GIVE(hdw->ctl_lock);
if (ret) {
diff --git a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
index 5313d34..25d3830 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-v4l2.c
@@ -808,11 +808,11 @@ static void pvr2_v4l2_destroy_no_lock(struct pvr2_v4l2
*vp)
{
if (vp->dev_video) {
pvr2_v4l2_dev_destroy(vp->dev_video);
- vp->dev_video = 0;
+ vp->dev_video = NULL;
}
if (vp->dev_radio) {
pvr2_v4l2_dev_destroy(vp->dev_radio);
- vp->dev_radio = 0;
+ vp->dev_radio = NULL;
}
pvr2_trace(PVR2_TRACE_STRUCT,"Destroying pvr2_v4l2 id=%p",vp);
@@ -1138,7 +1138,7 @@ static void pvr2_v4l2_dev_init(struct pvr2_v4l2_dev *dip,
{
int mindevnum;
int unit_numb
[PATCH 4/17] constant should be long
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/udbg_16550.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/udbg_16550.c b/arch/powerpc/kernel/udbg_16550.c
index e738f93..a963f65 100644
--- a/arch/powerpc/kernel/udbg_16550.c
+++ b/arch/powerpc/kernel/udbg_16550.c
@@ -184,7 +184,7 @@ void udbg_pas_real_putc(char c)
void udbg_init_pas_realmode(void)
{
- udbg_comport = (volatile struct NS16550 __iomem *)0xfcff03f8;
+ udbg_comport = (volatile struct NS16550 __iomem *)0xfcff03f8UL;
udbg_putc = udbg_pas_real_putc;
udbg_getc = NULL;
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/17] fastcall still doesn't make sense in paravirt
Andi had removed a bunch of those, but one more had creeped in... Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- include/asm-i386/paravirt.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-i386/paravirt.h b/include/asm-i386/paravirt.h index f8319ca..46dc34c 100644 --- a/include/asm-i386/paravirt.h +++ b/include/asm-i386/paravirt.h @@ -130,7 +130,7 @@ struct paravirt_ops void (*flush_tlb_kernel)(void); void (*flush_tlb_single)(u32 addr); - void (fastcall *map_pt_hook)(int type, pte_t *va, u32 pfn); + void (*map_pt_hook)(int type, pte_t *va, u32 pfn); void (*alloc_pt)(u32 pfn); void (*alloc_pd)(u32 pfn); -- 1.5.0-rc2.GIT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/17] dmfe trivial endianness annotations
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/net/tulip/dmfe.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tulip/dmfe.c b/drivers/net/tulip/dmfe.c
index 24a29c9..9aeac76 100644
--- a/drivers/net/tulip/dmfe.c
+++ b/drivers/net/tulip/dmfe.c
@@ -190,13 +190,13 @@
/* Structure/enum declaration --- */
struct tx_desc {
-u32 tdes0, tdes1, tdes2, tdes3; /* Data for the card */
+__le32 tdes0, tdes1, tdes2, tdes3; /* Data for the card */
char *tx_buf_ptr; /* Data for us */
struct tx_desc *next_tx_desc;
} __attribute__(( aligned(32) ));
struct rx_desc {
- u32 rdes0, rdes1, rdes2, rdes3; /* Data for the card */
+ __le32 rdes0, rdes1, rdes2, rdes3; /* Data for the card */
struct sk_buff *rx_skb_ptr; /* Data for us */
struct rx_desc *next_rx_desc;
} __attribute__(( aligned(32) ));
@@ -458,7 +458,7 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,
/* read 64 word srom data */
for (i = 0; i < 64; i++)
- ((u16 *) db->srom)[i] =
+ ((__le16 *) db->srom)[i] =
cpu_to_le16(read_srom_word(db->ioaddr, i));
/* Set Node address */
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 5/17] pasemi trivial iomem annotations
Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- arch/powerpc/platforms/pasemi/iommu.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/platforms/pasemi/iommu.c b/arch/powerpc/platforms/pasemi/iommu.c index 459a53b..71dbf1a 100644 --- a/arch/powerpc/platforms/pasemi/iommu.c +++ b/arch/powerpc/platforms/pasemi/iommu.c @@ -77,7 +77,7 @@ #define IOBMAP_L2E_V 0x8000 #define IOBMAP_L2E_V_CACHED0xc000 -static u32 *iob; +static u32 __iomem *iob; static u32 iob_l1_emptyval; static u32 iob_l2_emptyval; static u32 *iob_l2_base; -- 1.5.0-rc2.GIT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 7/17] trivial ATA iomem annotations
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/ata/pata_cs5520.c |2 +-
drivers/ata/sata_sis.c|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/pata_cs5520.c b/drivers/ata/pata_cs5520.c
index 7ef8342..55cc293 100644
--- a/drivers/ata/pata_cs5520.c
+++ b/drivers/ata/pata_cs5520.c
@@ -208,7 +208,7 @@ static struct ata_port_operations cs5520_port_ops = {
static int __devinit cs5520_init_one(struct pci_dev *dev, const struct
pci_device_id *id)
{
u8 pcicfg;
- void *iomap[5];
+ void __iomem *iomap[5];
static struct ata_probe_ent probe[2];
int ports = 0;
diff --git a/drivers/ata/sata_sis.c b/drivers/ata/sata_sis.c
index 1879e0c..a787f0d 100644
--- a/drivers/ata/sata_sis.c
+++ b/drivers/ata/sata_sis.c
@@ -354,7 +354,7 @@ static int sis_init_one (struct pci_dev *pdev, const struct
pci_device_id *ent)
return -ENOMEM;
if (!(probe_ent->port_flags & SIS_FLAG_CFGSCR)) {
- void *mmio;
+ void __iomem *mmio;
mmio = pcim_iomap(pdev, SIS_SCR_PCI_BAR, 0);
if (!mmio)
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 8/17] cciss endian annotations
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/block/cciss.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 0c716ee..072e18e 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -1439,7 +1439,7 @@ static int rebuild_lun_table(ctlr_info_t *h, struct
gendisk *del_disk)
if (return_code == IO_OK) {
listlength =
- be32_to_cpu(*(__u32 *) ld_buff->LUNListLength);
+ be32_to_cpu(*(__be32 *) ld_buff->LUNListLength);
} else {/* reading number of logical volumes failed */
printk(KERN_WARNING "cciss: report logical volume"
" command failed\n");
@@ -1961,8 +1961,8 @@ cciss_read_capacity(int ctlr, int logvol, int withirq,
sector_t *total_size,
ctlr, buf, sizeof(ReadCapdata_struct),
1, logvol, 0, NULL, TYPE_CMD);
if (return_code == IO_OK) {
- *total_size = be32_to_cpu(*(__u32 *) buf->total_size);
- *block_size = be32_to_cpu(*(__u32 *) buf->block_size);
+ *total_size = be32_to_cpu(*(__be32 *) buf->total_size);
+ *block_size = be32_to_cpu(*(__be32 *) buf->block_size);
} else {/* read capacity command failed */
printk(KERN_WARNING "cciss: read capacity failed\n");
*total_size = 0;
@@ -1997,8 +1997,8 @@ cciss_read_capacity_16(int ctlr, int logvol, int withirq,
sector_t *total_size,
1, logvol, 0, NULL, TYPE_CMD);
}
if (return_code == IO_OK) {
- *total_size = be64_to_cpu(*(__u64 *) buf->total_size);
- *block_size = be32_to_cpu(*(__u32 *) buf->block_size);
+ *total_size = be64_to_cpu(*(__be64 *) buf->total_size);
+ *block_size = be32_to_cpu(*(__be32 *) buf->block_size);
} else {/* read capacity command failed */
printk(KERN_WARNING "cciss: read capacity failed\n");
*total_size = 0;
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 9/17] qeth gfp_t annotations
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/s390/net/qeth.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/s390/net/qeth.h b/drivers/s390/net/qeth.h
index e95c281..84b108d 100644
--- a/drivers/s390/net/qeth.h
+++ b/drivers/s390/net/qeth.h
@@ -873,7 +873,7 @@ qeth_realloc_headroom(struct qeth_card *card, struct
sk_buff *skb, int size)
}
static inline struct sk_buff *
-qeth_pskb_unshare(struct sk_buff *skb, int pri)
+qeth_pskb_unshare(struct sk_buff *skb, gfp_t pri)
{
struct sk_buff *nskb;
if (!skb_cloned(skb))
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 14/17] atl1 trivial endianness misannotations
NB: driver is choke-full of code that will break on big-endian; as long
as the hardware is onboard-only we can live with that, but sooner or
later that'll need fixing.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1_main.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index 88d4f70..dee3638 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -1328,7 +1328,7 @@ static int atl1_tx_csum(struct atl1_adapter *adapter,
struct sk_buff *skb,
if (likely(skb->ip_summed == CHECKSUM_PARTIAL)) {
cso = skb->h.raw - skb->data;
- css = (skb->h.raw + skb->csum) - skb->data;
+ css = (skb->h.raw + skb->csum_offset) - skb->data;
if (unlikely(cso & 0x1)) {
printk(KERN_DEBUG "%s: payload offset != even number\n",
atl1_driver_name);
@@ -1562,7 +1562,7 @@ static int atl1_xmit_frame(struct sk_buff *skb, struct
net_device *netdev)
/* mss will be nonzero if we're doing segment offload (TSO/GSO) */
mss = skb_shinfo(skb)->gso_size;
if (mss) {
- if (skb->protocol == ntohs(ETH_P_IP)) {
+ if (skb->protocol == htons(ETH_P_IP)) {
proto_hdr_len = ((skb->h.raw - skb->data) +
(skb->h.th->doff << 2));
if (unlikely(proto_hdr_len > len)) {
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 12/17] hid-core endianness annotations
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/hid/hid-core.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index f4ee1af..9c8157f 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -753,8 +753,7 @@ static __inline__ __u32 extract(__u8 *report, unsigned
offset, unsigned n)
report += offset >> 3; /* adjust byte index */
offset &= 7;/* now only need bit offset into one byte */
- x = get_unaligned((u64 *) report);
- x = le64_to_cpu(x);
+ x = le64_to_cpu(get_unaligned((__le64 *) report));
x = (x >> offset) & ((1ULL << n) - 1); /* extract bit field */
return (u32) x;
}
@@ -769,7 +768,7 @@ static __inline__ __u32 extract(__u8 *report, unsigned
offset, unsigned n)
*/
static __inline__ void implement(__u8 *report, unsigned offset, unsigned n,
__u32 value)
{
- u64 x;
+ __le64 x;
u64 m = (1ULL << n) - 1;
WARN_ON(n > 32);
@@ -780,10 +779,10 @@ static __inline__ void implement(__u8 *report, unsigned
offset, unsigned n, __u3
report += offset >> 3;
offset &= 7;
- x = get_unaligned((u64 *)report);
+ x = get_unaligned((__le64 *)report);
x &= cpu_to_le64(~(m << offset));
x |= cpu_to_le64(((u64) value) << offset);
- put_unaligned(x, (u64 *) report);
+ put_unaligned(x, (__le64 *) report);
}
/*
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 13/17] ANSIfy powerpc floppy.h
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
include/asm-powerpc/floppy.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-powerpc/floppy.h b/include/asm-powerpc/floppy.h
index a0f14ee..afa700d 100644
--- a/include/asm-powerpc/floppy.h
+++ b/include/asm-powerpc/floppy.h
@@ -178,7 +178,7 @@ static struct fd_dma_ops virt_dma_ops =
._dma_setup = vdma_dma_setup
};
-static int fd_request_dma()
+static int fd_request_dma(void)
{
if (can_use_virtual_dma & 1) {
fd_ops = &virt_dma_ops;
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 17/17] m68k dma-mapping: gfp_t annotations
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
include/asm-m68k/dma-mapping.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-m68k/dma-mapping.h b/include/asm-m68k/dma-mapping.h
index 00259ed..a26cdeb 100644
--- a/include/asm-m68k/dma-mapping.h
+++ b/include/asm-m68k/dma-mapping.h
@@ -32,7 +32,7 @@ extern void dma_free_coherent(struct device *, size_t,
void *, dma_addr_t);
static inline void *dma_alloc_noncoherent(struct device *dev, size_t size,
- dma_addr_t *handle, int flag)
+ dma_addr_t *handle, gfp_t flag)
{
return dma_alloc_coherent(dev, size, handle, flag);
}
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 16/17] paride endianness annotations
Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- drivers/block/paride/pd.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/block/paride/pd.c b/drivers/block/paride/pd.c index 99e2c8c..31e0148 100644 --- a/drivers/block/paride/pd.c +++ b/drivers/block/paride/pd.c @@ -663,11 +663,11 @@ static enum action pd_identify(struct pd_unit *disk) return Fail; pi_read_block(disk->pi, pd_scratch, 512); disk->can_lba = pd_scratch[99] & 2; - disk->sectors = le16_to_cpu(*(u16 *) (pd_scratch + 12)); - disk->heads = le16_to_cpu(*(u16 *) (pd_scratch + 6)); - disk->cylinders = le16_to_cpu(*(u16 *) (pd_scratch + 2)); + disk->sectors = le16_to_cpu(*(__le16 *) (pd_scratch + 12)); + disk->heads = le16_to_cpu(*(__le16 *) (pd_scratch + 6)); + disk->cylinders = le16_to_cpu(*(__le16 *) (pd_scratch + 2)); if (disk->can_lba) - disk->capacity = le32_to_cpu(*(u32 *) (pd_scratch + 120)); + disk->capacity = le32_to_cpu(*(__le32 *) (pd_scratch + 120)); else disk->capacity = disk->sectors * disk->heads * disk->cylinders; -- 1.5.0-rc2.GIT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ahci.c: fix ati sb600 sata IRQ_TF_ERR
When there is no media in SATA CD/DVD drive or media is not ready,
AHCI controller fails to execute the ATAPI commands TEST_UNIT_READY,
READ_CAPACITY or READ_TOC and reports PORT_IRQ_TF_ERR. But ATI SB600
SATA controller sets SERR_INTERNAL bit in the error register at the
same time, which is not necessary. This patch is just to ignore the
INTERNAL ERROR in such case. Without this patch, ahci error handler
will report many errors as below:
--- cut from dmesg ---
ata9: soft resetting port
ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata9.00: configured for UDMA/33
ata9: EH complete
ata9.00: exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x2
ata9.00: (irq_stat 0x4001)
ata9.00: cmd a0/00:00:00:00:20/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0
res 51/24:03:00:00:20/00:00:00:00:00/a0 Emask 0x40 (internal error)
ata9: soft resetting port
ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata9.00: configured for UDMA/33
ata9: EH complete
ata9.00: exception Emask 0x40 SAct 0x0 SErr 0x800 action 0x2
ata9.00: (irq_stat 0x4001)
ata9.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x43 data 12 in
res 51/24:03:00:00:00/00:00:00:00:00/a0 Emask 0x40 (internal error)
end cut -
Signed-off-by: Conke Hu <[EMAIL PROTECTED]>
--- linux-2.6.21-rc3-git8/drivers/ata/ahci.c.orig 2007-03-25
20:57:31.0 +0800
+++ linux-2.6.21-rc3-git8/drivers/ata/ahci.c2007-03-25 21:03:54.0
+0800
@@ -80,6 +80,7 @@ enum {
board_ahci_pi = 1,
board_ahci_vt8251 = 2,
board_ahci_ign_iferr= 3,
+ board_ahci_ati = 4,
/* global controller registers */
HOST_CAP= 0x00, /* host capabilities */
@@ -168,6 +169,7 @@ enum {
AHCI_FLAG_NO_NCQ= (1 << 24),
AHCI_FLAG_IGN_IRQ_IF_ERR= (1 << 25), /* ignore IRQ_IF_ERR */
AHCI_FLAG_HONOR_PI = (1 << 26), /* honor PORTS_IMPL */
+ AHCI_FLAG_TF_ERR_FIX= (1 << 27), /* ignore INTERNAL ERROR on
IRQ_TF_ERROR */
};
struct ahci_cmd_hdr {
@@ -362,6 +364,16 @@ static const struct ata_port_info ahci_p
.udma_mask = 0x7f, /* udma0-6 ; FIXME */
.port_ops = &ahci_ops,
},
+ /* board_ahci_ati */
+ {
+ .sht= &ahci_sht,
+ .flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
+ ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
+ ATA_FLAG_SKIP_D2H_BSY | AHCI_FLAG_TF_ERR_FIX,
+ .pio_mask = 0x1f, /* pio0-4 */
+ .udma_mask = 0x7f, /* udma0-6 ; FIXME */
+ .port_ops = &ahci_ops,
+ },
};
static const struct pci_device_id ahci_pci_tbl[] = {
@@ -399,7 +411,7 @@ static const struct pci_device_id ahci_p
PCI_CLASS_STORAGE_SATA_AHCI, 0xff, board_ahci_ign_iferr },
/* ATI */
- { PCI_VDEVICE(ATI, 0x4380), board_ahci }, /* ATI SB600 non-raid */
+ { PCI_VDEVICE(ATI, 0x4380), board_ahci_ati }, /* ATI SB600 non-raid */
{ PCI_VDEVICE(ATI, 0x4381), board_ahci }, /* ATI SB600 raid */
/* VIA */
@@ -1063,12 +1075,22 @@ static void ahci_error_intr(struct ata_p
/* analyze @irq_stat */
ata_ehi_push_desc(ehi, "irq_stat 0x%08x", irq_stat);
+ qc = ata_qc_from_tag(ap, ap->active_tag);
+
/* some controllers set IRQ_IF_ERR on device errors, ignore it */
if (ap->flags & AHCI_FLAG_IGN_IRQ_IF_ERR)
irq_stat &= ~PORT_IRQ_IF_ERR;
- if (irq_stat & PORT_IRQ_TF_ERR)
+ if (irq_stat & PORT_IRQ_TF_ERR) {
err_mask |= AC_ERR_DEV;
+
+ /* some controllers set INTERNAL ERROR on ATAPI IRQ_TF_ERROR,
ignore it */
+ if ((serror & SERR_INTERNAL) &&
+(ap->flags & AHCI_FLAG_TF_ERR_FIX) &&
+ qc && qc->dev->class == ATA_DEV_ATAPI) {
+ serror &= ~SERR_INTERNAL;
+ }
+ }
if (irq_stat & (PORT_IRQ_HBUS_ERR | PORT_IRQ_HBUS_DATA_ERR)) {
err_mask |= AC_ERR_HOST_BUS;
@@ -1100,7 +1122,6 @@ static void ahci_error_intr(struct ata_p
ehi->serror |= serror;
ehi->action |= action;
- qc = ata_qc_from_tag(ap, ap->active_tag);
if (qc)
qc->err_mask |= err_mask;
else
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 15/17] kill bogus casts in amd64 uaccess.h
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
include/asm-x86_64/uaccess.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-x86_64/uaccess.h b/include/asm-x86_64/uaccess.h
index 1981f70..9df30b9 100644
--- a/include/asm-x86_64/uaccess.h
+++ b/include/asm-x86_64/uaccess.h
@@ -373,12 +373,12 @@ extern long __copy_user_nocache(void *dst, const void
__user *src, unsigned size
static inline int __copy_from_user_nocache(void *dst, const void __user *src,
unsigned size)
{
might_sleep();
- return __copy_user_nocache(dst, (__force void *)src, size, 1);
+ return __copy_user_nocache(dst, src, size, 1);
}
static inline int __copy_from_user_inatomic_nocache(void *dst, const void
__user *src, unsigned size)
{
- return __copy_user_nocache(dst, (__force void *)src, size, 0);
+ return __copy_user_nocache(dst, src, size, 0);
}
#endif /* __X86_64_UACCESS_H */
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 10/17] C99 initializers, proper use of const in drivers/ps3
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/ps3/ps3av_cmd.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/ps3/ps3av_cmd.c b/drivers/ps3/ps3av_cmd.c
index 21c97c8..bc70e81 100644
--- a/drivers/ps3/ps3av_cmd.c
+++ b/drivers/ps3/ps3av_cmd.c
@@ -485,12 +485,12 @@ static u8 ps3av_cnv_mclk(u32 fs)
static const u32 ps3av_ns_table[][5] = {
/* D1,D2,D3,D4,D5 */
- [PS3AV_CMD_AUDIO_FS_44K-BASE] { 6272, 6272, 17836, 17836, 8918 },
- [PS3AV_CMD_AUDIO_FS_48K-BASE] { 6144, 6144, 11648, 11648, 5824 },
- [PS3AV_CMD_AUDIO_FS_88K-BASE] { 12544, 12544, 35672, 35672, 17836 },
- [PS3AV_CMD_AUDIO_FS_96K-BASE] { 12288, 12288, 23296, 23296, 11648 },
- [PS3AV_CMD_AUDIO_FS_176K-BASE] { 25088, 25088, 71344, 71344, 35672 },
- [PS3AV_CMD_AUDIO_FS_192K-BASE] { 24576, 24576, 46592, 46592, 23296 }
+ [PS3AV_CMD_AUDIO_FS_44K-BASE] = { 6272, 6272, 17836, 17836, 8918 },
+ [PS3AV_CMD_AUDIO_FS_48K-BASE] = { 6144, 6144, 11648, 11648, 5824 },
+ [PS3AV_CMD_AUDIO_FS_88K-BASE] = { 12544, 12544, 35672, 35672, 17836 },
+ [PS3AV_CMD_AUDIO_FS_96K-BASE] = { 12288, 12288, 23296, 23296, 11648 },
+ [PS3AV_CMD_AUDIO_FS_176K-BASE] ={ 25088, 25088, 71344, 71344,
35672 },
+ [PS3AV_CMD_AUDIO_FS_192K-BASE] ={ 24576, 24576, 46592, 46592,
23296 }
};
static void ps3av_cnv_ns(u8 *ns, u32 fs, u32 video_vid)
@@ -543,9 +543,10 @@ static void ps3av_cnv_ns(u8 *ns, u32 fs, u32 video_vid)
#undef BASE
-static u8 ps3av_cnv_enable(u32 source, u8 *enable)
+static u8 ps3av_cnv_enable(u32 source, const u8 *enable)
{
- u8 *p, ret = 0;
+ const u8 *p;
+ u8 ret = 0;
if (source == PS3AV_CMD_AUDIO_SOURCE_SPDIF) {
ret = 0x03;
@@ -559,9 +560,10 @@ static u8 ps3av_cnv_enable(u32 source, u8 *enable)
return ret;
}
-static u8 ps3av_cnv_fifomap(u8 *map)
+static u8 ps3av_cnv_fifomap(const u8 *map)
{
- u8 *p, ret = 0;
+ const u8 *p;
+ u8 ret = 0;
p = map;
ret = p[0] + (p[1] << 2) + (p[2] << 4) + (p[3] << 6);
@@ -615,7 +617,7 @@ static void ps3av_cnv_info(struct ps3av_audio_info_frame
*info,
info->pb5.lsv = mode->audio_downmix_level;
}
-static void ps3av_cnv_chstat(u8 *chstat, u8 *cs_info)
+static void ps3av_cnv_chstat(u8 *chstat, const u8 *cs_info)
{
memcpy(chstat, cs_info, 5);
}
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 11/17] cifs endianness annotations
Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- fs/cifs/cifspdu.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/cifs/cifspdu.h b/fs/cifs/cifspdu.h index 0efdf35..3af7624 100644 --- a/fs/cifs/cifspdu.h +++ b/fs/cifs/cifspdu.h @@ -220,7 +220,7 @@ */ #define CIFS_NO_HANDLE0x -#define NO_CHANGE_64 0xULL +#define NO_CHANGE_64 cpu_to_le64(0xULL) #define NO_CHANGE_32 0xUL /* IPC$ in ASCII */ -- 1.5.0-rc2.GIT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 6/17] sparc: nr_free_pages() is unsigned long
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
arch/sparc/mm/init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/sparc/mm/init.c b/arch/sparc/mm/init.c
index c85ddf3..a532922 100644
--- a/arch/sparc/mm/init.c
+++ b/arch/sparc/mm/init.c
@@ -75,7 +75,7 @@ void show_mem(void)
printk("Free swap: %6ldkB\n",
nr_swap_pages << (PAGE_SHIFT-10));
printk("%ld pages of RAM\n", totalram_pages);
- printk("%d free pages\n", nr_free_pages());
+ printk("%ld free pages\n", nr_free_pages());
#if 0 /* undefined pgtable_cache_size, pgd_cache_size */
printk("%ld pages in page table cache\n",pgtable_cache_size);
#ifndef CONFIG_SMP
--
1.5.0-rc2.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [RSDL-0.30] sched: rsdl improve latencies with differential nice
On Wednesday 14 March 2007 20:13, Mike Galbraith wrote: > On Wed, 2007-03-14 at 02:31 +1100, Con Kolivas wrote: > > Can you try the attached patch please Al and Mike? It "dithers" the > > priority bitmap which tends to fluctuate the latency a lot more but in a > > cyclical fashion. This tends to make the max latency bound to a smaller > > value and should make it possible to run -nice tasks without killing the > > latency of the non niced tasks. Eg you could possibly run X nice -10 at a > > guess like we used to in 2.4 days. It's not essential of course, but is a > > workaround for Mike's testcase. > > Oh my. I thought I was all done staring mindlessly at gforce (chinese > water torture). Oh well, a few more brain cells dying of boredom won't > kill me I guess ;-) Will give it a shot. No don't. It's buggy and you missed the warning. Boy were you lucky I was looking right now. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/1] LinuxPPS: Pulse per Second support for Linux
On Tue, Mar 13, 2007 at 06:48:17PM -0400, Lennart Sorensen wrote:
>
> I have tried out 3.0.0-rc2 which seems to work pretty well so far (when
Thanks. I just posted to the linux kernel ML the last release
3.0.0. Maybe you can do a "git pull" and try it out. :)
> combined with the patches to the jsm driver I just posted). It took soe
> work to get ntp's refclock_nmea to work though, since the patch that is
> linked to from the linuxpps page seems out of date. Here is the patch
> that seems to be working for me, although I am still testing it. Given
> you know the linuxpps code better perhaps you can see if it looks sane
> to you.
>
> --- ntpd/refclock_nmea.c.ori 2007-03-13 18:38:01.0 -0400
> +++ ntpd/refclock_nmea.c 2007-03-13 18:44:47.0 -0400
> @@ -79,6 +79,7 @@
> #define RANGEGATE50 /* range gate (ns) */
>
> #define LENNMEA 75 /* min timecode length */
> +#define LENPPS PPS_MAX_NAME_LEN
>
> /*
> * Tables to compute the ddd of year form icky dd/mm timecode. Viva la
> @@ -99,6 +100,7 @@
> pps_params_t pps_params; /* pps parameters */
> pps_info_t pps_info;/* last pps data */
> pps_handle_t handle;/* pps handlebars */
> + int handle_created; /* pps handle created flag */
> #endif /* HAVE_PPSAPI */
> };
>
> @@ -147,6 +149,11 @@
> register struct nmeaunit *up;
> struct refclockproc *pp;
> int fd;
> +#ifdef PPS_HAVE_FINDPATH
> + char id[LENPPS] = "",
> + path[LENPPS],
> + mylink[LENPPS] = "";/* just a default device */
> +#endif /* PPS_HAVE_FINDPATH */
> char device[20];
>
> /*
> @@ -201,7 +208,20 @@
> #else
> return (0);
> #endif
> -}
> +} else {
> +struct serial_struct ss;
> +if (ioctl(fd, TIOCGSERIAL, &ss) < 0 ||
> +(
> + ss.flags |= ASYNC_HARDPPS_CD,
> + ioctl(fd, TIOCSSERIAL, &ss)) < 0) {
> + msyslog(LOG_NOTICE, "refclock_nmea: TIOCSSERIAL fd %d, %m",
> fd);
> + msyslog(LOG_NOTICE,
> + "refclock_nmea: optional PPS processing not
> available");
> +} else {
> +msyslog(LOG_INFO,
> +"refclock_nmea: PPS detection on");
> +}
> + }
You should use "setserial" here. Keep in mind that the PPS source
could be _not_ connected with the serial line at all.
> /*
>* Allocate and initialize unit structure
> @@ -238,12 +258,26 @@
>* Start the PPSAPI interface if it is there. Default to use
>* the assert edge and do not enable the kernel hardpps.
>*/
> +#ifdef PPS_HAVE_FINDPATH
> + /* Get the PPS source's real name */
> + //time_pps_readlink(mylink, LENPPS, path, LENPPS);
Remove unneeded code.
> + time_pps_readlink(device, LENPPS, path, LENPPS);
Test the return value (see the wiki at
http://wiki.enneenne.com/index.php/LinuxPPS_support#How_to_modify_a_refclock_to_work_with_LinuxPPS).
> + /* Try to find the source */
> + fd = time_pps_findpath(path, LENPPS, id, LENPPS);
> + if (fd < 0) {
> + msyslog(LOG_ERR, "refclock_nmea: cannot find PPS path \"%s\" in
> the system", path);
> + return (0);
> + }
> + msyslog(LOG_INFO, "refclock_nmea: found PPS source \"%s\" at id #%d on
> \"%s\"", path, fd, id);
> +#endif /* PPS_HAVE_FINDPATH */
> if (time_pps_create(fd, &up->handle) < 0) {
> - up->handle = 0;
> + up->handle_created = 0;
> msyslog(LOG_ERR,
> "refclock_nmea: time_pps_create failed: %m");
> return (1);
> }
> + up->handle_created = ~0;
> return(nmea_ppsapi(peer, 0, 0));
> #else
> return (1);
> @@ -265,8 +299,10 @@
> pp = peer->procptr;
> up = (struct nmeaunit *)pp->unitptr;
> #ifdef HAVE_PPSAPI
> - if (up->handle != 0)
> + if (up->handle_created) {
> time_pps_destroy(up->handle);
> + up->handle_created = 0;
> + }
> #endif /* HAVE_PPSAPI */
> io_closeclock(&pp->io);
> free(up);
> @@ -374,7 +410,7 @@
> /*
>* Convert the timespec nanoseconds field to ntp l_fp units.
>*/
> - if (up->handle == 0)
> + if (!up->handle_created)
> return (0);
> timeout.tv_sec = 0;
> timeout.tv_nsec = 0;
Please, rewiev and test the code and I'll publish it.
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems[EMAIL PROTECTED]
UNIX programming phone: +39 349 2432127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read th
Re: [PATCH 00/18] Make common x86 arch area for i386 and x86_64 - Take 2
Steven Rostedt <[EMAIL PROTECTED]> writes: > > So I spent last night hacking up something to try to make a common ground > for all code that is shared between x86_64 and i386. I called this > >arch/x86 NACK. I think the current ways work just fine. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] Apple SMC driver (hardware monitoring and control)
Hello, I developed, a while ago, a driver the Apple System Management Controller, which provides an accelerometer (Apple Sudden Motion Sensor), light sensors, temperature sensors, keyboard backlight control and fan control on Intel-based Apple's computers (MacBook Pro, MacBook, MacMini). This patch has been tested successfully since kernel 2.6.18 (i.e. 3-4 months ago) by various users on different systems on the mactel-linux lists. However, I'm not really satisfied with the way sysfs files are created: I use a lot of preprocessor macros to avoid repetition of code. The files created with these macros in /sys/devices/platform/applesmc are the following (on a Macbook Pro): fan0_actual_speed fan0_manual fan0_maximum_speed fan0_minimum_speed fan0_safe_speed fan0_target_speed fan1_actual_speed fan1_manual fan1_maximum_speed fan1_minimum_speed fan1_safe_speed fan1_target_speed temperature_0 temperature_1 temperature_2 temperature_3 temperature_4 temperature_5 temperature_6 (i.e. temperature_* is created by one macro, fan*_actual_speed by another, ...) Is it acceptable programming practice? Is there a way to create these files in a more elegant manner? Also, I never call any sysfs_remove_* function, as the files are deleted when the module is unloaded. Is it safe to do so? Doesn't it cause any memory leak? This is my main concerns, however, I would be happy to have comments on the other parts of the code. (Please cc me I'm not subscribed to lkml) Best regards, Nicolas Boichat From: Nicolas Boichat <[EMAIL PROTECTED]> --- drivers/hwmon/Kconfig| 24 + drivers/hwmon/Makefile |1 drivers/hwmon/applesmc.c | 964 ++ 3 files changed, 989 insertions(+), 0 deletions(-) diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index c3d4856..798b91d 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -593,6 +593,30 @@ config SENSORS_HDAPS Say Y here if you have an applicable laptop and want to experience the awesome power of hdaps. +config SENSORS_APPLESMC + tristate "Apple SMC (Motion sensor, light sensor, keyboard backlight)" + depends on HWMON && INPUT && X86 + select NEW_LEDS + select LEDS_CLASS + default n + help + This driver provides support for the Apple System Management + Controller, which provides an accelerometer (Apple Sudden Motion + Sensor), light sensors, temperature sensors, keyboard backlight + control and fan control. + + Only Intel-based Apple's computers are supported (MacBook Pro, + MacBook, MacMini). + + Data from the different sensors, keyboard backlight control and fan + control are accessible via sysfs. + + This driver also provides an absolute input class device, allowing + the laptop to act as a pinball machine-esque joystick. + + Say Y here if you have an applicable laptop and want to experience + the awesome power of applesmc. + config HWMON_DEBUG_CHIP bool "Hardware Monitoring Chip debugging messages" depends on HWMON diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 4165c27..544f8d8 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -20,6 +20,7 @@ obj-$(CONFIG_SENSORS_ADM1026) += adm1026.o obj-$(CONFIG_SENSORS_ADM1029) += adm1029.o obj-$(CONFIG_SENSORS_ADM1031) += adm1031.o obj-$(CONFIG_SENSORS_ADM9240) += adm9240.o +obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o obj-$(CONFIG_SENSORS_AMS) += ams/ obj-$(CONFIG_SENSORS_ATXP1)+= atxp1.o obj-$(CONFIG_SENSORS_DS1621) += ds1621.o diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c new file mode 100644 index 000..3bdd1a8 --- /dev/null +++ b/drivers/hwmon/applesmc.c @@ -0,0 +1,964 @@ +/* + * drivers/hwmon/applesmc.c - driver for Apple's SMC (accelerometer, temperature + * sensors, fan control, keyboard backlight control) used in Intel-based Apple + * computers. + * + * Copyright (C) 2007 Nicolas Boichat <[EMAIL PROTECTED]> + * + * Based on hdaps.c driver: + * Copyright (C) 2005 Robert Love <[EMAIL PROTECTED]> + * Copyright (C) 2005 Jesper Juhl <[EMAIL PROTECTED]> + * + * Fan control based on smcFanControl: + * Copyright (C) 2006 Hendrik Holtmann <[EMAIL PROTECTED]> + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License v2 as published by the + * Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * You should have received a copy of the GNU General Public License along with + * this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#incl
Re: [PATCH 10/17] C99 initializers, proper use of const in drivers/ps3
On Wed, 14 Mar 2007, Al Viro wrote:
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Acked-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
> ---
> drivers/ps3/ps3av_cmd.c | 24 +---
> 1 files changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/ps3/ps3av_cmd.c b/drivers/ps3/ps3av_cmd.c
> index 21c97c8..bc70e81 100644
> --- a/drivers/ps3/ps3av_cmd.c
> +++ b/drivers/ps3/ps3av_cmd.c
> @@ -485,12 +485,12 @@ static u8 ps3av_cnv_mclk(u32 fs)
>
> static const u32 ps3av_ns_table[][5] = {
> /* D1,D2,D3,D4,D5 */
> - [PS3AV_CMD_AUDIO_FS_44K-BASE] { 6272, 6272, 17836, 17836, 8918 },
> - [PS3AV_CMD_AUDIO_FS_48K-BASE] { 6144, 6144, 11648, 11648, 5824 },
> - [PS3AV_CMD_AUDIO_FS_88K-BASE] { 12544, 12544, 35672, 35672, 17836 },
> - [PS3AV_CMD_AUDIO_FS_96K-BASE] { 12288, 12288, 23296, 23296, 11648 },
> - [PS3AV_CMD_AUDIO_FS_176K-BASE] { 25088, 25088, 71344, 71344, 35672 },
> - [PS3AV_CMD_AUDIO_FS_192K-BASE] { 24576, 24576, 46592, 46592, 23296 }
> + [PS3AV_CMD_AUDIO_FS_44K-BASE] = { 6272, 6272, 17836, 17836, 8918 },
> + [PS3AV_CMD_AUDIO_FS_48K-BASE] = { 6144, 6144, 11648, 11648, 5824 },
> + [PS3AV_CMD_AUDIO_FS_88K-BASE] = { 12544, 12544, 35672, 35672, 17836 },
> + [PS3AV_CMD_AUDIO_FS_96K-BASE] = { 12288, 12288, 23296, 23296, 11648 },
> + [PS3AV_CMD_AUDIO_FS_176K-BASE] ={ 25088, 25088, 71344, 71344,
> 35672 },
> + [PS3AV_CMD_AUDIO_FS_192K-BASE] ={ 24576, 24576, 46592, 46592,
> 23296 }
> };
>
> static void ps3av_cnv_ns(u8 *ns, u32 fs, u32 video_vid)
> @@ -543,9 +543,10 @@ static void ps3av_cnv_ns(u8 *ns, u32 fs, u32 video_vid)
>
> #undef BASE
>
> -static u8 ps3av_cnv_enable(u32 source, u8 *enable)
> +static u8 ps3av_cnv_enable(u32 source, const u8 *enable)
> {
> - u8 *p, ret = 0;
> + const u8 *p;
> + u8 ret = 0;
>
> if (source == PS3AV_CMD_AUDIO_SOURCE_SPDIF) {
> ret = 0x03;
> @@ -559,9 +560,10 @@ static u8 ps3av_cnv_enable(u32 source, u8 *enable)
> return ret;
> }
>
> -static u8 ps3av_cnv_fifomap(u8 *map)
> +static u8 ps3av_cnv_fifomap(const u8 *map)
> {
> - u8 *p, ret = 0;
> + const u8 *p;
> + u8 ret = 0;
>
> p = map;
> ret = p[0] + (p[1] << 2) + (p[2] << 4) + (p[3] << 6);
> @@ -615,7 +617,7 @@ static void ps3av_cnv_info(struct ps3av_audio_info_frame
> *info,
> info->pb5.lsv = mode->audio_downmix_level;
> }
>
> -static void ps3av_cnv_chstat(u8 *chstat, u8 *cs_info)
> +static void ps3av_cnv_chstat(u8 *chstat, const u8 *cs_info)
> {
> memcpy(chstat, cs_info, 5);
> }
> --
> 1.5.0-rc2.GIT
>
>
> ___
> Linuxppc-dev mailing list
> [EMAIL PROTECTED]
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 B-1935 Zaventem, Belgium
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RSDL-0.30] sched: rsdl improve latencies with differential nice
On Wed, 2007-03-14 at 20:25 +1100, Con Kolivas wrote: > No don't. It's buggy and you missed the warning. Boy were you lucky I was > looking right now. I'll wait for a .31 and construct a 2.6.21-rc3 (isolation) test-tree from that. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 11/13] sparc: have dma-mapping.h include generic/dma-mapping-broken in non-PCI case
On Wed, Mar 14, 2007 at 09:16:44AM +, Al Viro wrote:
>
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
> ---
> include/asm-sparc/dma-mapping.h | 15 +--
> 1 files changed, 1 insertions(+), 14 deletions(-)
>
> diff --git a/include/asm-sparc/dma-mapping.h b/include/asm-sparc/dma-mapping.h
> index 6db83dc..f3a641e 100644
> --- a/include/asm-sparc/dma-mapping.h
> +++ b/include/asm-sparc/dma-mapping.h
> @@ -5,20 +5,7 @@
> #ifdef CONFIG_PCI
> #include
> #else
> -
> -static inline void *dma_alloc_coherent(struct device *dev, size_t size,
> - dma_addr_t *dma_handle, gfp_t flag)
> -{
> - BUG();
> - return NULL;
> -}
> -
> -static inline void dma_free_coherent(struct device *dev, size_t size,
> -void *vaddr, dma_addr_t dma_handle)
> -{
> - BUG();
> -}
> -
> +#include
> #endif /* PCI */
>
> #endif /* _ASM_SPARC_DMA_MAPPING_H */
This one is in -mm : http://lkml.org/lkml/2007/2/26/107
So maybe you don't need to add another reference to dma-mapping-broken.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: [ck] RSDL v0.30 cpu scheduler for mainline kernels
On Tue, 13 Mar 2007 11:45:50 -0600 "Chris Friesen" <[EMAIL PROTECTED]> wrote: > Lee Revell wrote: > > > Sounds like Wengophone is broken. It should be using RT threads for > > time critical work, as JACK and Ardour2 are doing. > > If the app has root privileges to set RT policy, then it could also set > deeply negative nice values as well. > > Doesn't reallly help the regular user with no privileges. > > Chris Well my distro (Arch) does have the relevant PAM support for giving users realtime capabilities, but naturally Wengophone is not designed to make use of them (does any internet phone do this?). The main problem is that it worked fine on mainline and does not with RSDL, and even boosting it to nice -19 (with root privs) makes no difference (although I only tested nice -19 with the slightly dodgy patch Con posted for Mike Galbraith, that patch reportedly only affects a few positive nice values). Two possibilities occur to me: 1. RSDL just isn't giving sched_other tasks as low latency as mainline (Wengophone is not using much CPU time from as far as top can tell). 2. The problem is actually caused by increased network latency somehow caused by RSDL (this is an internet phone). I would like to add that the problem seems to be latency *spikes* that occur when there is sudden activity in another app (say, I open a folder in nautilus) that was previously largely idle. I suppose if Con does what he says and reduces latency overall, this problem might disappear. For now, of course, I hope his neck gets better :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Need help on mach-ep93xx
Hi, Many thanks to Lennert Buytenhek. Try applying: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4122/1 On 3/13/07, Ben Dooks <[EMAIL PROTECTED]> wrote: On Tue, Mar 13, 2007 at 10:54:08AM +0530, Maxin John wrote: > Hi, > > I have one question mach-ep93xx. > > In EP93xx IRQ handling part in core.c, the 2.6.19.2 kernel and > newer kernels are configuring the 16 interrupts of the ports A & B > together. The code is not using the interrupt capability of the port > F which can provide 3 interrupts. > > Why the port F is not configured for interrupts ? > > Thanks in advance, subscribe to the linux-arm-kernel list and ask the question there, you'll find more ARM people there. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' Sincerely, Maxin B. john 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][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2
On Wed, 2007-03-14 at 04:25 +0100, Gabriel C wrote: > [EMAIL PROTECTED] wrote: > > On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said: > > > >> with latest xorg, xlib will be using xcb internally, > >> > > > > Out of curiosity, when is this "latest" Xorg going to escape to distros, > > > > Already is .. Xorg 7.2+ libx11 build with xcb enabled.. I think the true improvement will come when toolkits (GTK+ & Qt) are ported to xcb. Xav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/18] Make common x86 arch area for i386 and x86_64 - Take 2
Hi, I am newbie developing a routing application which needs three features; 1. if the fib lookup fails, my application needs to know about using preferably netlink, -- any direction to some sample code or files in the kernel??? 2. I need a counter recording the hits a fib entry is chosen for packet forwarding. Is it the function fn_trie_lookup in file /net/ipv4/fib_trie.c i need to modify and look into? -- ?? and therefore is it safe to add a int counter in fib_node w/o breaking the build?? 2. need to read the entire fib, i.e dump the fib to the user space, -- again any direction to some sample code etc.. i have seen a fn in /source/net/ipv4/fib_frontend.c , which looks like is supposed to dump the routes but not sure how to use it.. line no.581 int inet_dump_fib(struct sk_buff *skb, struct netlink_callback *cb) Also; fn_trie_dump() in /net/ipv4/fib_trie.c This could be an inappropriate list for the above questions, if it is request for some direction on the appropriate mailing list Appreciate any help. Thanking you, Sujay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 13/13] fix ps3fb glue allowing a modular build
On Wed, 14 Mar 2007, Al Viro wrote:
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
NAK
There are several problems with making it modular. I did try, cfr. the
incomplete patchlets below.
> ---
> arch/powerpc/platforms/ps3/htab.c |2 ++
> drivers/video/Kconfig |2 +-
> include/asm-powerpc/ps3fb.h |5 -
> 3 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/platforms/ps3/htab.c
> b/arch/powerpc/platforms/ps3/htab.c
> index e12e59f..67d6f58 100644
> --- a/arch/powerpc/platforms/ps3/htab.c
> +++ b/arch/powerpc/platforms/ps3/htab.c
> @@ -235,7 +235,9 @@ static void ps3_hpte_invalidate(unsigned long slot,
> unsigned long va,
> static void ps3_hpte_clear(void)
> {
> /* Make sure to clean up the frame buffer device first */
> +#ifdef CONFIG_PS3_FB
> ps3fb_cleanup();
> +#endif
I'm not sure it will survive a kexec() of a new kernel if ps3fb_cleanup()
isn't called when ps3fb.ko has been loaded. But that's an issue for later...
> index ad81cf4..a447387 100644
> --- a/include/asm-powerpc/ps3fb.h
> +++ b/include/asm-powerpc/ps3fb.h
> @@ -43,13 +43,8 @@ struct ps3fb_ioctl_res {
>
> #ifdef __KERNEL__
>
> -#ifdef CONFIG_FB_PS3
> extern void ps3fb_flip_ctl(int on);
> extern void ps3fb_cleanup(void);
> -#else
> -static inline void ps3fb_flip_ctl(int on) {}
> -static inline void ps3fb_cleanup(void) {}
> -#endif
Now it fails to link with:
| drivers/built-in.o: In function
`ps3av_cmd_avb_param':ps3-linux-2.6.21-rc3/drivers/ps3/ps3av_cmd.c:855:
undefined reference to `.ps3fb_flip_ctl'
| :ps3-linux-2.6.21-rc3/drivers/ps3/ps3av_cmd.c:869: undefined reference to
`.ps3fb_flip_ctl'
Which could be fixed with something like:
--- ps3-linux-2.6.20.orig/drivers/ps3/ps3av.c
+++ ps3-linux-2.6.20/drivers/ps3/ps3av.c
@@ -868,6 +868,22 @@ int ps3av_dev_close(void)
EXPORT_SYMBOL_GPL(ps3av_dev_close);
+void ps3av_register_flip_ctl(void (*flip_ctl)(int on))
+{
+ mutex_lock(&ps3av.mutex);
+ ps3av.flip_ctl = flip_ctl;
+ mutex_unlock(&ps3av.mutex);
+}
+EXPORT_SYMBOL_GPL(ps3av_register_flip_ctl);
+
+void ps3av_flip_ctl(int on)
+{
+ mutex_lock(&ps3av.mutex);
+ if (ps3av.flip_ctl)
+ ps3av.flip_ctl(on);
+ mutex_unlock(&ps3av.mutex);
+}
+
static int ps3av_probe(struct ps3_vuart_port_device *dev)
{
int res;
--- ps3-linux-2.6.20.orig/drivers/ps3/ps3av_cmd.c
+++ ps3-linux-2.6.20/drivers/ps3/ps3av_cmd.c
@@ -852,7 +852,7 @@ int ps3av_cmd_avb_param(struct ps3av_pkt
{
int res;
- ps3fb_flip_ctl(0); /* flip off */
+ ps3av_flip_ctl(0); /* flip off */
/* avb packet */
res = ps3av_do_pkt(PS3AV_CID_AVB_PARAM, send_len, sizeof(*avb),
@@ -866,7 +866,7 @@ int ps3av_cmd_avb_param(struct ps3av_pkt
res);
out:
- ps3fb_flip_ctl(1); /* flip on */
+ ps3av_flip_ctl(1); /* flip on */
return res;
}
--- ps3-linux-2.6.20.orig/include/asm-powerpc/ps3av.h
+++ ps3-linux-2.6.20/include/asm-powerpc/ps3av.h
@@ -660,6 +660,7 @@ struct ps3av {
u32 audio_port;
int ps3av_mode;
int ps3av_mode_old;
+ void (*flip_ctl)(int on);
};
/** command status **/
@@ -734,5 +735,7 @@ extern int ps3av_video_mute(int);
extern int ps3av_audio_mute(int);
extern int ps3av_dev_open(void);
extern int ps3av_dev_close(void);
+extern void ps3av_register_flip_ctl(void (*func)(int on));
+extern void ps3av_flip_ctl(int on);
#endif /* _ASM_POWERPC_PS3AV_H_ */
and calling ps3av_register_flip_ctl() from ps3fb at the appropriate places.
Still, the module won't load, as ps3fb needs ps3fb_videomemory[] (do you
know a better way to allocate a few mebibytes of physically contiguous
memory?):
--- ps3-linux-2.6.20.orig/arch/powerpc/platforms/ps3/setup.c
+++ ps3-linux-2.6.20/arch/powerpc/platforms/ps3/setup.c
@@ -115,12 +115,13 @@ static void prealloc(struct ps3_prealloc
p->address);
}
-#ifdef CONFIG_FB_PS3
+#if defined(CONFIG_FB_PS3) || defined(CONFIG_FB_PS3_MODULE)
struct ps3_prealloc ps3fb_videomemory = {
.name = "ps3fb videomemory",
.size = CONFIG_FB_PS3_DEFAULT_SIZE_M*1024*1024,
.align = 1024*1024 /* the GPU requires 1 MiB alignment */
};
+EXPORT_SYMBOL_GPL(ps3fb_videomemory);
#define prealloc_ps3fb_videomemory() prealloc(&ps3fb_videomemory)
static int __init early_parse_ps3fb(char *p)
And finally, make sure CONFIG_LOGO=n, as there's a bug in the logo code: logos
are __initdata but the logo code still tries to draw them for a modular fbdev.
Originally (eons ago) this case was handled by the flag initmem_freed, which no
longer exists.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 B-1935 Zaventem, Belgium
-
To unsubscribe fro
fib search and handling
Hi, I am newbie developing a routing application which needs three features; 1. if the fib lookup fails, my application needs to know about using preferably netlink, -- any direction to some sample code or files in the kernel??? 2. I need a counter recording the hits a fib entry is chosen for packet forwarding. Is it the function fn_trie_lookup in file /net/ipv4/fib_trie.c i need to modify and look into? -- ?? and therefore is it safe to add a int counter in fib_node w/o breaking the build?? 2. need to read the entire fib, i.e dump the fib to the user space, -- again any direction to some sample code etc.. i have seen a fn in /source/net/ipv4/fib_frontend.c , which looks like is supposed to dump the routes but not sure how to use it.. line no.581 int inet_dump_fib(struct sk_buff *skb, struct netlink_callback *cb) Also; fn_trie_dump() in /net/ipv4/fib_trie.c This could be an inappropriate list for the above questions, if it is request for some direction on the appropriate mailing list Appreciate any help. Thanking you, Sujay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] hrtimer: prevent overrun DoS in hrtimer_forward()
hrtimer_forward() does not check for the possible overflow of timer->expires. This can happen on 64 bit machines with large interval values and results currently in an endless loop in the softirq because the expiry value becomes negative and therefor the timer is expired all the time. Check for this condition and set the expiry value to the max. expiry time in the future. The fix should be applied to stable kernel series as well. Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED],de> diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index ec4cb9f..5e7122d 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -644,6 +644,12 @@ hrtimer_forward(struct hrtimer *timer, k orun++; } timer->expires = ktime_add(timer->expires, interval); + /* +* Make sure, that the result did not wrap with a very large +* interval. +*/ + if (timer->expires.tv64 < 0) + timer->expires = ktime_set(KTIME_SEC_MAX, 0); return orun; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 14/17] atl1 trivial endianness misannotations
Al Viro wrote: NB: driver is choke-full of code that will break on big-endian; as long as the hardware is onboard-only we can live with that, but sooner or later that'll need fixing. Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- drivers/net/atl1/atl1_main.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) ACK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 7/17] trivial ATA iomem annotations
Al Viro wrote: Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- drivers/ata/pata_cs5520.c |2 +- drivers/ata/sata_sis.c|2 +- 2 files changed, 2 insertions(+), 2 deletions(-) ACK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/17] dmfe trivial endianness annotations
Al Viro wrote: Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- drivers/net/tulip/dmfe.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) ACK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible "struct pid" leak from tty_io.c
On 13/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> void proc_clear_tty(struct task_struct *p)
> {
> + struct tty_struct *tty;
> +
> spin_lock_irq(&p->sighand->siglock);
> + tty = p->signal->tty;
> + if (tty) {
> + put_pid(tty->session);
> + put_pid(tty->pgrp);
> + }
> p->signal->tty = NULL;
> spin_unlock_irq(&p->sighand->siglock);
> }
This patch can't be right. Not the way proc_clear_tty is called
once for each process in the session, plus we aren't clearing
tty->session and tty->pgrp here.
If the above patch works it's a fluke.
I looked at the logs and the pointer isn't freed indeed. It is just a
false negative in kmemleak and it would appear as a leak at some
point. But the previous patch (do_tty_hangup) seems to fix one of the
leaks.
For the 2nd leak, proc_set_tty is called and, for symmetry, I added
put_pid in proc_clear_tty (but without any deep thought). I also
haven't checked any lockdep issues with adding put_pid when
p->sighand->siglock is held.
--
Catalin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] hrtimer: prevent overrun DoS in hrtimer_forward()
* Thomas Gleixner <[EMAIL PROTECTED]> wrote: > hrtimer_forward() does not check for the possible overflow of > timer->expires. This can happen on 64 bit machines with large interval > values and results currently in an endless loop in the softirq because > the expiry value becomes negative and therefor the timer is expired > all the time. > > Check for this condition and set the expiry value to the max. expiry > time in the future. > > The fix should be applied to stable kernel series as well. > > Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED],de> ouch ... nice one. Acked-by: Ingo Molnar <[EMAIL PROTECTED]> Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH 00/59] Make common x86 arch area for i386 and x86_64
On Tue, Mar 13, 2007 at 02:39:33PM -0700, Linus Torvalds wrote: > > > On Tue, 13 Mar 2007, Steven Rostedt wrote: > > > > What we have currently is a bunch of hacks. Seems that people can't make > > up their mind to what to do. I think they work fine. I don't like such large scale renaming -- they are a pain for anybody with external patches and make regression hunting later painful. And the gain is about zero as far as I can see. It won't fix a single bug, just cause pain. > > I don't mind the patches, but I'd be a lot happier if it also was a stated > intention to actually make it be buildable as "x86", the same way that the > separate 32-bit and 64-bit POWER architectures were merged into just one > architecture that could be built either way. I've thought about it, but it would be a lot of work and regression test on old hardware would be a nightmare. Besides still x86-64 is a lot cleaner than i386 and imho easier to hack and with all the 32bit quirks readded it would probably become worse than current i386. The only good option would be a "modern 32bit only" but even that gets complicated quickly when you consider all the corner cases. And a clean 32bit port wouldn't cover enough hardware to be usable by distributions. And I also don't have really time to work on that. > The "32-bit code has legcay issues" thing that Andi complained about (eg > there's no guarantee of a HPET on 32-bit x86) doesn't really change the Most 64bit doesn't neither. > fact that yes, we have to support those legacy issues *anyway*, and 64-bit > x86 certainly has its set of issues already too. Yes :/ The more supported systems, the more junk. The recent nmi watchdog issues are a good example. All just because a few vendors write crappy AML/SMM code. > We've started to notice that the i386 build gets broken now that most > developers tend to have newer CPU's and run mostly on x86-64 (and yes, > that's me too), and while I don't think unifying things will guarantee > that doesn't happen in the future, it will hopefully at least help make it > not get much *worse*. Build test would be needed anyways, doesn't make much difference I guess. > As it is, the build environment has to know to pass in "-m32/-m64" > anyway.. It already does that. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc3-mm2 (oops in move_freepages)
On (13/03/07 21:52), Bjorn Helgaas didst pronounce:
> FYI, I'm seeing the following oops with 2.6.21-rc3-mm1 (and -mm2)
> on the HP rx2600 and an Intel Tiger (both ia64 boxes).
>
> I haven't investigated this other than to determine that it
> does not occur with 2.6.21-rc3 or 2.6.20-rc3-mm1, and the
> instruction at move_freepages+0x10 is a load of the value
> pointed to by the third argument (end_page).
>
Please try the following patch from Yasunori Goto.
>From [EMAIL PROTECTED] Thu Mar 8 08:00:15 2007
Date: Thu, 08 Mar 2007 16:39:43 +0900
From: Yasunori Goto <[EMAIL PROTECTED]>
To: Andrew Morton <[EMAIL PROTECTED]>
Cc: linux-kernel@vger.kernel.org, Mel Gorman <[EMAIL PROTECTED]>
Subject: [PATCH] fix BUG_ON check at move_freepages() (Re: 2.6.21-rc3-mm2)
Hello.
The BUG_ON() check at move_freepages() is wrong.
Its end_page is start_page + MAX_ORDER_NR_PAGES. So, it can be
next zone. BUG_ON() should check "end_page - 1".
This is fix of 2.6.21-rc3-mm2 for it.
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
---
mm/page_alloc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: current_test/mm/page_alloc.c
===
--- current_test.orig/mm/page_alloc.c 2007-03-08 15:44:10.0 +0900
+++ current_test/mm/page_alloc.c2007-03-08 16:17:29.0 +0900
@@ -707,7 +707,7 @@ int move_freepages(struct zone *zone,
unsigned long order;
int blocks_moved = 0;
- BUG_ON(page_zone(start_page) != page_zone(end_page));
+ BUG_ON(page_zone(start_page) != page_zone(end_page - 1));
for (page = start_page; page < end_page;) {
if (!PageBuddy(page)) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 58/59] sysctl: Reimplement the sysctl proc support
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]> - unquoted
>
> With this change the sysctl inodes can be cached and nothing needs to
> be done when removing a sysctl table.
your change is now upstream:
commit 77b14db502cb85a031fe8fde6c85d52f3e0acb63
Author: Eric W. Biederman <[EMAIL PROTECTED]>
Date: Wed Feb 14 00:34:12 2007 -0800
but it broke the latency tracer in -rt which uses create_proc_entry() to
attach a custom handler to value changes in preempt_max_latency:
#define PROCNAME_PML"sys/kernel/preempt_max_latency"
static __init int latency_fs_init(void)
{
struct proc_dir_entry *entry;
if (!(entry = create_proc_entry(PROCNAME_PML, 0644, NULL)))
printk("latency_fs_init(): can't create %s\n", PROCNAME_PML);
with your change that broke because beyond /proc/sys/ there are no real
proc entries anymore, there's no de->subdir directory for
xlate_proc_name() to find. While the latency tracer isnt upstream, this
change in semantics does not seem to be intended (the changelog is
certainly silent about it).
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at mm/slab.c:610
Hi Marco, On 3/14/07, Marco Berizzi <[EMAIL PROTECTED]> wrote: Hello everybody. Sorry for posting to this list, but I'm pretty lost. Don't worry, this is the proper mailing list for bug reports. On 3/14/07, Marco Berizzi <[EMAIL PROTECTED]> wrote: I don't think this is related to buggy hardware because it is happening on 3 different boxes with the same hardware config. No, looks like someone is feeding a bad pointer to slab. The debug check is relatively new and in previous kernels the problem would might have gone unnoticed causing silent corruption of the slab. On 3/14/07, Marco Berizzi <[EMAIL PROTECTED]> wrote: ksymoops 2.4.10 on i686 2.6.20. Options used From Documentation/oops-tracing.txt: "NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format (from dmesg, etc). Ignore any references in this or other docs to "decoding the Oops" or "running it through ksymoops". If you post an Oops from 2.6 that has been run through ksymoops, people will just tell you to repost it." So, can you please repost the original oops? Also, please enable CONFIG_DEBUG_SLAB and try to reproduce. 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: [PATCH 58/59] sysctl: Reimplement the sysctl proc support
On 3/14/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
#define PROCNAME_PML"sys/kernel/preempt_max_latency"
static __init int latency_fs_init(void)
{
struct proc_dir_entry *entry;
if (!(entry = create_proc_entry(PROCNAME_PML, 0644, NULL)))
printk("latency_fs_init(): can't create %s\n",
PROCNAME_PML);
with your change that broke because beyond /proc/sys/ there are no real
proc entries anymore, there's no de->subdir directory for
xlate_proc_name() to find. While the latency tracer isnt upstream, this
change in semantics does not seem to be intended (the changelog is
certainly silent about it).
Use register_sysctl_table() for sysctls.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Clarification required about select vs wake_up race condition
On Mon, 2007-03-12 at 12:44 -0700, Ravinandan Arakali (rarakali) wrote: > Hi, > I am facing following problem and was wondering if somebody could help > me out. > Our char driver(pretty much like all other char drivers) does a > poll_wait() you forgot to include your (full) sourcecode or a pointer to that... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Apple SMC driver (hardware monitoring and control)
I am sorry. I forgot to CC to the list.
2007/3/14, Nicolas Boichat wrote:
Hello,
+static ssize_t applesmc_show_fan_manual(struct device *dev, char *buf,
+ int offset)
+{
+ int ret;
+ u16 manual = 0;
+ u8 buffer[2];
+
+ down(&applesmc_sem);
+
+ ret = applesmc_read_key(FANS_MANUAL, buffer, 2);
+ manual = ((buffer[0] << 8 | buffer[1]) >> offset) & 0x01;
+
+ up(&applesmc_sem);
+ if (ret)
+ return ret;
+ else
+ return sprintf(buf, "%d\n", manual);
+}
+
I doubt about your last 'sprintf'. Your 'buf' just has only two 'u8's,
which maybe only has two bytes, and '\n' already consumes one. So only
one byte is left for the decimal vaule of 'manual'. Even it is just
less than 10, just as what you want, the final '\0' is omitted!
What's more, you can't get such information from the return value of
'sprintf'. So I suggest you to choose 'snprintf' instead.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)
(Cc'ing Greg KH and linux1394-devel) Ismail Dönmez wrote at lkml: > With latest GIT tree I am getting the following oops when I try to suspend to > RAM: > > BUG: unable to handle kernel NULL pointer dereference at virtual address > 0094 > printing eip: > c0222af4 > *pde = > Oops: [#1] > PREEMPT > Modules linked in: i915 drm snd_pcm_oss snd_mixer_oss snd_seq_dummy > snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device usbhid eth1394 ipw2200 > ieee80211 ieee80211_crypt snd_hda_intel snd_hda_codec snd_pcm snd_timer snd > snd_page_alloc tifm_7xx1 tifm_core i2c_i801 i2c_core ehci_hcd uhci_hcd > ohci1394 ieee1394 pcmcia usbcore yenta_socket rsrc_nonstatic pcmcia_core > sony_laptop backlight > CPU:0 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010246 (2.6.21-rc3 #12) > EIP is at class_device_remove_attrs+0xa/0x30 > eax: f7cb5b18 ebx: ecx: f8bde010 edx: > esi: edi: f7cb5b18 ebp: esp: d93e7e1c > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process modprobe (pid: 12200, ti=d93e6000 task=e5770a50 task.ti=d93e6000) > Stack: f7cb5b18 f7cb5b20 c0222bc3 f7cb5990 f7cb5b18 f7cb59c4 >f8bcdc0f c0222bfb f7cb5990 f8bcdbf6 f8bd3275 04e2c100 000f >03c3 f8dcf05f f7e3e000 f8bcdc17 c0220567 f7e3e0a4 > Call Trace: > [] class_device_del+0xa9/0xd9 > [] __nodemgr_remove_host_dev+0x0/0xb [ieee1394] > [] class_device_unregister+0x8/0x10 > [] nodemgr_remove_ne+0x61/0x7a [ieee1394] > [] ether1394_mac_addr+0x0/0x12 [eth1394] > [] __nodemgr_remove_host_dev+0x8/0xb [ieee1394] > [] device_for_each_child+0x1a/0x3c > [] nodemgr_remove_host+0x30/0x90 [ieee1394] > [] __unregister_host+0x1a/0xac [ieee1394] > [] flush_cpu_workqueue+0x98/0xb7 > [] highlevel_remove_host+0x21/0x42 [ieee1394] > [] hpsb_remove_host+0x37/0x58 [ieee1394] > [] ohci1394_pci_remove+0x47/0x1ec [ohci1394] > [] sysfs_hash_and_remove+0xfa/0x111 > [] pci_device_remove+0x16/0x35 > [] __device_release_driver+0x6e/0x8b > [] driver_detach+0x99/0xda > [] bus_remove_driver+0x57/0x75 > [] driver_unregister+0x8/0x13 > [] pci_unregister_driver+0xc/0x67 > [] sys_delete_module+0x15c/0x19d > [] remove_vma+0x31/0x36 > [] do_munmap+0x19b/0x1b4 > [] sysenter_past_esp+0x5f/0x85 > [] packet_notifier+0xf3/0x157 > === > Code: ff c3 85 c0 74 08 83 c0 08 e9 83 6d f6 ff b8 ea ff ff ff c3 85 c0 74 08 > 83 c0 08 e9 4c 51 f6 ff c3 57 89 c7 56 53 8b 70 44 31 db <83> be 94 00 00 00 > 00 75 09 eb 17 89 f8 e8 d7 ff ff ff 89 da 83 > EIP: [] class_device_remove_attrs+0xa/0x30 SS:ESP 0068:d93e7e1c > > > Checking Google I see a similar oops was reported long ago: > http://lkml.org/lkml/2006/11/16/147 . > > Any ideas/patches to test? Please CC me in your replies. Thanks for the report. Do you have a script or config which marks the ohci1394 module to be unloaded before suspend? This should not be necessary since 2.6.21-rc1 anymore. (Although I tested this only with APM suspend to RAM and only with the sbp2 driver as IEEE 1394 application-layer software, and only with current 1394 drivers on top of 2.6.20-rcX instead of 2.6.21-rcX. I heard that raw1394 survives suspend/resume thanks to the ohci1394 updates already in 2.6.20.) But back to your problem. The older report which you pointed to was a hickup caused by the ongoing conversion away from class_device. Further down that discussion, a 2.6.19-rcX-mmY patch was discovered to trigger this: http://lkml.org/lkml/2006/11/19/53 | the winner is... gregkh-driver-network-device.patch By "trigger" I mean that I don't know where the bug was, i.e. in the then partial driver core conversion or in the ieee1394 nodemgr. *However*, this time it's different --- you don't have eth1394 present. I will boot 2.6.21-rc3 on a spare machine and see how it goes. As a side note, the IEEE 1394 subsystem features quite a fat usage of the driver core. We have (in order of parent devices to child devices) the host adapter's PCI device's device, the 1394 host device (hpsb_host), the node entry devices, the unit directory devices. And all of them have respective class devices. But really important outside of the ieee1394 core are only the first and the last, i.e. PCI device and unit directories. Maybe we should redesign nodemgr to work without host devices and node entry devices. Side note to the side note: The new alternative IEEE 1394 drivers which are currently maturing in -mm (the 1394 stack nicknamed Juju), does indeed create only unit directory devices if I'm not badly mistaken. -- Stefan Richter -=-=-=== --== -===- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Linux 2.6.20.2 - unable to handle kernel paging request - still accessing freed memory
Hi Chris, On 3/10/07, Chris Rankin <[EMAIL PROTECTED]> wrote: It looks like 2.6.20.2 is still doing Bad Things in /sys. I have seen other reports of this too so can you please open a bug at bugzilla.kernel.org so this is not lost in the noise? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 8040] Hang before INIT when CONFIG_HIGHMEM4G=y
> On Wed, 14 Mar 2007 03:13:25 -0700 [EMAIL PROTECTED] wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=8040 > > > > > > --- Additional Comments From [EMAIL PROTECTED] 2007-03-14 03:13 --- > Any news on that bug please ? None whatsoever. Three people are reporting this and it's a drop-dead showstopper for a 2.6.21 release so we just have to wait until someone wakes up and thinks about it. It would be very useful if one of the reporters could perform a git-bisect search to identify the offending change, please. I would dearly like to point you at a document or web page which describes kernel-git-bisect-for-newbies, but afaik there isn't such a thing, which is a huge failing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 BUG at mm/slab.c:610
Pekka Enberg wrote: Hi Pekka, > So, can you please repost the original oops? Here is: Mar 14 03:42:25 Mimosa kernel: [ cut here ] Mar 14 03:42:25 Mimosa kernel: kernel BUG at mm/slab.c:610! Mar 14 03:42:25 Mimosa kernel: invalid opcode: [#1] Mar 14 03:42:25 Mimosa kernel: Modules linked in: sch_sfq sch_htb cls_fw nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_ftp nf_conntrack_ftp 3c59x mii Mar 14 03:42:25 Mimosa kernel: CPU:0 Mar 14 03:42:25 Mimosa kernel: EIP:0060:[]Not tainted VLI Mar 14 03:42:25 Mimosa kernel: EFLAGS: 00010046 (2.6.20 #1) Mar 14 03:42:25 Mimosa kernel: EIP is at free_block+0xd9/0xf0 Mar 14 03:42:25 Mimosa kernel: eax: 0008 ebx: c100 ecx: c0e7d4e0 edx: c101cfa0 Mar 14 03:42:25 Mimosa kernel: esi: c121 edi: c1176560 ebp: esp: c119bef0 Mar 14 03:42:25 Mimosa kernel: ds: 007b es: 007b ss: 0068 Mar 14 03:42:25 Mimosa kernel: Process events/0 (pid: 3, ti=c119a000 task=c118f030 task.ti=c119a000) Mar 14 03:42:25 Mimosa kernel: Stack: c1213a10 161c9ed5 c1210010 c1210010 c121 161c9ed5 c1176560 c014d201 Mar 14 03:42:25 Mimosa kernel: c1180420 c1176560 c1180d60 c014d220 c014d26b Mar 14 03:42:25 Mimosa kernel:c03b7ae0 c03b7ae0 0282 c0123d37 c118f13c 007b 508b Mar 14 03:42:25 Mimosa kernel: Call Trace: Mar 14 03:42:25 Mimosa kernel: [] drain_array+0x91/0xb0 Mar 14 03:42:25 Mimosa kernel: [] cache_reap+0x0/0xf0 Mar 14 03:42:25 Mimosa kernel: [] cache_reap+0x4b/0xf0 Mar 14 03:42:25 Mimosa kernel: [] run_workqueue+0x67/0x130 Mar 14 03:42:25 Mimosa kernel: [] worker_thread+0x13a/0x170 Mar 14 03:42:25 Mimosa kernel: [] default_wake_function+0x0/0x10 Mar 14 03:42:25 Mimosa kernel: [] __wake_up_common+0x37/0x70 Mar 14 03:42:25 Mimosa kernel: [] default_wake_function+0x0/0x10 Mar 14 03:42:25 Mimosa kernel: [] worker_thread+0x0/0x170 Mar 14 03:42:25 Mimosa kernel: [] kthread+0xb6/0xc0 Mar 14 03:42:25 Mimosa kernel: [] kthread+0x0/0xc0 Mar 14 03:42:25 Mimosa kernel: [] kernel_thread_helper+0x7/0x14 Mar 14 03:42:25 Mimosa kernel: === Mar 14 03:42:25 Mimosa kernel: Code: ff 83 c4 0c 5b 5e 5f 5d c3 8b 57 20 29 d0 89 da 89 46 18 89 f8 e8 78 f1 ff ff eb da 89 33 8b 46 04 89 5e 04 89 18 89 43 04 eb cb <0f> 0b 90 8d 74 26 00 eb fe 8b 52 0c e9 57 ff ff ff 8d b6 00 00 Mar 14 03:42:25 Mimosa kernel: EIP: [] free_block+0xd9/0xf0 SS:ESP 0068:c119bef0 Here is from another machine: Mar 14 08:53:47 Gemini kernel: [ cut here ] Mar 14 08:53:47 Gemini kernel: kernel BUG at mm/slab.c:610! Mar 14 08:53:47 Gemini kernel: invalid opcode: [#1] Mar 14 08:53:47 Gemini kernel: Modules linked in: nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_ftp nf_conntrack_ftp 3c59x mii Mar 14 08:53:47 Gemini kernel: CPU:0 Mar 14 08:53:47 Gemini kernel: EIP:0060:[]Not tainted VLI Mar 14 08:53:47 Gemini kernel: EFLAGS: 00010046 (2.6.20 #1) Mar 14 08:53:47 Gemini kernel: EIP is at free_block+0xd6/0xf0 Mar 14 08:53:47 Gemini kernel: eax: 8000 ebx: c100 ecx: c9ae64e0 edx: c1135cc0 Mar 14 08:53:47 Gemini kernel: esi: c121 edi: c1176560 ebp: esp: c119bef0 Mar 14 08:53:47 Gemini kernel: ds: 007b es: 007b ss: 0068 Mar 14 08:53:47 Gemini kernel: Process events/0 (pid: 3, ti=c119a000 task=c118f030 task.ti=c119a000) Mar 14 08:53:47 Gemini kernel: Stack: c1179a10 110b04c7 c1210010 c1210010 c121 110b04c7 c1176560 c014d5f1 Mar 14 08:53:47 Gemini kernel: c1180420 c1176560 c1180d60 c014d610 c014d65b Mar 14 08:53:47 Gemini kernel:c03b7a60 c03b7a60 0282 c0124157 c118f13c 0076 5e32 Mar 14 08:53:47 Gemini kernel: Call Trace: Mar 14 08:53:47 Gemini kernel: [] drain_array+0x91/0xb0 Mar 14 08:53:47 Gemini kernel: [] cache_reap+0x0/0xf0 Mar 14 08:53:47 Gemini kernel: [] cache_reap+0x4b/0xf0 Mar 14 08:53:47 Gemini kernel: [] run_workqueue+0x67/0x130 Mar 14 08:53:47 Gemini kernel: [] worker_thread+0x13a/0x170 Mar 14 08:53:47 Gemini kernel: [] default_wake_function+0x0/0x10 Mar 14 08:53:47 Gemini kernel: [] __wake_up_common+0x37/0x70 Mar 14 08:53:47 Gemini kernel: [] default_wake_function+0x0/0x10 Mar 14 08:53:47 Gemini kernel: [] worker_thread+0x0/0x170 Mar 14 08:53:47 Gemini kernel: [] kthread+0xb6/0xc0 Mar 14 08:53:47 Gemini kernel: [] kthread+0x0/0xc0 Mar 14 08:53:47 Gemini kernel: [] kernel_thread_helper+0x7/0x10 Mar 14 08:53:47 Gemini kernel: === Mar 14 08:53:47 Gemini kernel: Code: ff 83 c4 0c 5b 5e 5f 5d c3 8b 57 20 29 d0 89 da 89 46 18 89 f8 e8 7b f1 ff ff eb da 89 33 8b 46 04 89 5e 04 89 18 89 43 04 eb cb <0f> 0b 90 8d b4 26 00 00 00 00 eb fe 8b 52 0c e9 57 ff ff ff 8d Mar 14 08:53:47 Gemini kernel: EIP: [] free_block+0xd6/0xf0 SS:ESP 0068:c119bef0 > Also, please enable > CONFIG_DEBUG_SLAB and try to reproduce. Thanks. I'm rebuilding all kernel w
Re: [BUG] Linux 2.6.20.2 - unable to handle kernel paging request - still accessing freed memory
Hi Greg, I think there's some sort of reference counting problem with sysfs in 2.6.20 kernels. Can you please help us debug it further? On 3/10/07, Chris Rankin <[EMAIL PROTECTED]> wrote: It looks like 2.6.20.2 is still doing Bad Things in /sys. BUG: unable to handle kernel paging request at virtual address 6b6b6d6b [snip] EIP:0060:[]Not tainted VLI EFLAGS: 00010202 (2.6.20.2 #1) EIP is at module_put+0x20/0x52 eax: 6b6b6d6b ebx: 6b6b6b6b ecx: 0001 edx: e7a01000 esi: edb7e4e4 edi: 6b6b6b6b ebp: e79fd50c esp: e7a01f58 ds: 007b es: 007b ss: 0068 Process udevd (pid: 9656, ti=e7a01000 task=f7a46030 task.ti=e7a01000) Stack: eba628a0 c0183a1e 0010 ed570870 e7a641d0 c0151263 f7ff2208 ed570870 f745b678 ed570870 c014eda0 0003 0003 f745b678 f745b6f8 c014fd99 0003 0007 0003 e7a01000 c0102bde Call Trace: [] sysfs_release+0x2d/0x4c [] __fput+0x96/0x13c [] filp_close+0x51/0x58 [] sys_close+0x70/0xa7 [] sysenter_past_esp+0x5f/0x85 [] __sched_text_start+0x613/0x971 There's also some previous discussion here: http://lkml.org/lkml/2007/3/1/114 Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 8040] Hang before INIT when CONFIG_HIGHMEM4G=y
On Wed, 14 Mar 2007, Andrew Morton wrote: > > On Wed, 14 Mar 2007 03:13:25 -0700 [EMAIL PROTECTED] wrote: > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8040 > > > > > > --- Additional Comments From [EMAIL PROTECTED] 2007-03-14 03:13 --- > > Any news on that bug please ? > > None whatsoever. Three people are reporting this and it's a drop-dead > showstopper for a 2.6.21 release so we just have to wait until someone > wakes up and thinks about it. > > It would be very useful if one of the reporters could perform a git-bisect > search to identify the offending change, please. > > I would dearly like to point you at a document or web page which describes > kernel-git-bisect-for-newbies, but afaik there isn't such a thing, which is > a huge failing. I have one of those one-of-my-machines-wont-boot-2.6.21-rc* and I expect that I'll try to use git bisect on it, in which case I will also document it. -- ~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: [Bug 8040] Hang before INIT when CONFIG_HIGHMEM4G=y
On 14/03/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 14 Mar 2007 03:13:25 -0700 [EMAIL PROTECTED] wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=8040 > > > > > > --- Additional Comments From [EMAIL PROTECTED] 2007-03-14 03:13 --- > Any news on that bug please ? None whatsoever. Three people are reporting this and it's a drop-dead showstopper for a 2.6.21 release so we just have to wait until someone wakes up and thinks about it. It would be very useful if one of the reporters could perform a git-bisect search to identify the offending change, please. I would dearly like to point you at a document or web page which describes kernel-git-bisect-for-newbies, but afaik there isn't such a thing, which is a huge failing. "Linux testers handbook" should be translated in a few weeks. Here is a "git-bisect basics" movie :) http://www.youtube.com/watch?v=R7_LY-ceFbE Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [6/6] 2.6.21-rc3: known regressions
On Tue, Mar 13, 2007 at 09:05:28PM +0100, Thomas Gleixner wrote: > On Tue, 2007-03-13 at 13:50 +0100, Adrian Bunk wrote: > > Subject: hrtimer_switch_to_hres(): > > wrong tick_init_highres() return value handling > > References : http://lkml.org/lkml/2007/3/6/262 > > Submitter : Linus Torvalds <[EMAIL PROTECTED]> > > Caused-By : Thomas Gleixner <[EMAIL PROTECTED]> > > commit 54cdfdb47f73b5af3d1ebb0f1e383efbe70fde9e > > Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> > > Status : unknown > > Linus merged the original patch, which solved the real problem. > > He just gave me a lesson how to do it right next time. Sorry, my fault. > tglx 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/
XFS internal error xfs_da_do_buf(2) at line 2087 of file fs/xfs/xfs_da_btree.c. Caller 0xc01b00bd
Hello everybody. Since 2.6.19.2 + commit 7fbbb01dca7704d52ace6f45a805c98a5b0362f9 I'm experimenting these errors. 2.6.19.1 has been worked good for more than 30 days. I have reverted back to 2.6.19.1 to see if this problem happens again. sda8 is a 280GB xfs filesystem which hosts the squid file cache. I don't know if this bug may be related to the used% size on this file system. May anoybody point me the step to try to spot this bug? TIA Here is dmesg: Mar 2 16:31:15 Pleiadi kernel: BUG: unable to handle kernel paging request at virtual address a0814e49 Mar 2 16:31:15 Pleiadi kernel: printing eip: Mar 2 16:31:15 Pleiadi kernel: c013c22d Mar 2 16:31:15 Pleiadi kernel: *pde = Mar 2 16:31:15 Pleiadi kernel: Oops: [#1] Mar 2 16:31:15 Pleiadi kernel: SMP Mar 2 16:31:15 Pleiadi kernel: Modules linked in: nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_ftp nf_conntrack_ftp e1000 tg3 Mar 2 16:31:15 Pleiadi kernel: CPU:0 Mar 2 16:31:15 Pleiadi kernel: EIP:0060:[]Not tainted VLI Mar 2 16:31:15 Pleiadi kernel: EFLAGS: 00010082 (2.6.20 #1) Mar 2 16:31:15 Pleiadi kernel: EIP is at find_lock_page+0x39/0x9c Mar 2 16:31:15 Pleiadi kernel: eax: a0814e49 ebx: a0814e49 ecx: fffa edx: a0814e49 Mar 2 16:31:15 Pleiadi kernel: esi: f7e28694 edi: f7e286a4 ebp: 01e452a8 esp: eb585b38 Mar 2 16:31:15 Pleiadi kernel: ds: 007b es: 007b ss: 0068 Mar 2 16:31:15 Pleiadi kernel: Process squid (pid: 29819, ti=eb584000 task=c1969550 task.ti=eb584000) Mar 2 16:31:15 Pleiadi kernel: Stack: f7e28698 f4f96380 0250 01e452a8 c013c2c7 0250 f7e28694 Mar 2 16:31:15 Pleiadi kernel:c1330ce0 f4f96380 1000 c01e8caf c01e8a0a f4f96380 f7ed37f4 Mar 2 16:31:15 Pleiadi kernel:0001 c03bee20 c03bee20 01e452a7 00010001 0250 1000 Mar 2 16:31:15 Pleiadi kernel: Call Trace: Mar 2 16:31:15 Pleiadi kernel: [] find_or_create_page+0x37/0x8e Mar 2 16:31:15 Pleiadi kernel: [] _xfs_buf_lookup_pages+0x132/0x2ea Mar 2 16:31:15 Pleiadi kernel: [] _xfs_buf_initialize+0xc8/0xf6 Mar 2 16:31:15 Pleiadi kernel: [] xfs_buf_get_flags+0xf8/0x11d Mar 2 16:31:15 Pleiadi kernel: [] xfs_buf_read_flags+0x1c/0x7f Mar 2 16:31:15 Pleiadi kernel: [] xfs_trans_read_buf+0x16a/0x34f Mar 2 16:31:15 Pleiadi kernel: [] xfs_itobp+0x7c/0x242 Mar 2 16:31:15 Pleiadi kernel: [] xfs_iread+0x68/0x1d3 Mar 2 16:31:15 Pleiadi kernel: [] xfs_dir2_leaf_lookup+0xd8/0xe2 Mar 2 16:31:15 Pleiadi kernel: [] xfs_iget_core+0xe7/0x687 Mar 2 16:31:15 Pleiadi kernel: [] xfs_iget+0xd8/0x150 Mar 2 16:31:15 Pleiadi kernel: [] xfs_dir_lookup_int+0x98/0x10e Mar 2 16:31:15 Pleiadi kernel: [] xfs_lookup+0x5a/0x90 Mar 2 16:31:15 Pleiadi kernel: [] xfs_vn_lookup+0x52/0x93 Mar 2 16:31:15 Pleiadi kernel: [] real_lookup+0xbb/0x116 Mar 2 16:31:15 Pleiadi kernel: [] do_lookup+0x90/0xc2 Mar 2 16:31:15 Pleiadi kernel: [] xfs_vn_lookup+0x0/0x93 Mar 2 16:31:15 Pleiadi kernel: [] __link_path_walk+0x727/0xcf1 Mar 2 16:31:15 Pleiadi kernel: [] link_path_walk+0x3e/0xac Mar 2 16:31:15 Pleiadi kernel: [] get_unused_fd+0x2e/0xb6 Mar 2 16:31:15 Pleiadi kernel: [] do_path_lookup+0x11a/0x1ba Mar 2 16:31:15 Pleiadi kernel: [] __path_lookup_intent_open+0x50/0x90 Mar 2 16:31:15 Pleiadi kernel: [] path_lookup_open+0x20/0x25 Mar 2 16:31:15 Pleiadi kernel: [] open_namei+0x7a/0x550 Mar 2 16:31:15 Pleiadi kernel: [] do_wp_page+0x20e/0x3e8 Mar 2 16:31:15 Pleiadi kernel: [] do_filp_open+0x2e/0x5b Mar 2 16:31:15 Pleiadi kernel: [] get_unused_fd+0x2e/0xb6 Mar 2 16:31:15 Pleiadi kernel: [] do_sys_open+0x4e/0xdb Mar 2 16:31:15 Pleiadi kernel: [] sys_open+0x1c/0x20 Mar 2 16:31:15 Pleiadi kernel: [] syscall_call+0x7/0xb Mar 2 16:31:15 Pleiadi kernel: === Mar 2 16:31:15 Pleiadi kernel: Code: 89 c6 89 f8 89 6c 24 10 89 5c 24 04 89 d5 e8 85 80 1b 00 8d 46 04 89 04 24 89 ea 8b 04 24 e8 6d ea 0c 00 85 c0 89 c3 74 35 89 c2 <8b> 00 f6 c4 40 75 57 f0 ff 42 04 f0 0f ba 2b 00 19 c0 85 c0 74 Mar 2 16:31:15 Pleiadi kernel: EIP: [] find_lock_page+0x39/0x9c SS:ESP 0068:eb585b38 Mar 12 13:03:37 Pleiadi kernel: sanitize start Mar 12 13:03:37 Pleiadi kernel: sanitize end Mar 12 13:03:37 Pleiadi kernel: copy_e820_map() start: size: 0009ac00 end: 0009ac00 type: 1 Mar 12 13:03:37 Pleiadi kernel: copy_e820_map() type is E820_RAM Mar 12 13:03:37 Pleiadi kernel: copy_e820_map() start: 0009ac00 size: 5400 end: 000a type: 2 Mar 12 13:03:37 Pleiadi kernel: copy_e820_map() start: 000ce000 size: 2000 end: 000d type: 2 Mar 12 13:03:37 Pleiadi kernel: copy_e820_map() start: 000e size: 0002 end: 0010 type: 2 Mar 12 13:03:37 Pleiadi kernel: copy_e820_map() start: 0010 size: 3fdf end: 3fef type: 1 Mar 12 13:03:37 Pleiadi kernel: copy_e820_map() type is E820_RAM Mar 12 13:03:37 Pleia
Re: [6/6] 2.6.21-rc3: known regressions
On Tue, Mar 13, 2007 at 09:46:17PM +0100, Thomas Gleixner wrote: > On Tue, 2007-03-13 at 13:50 +0100, Adrian Bunk wrote: > > This email lists some known regressions in Linus' tree compared to 2.6.20. > > > > If you find your name in the Cc header, you are either submitter of one > > of the bugs, maintainer of an affectected subsystem or driver, a patch > > of you caused a breakage or I'm considering you in any other way > > possibly involved with one or more of these issues. > > > > Due to the huge amount of recipients, please trim the Cc when answering. > > Subject: Clocksource tsc unstable (delta = -154983451 ns) > > References : http://lkml.org/lkml/2007/3/9/271 > > Submitter : Jiri Slaby <[EMAIL PROTECTED]> > > Status : unknown > > That's not a regression. That's an informal message, when the TSC > watchdog detects that the TSC is unreliable. Looking at [1], there's also be a probably related "doesn't boot" problem. My first guess would be commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd "clocksource init adjustments (fix bug #7426)". Jiri, is the message also present with 2.6.21-rc2 (at a different place of the dmesg) for you? > tglx cu Adrian [1] http://lkml.org/lkml/2007/3/13/219 -- "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: oops in __nodemgr_remove_host_dev
I wrote: > As a side note, the IEEE 1394 subsystem features quite a fat usage of > the driver core. [...] Maybe we should redesign nodemgr to work without > host devices and node entry devices. Greg, you once indicated you had class device conversion patches for 1394 in the pipeline, but they couldn't go out to -mm or wherever because of them depending on unfinished driver core changes. If you found that the 1394 subsystem needed some special treatment, there might be a chance to eliminate this by pulling some historically grown but now obsolete infrastructure out. (Of course not for 2.6.21-rc anymore, but perhaps post 2.6.21 if we take it on quickly.) -- Stefan Richter -=-=-=== --== -===- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ooops with suspend to RAM
On Wed, Mar 14, 2007 at 06:42:28AM +0200, Ismail Dönmez wrote: > Hi all, > > With latest GIT tree I am getting the following oops when I try to suspend to > RAM: >... Is this an old problem, or what was the last kernel that worked for you? 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: kernel BUG at mm/slab.c:610
Marco Berizzi wrote: > Pekka Enberg wrote: > > Hi Pekka, > > > So, can you please repost the original oops? > > Here is: > > Mar 14 03:42:25 Mimosa kernel: [ cut here ] > Mar 14 03:42:25 Mimosa kernel: kernel BUG at mm/slab.c:610! > Mar 14 03:42:25 Mimosa kernel: invalid opcode: [#1] > Mar 14 03:42:25 Mimosa kernel: Modules linked in: sch_sfq sch_htb cls_fw > nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre > nf_nat_ftp nf_conntrack_ftp 3c59x mii > Mar 14 03:42:25 Mimosa kernel: CPU:0 > Mar 14 03:42:25 Mimosa kernel: EIP:0060:[]Not tainted > VLI > Mar 14 03:42:25 Mimosa kernel: EFLAGS: 00010046 (2.6.20 #1) > Mar 14 03:42:25 Mimosa kernel: EIP is at free_block+0xd9/0xf0 > Mar 14 03:42:25 Mimosa kernel: eax: 0008 ebx: c100 ecx: > c0e7d4e0 edx: c101cfa0 > Mar 14 03:42:25 Mimosa kernel: esi: c121 edi: c1176560 ebp: > esp: c119bef0 > Mar 14 03:42:25 Mimosa kernel: ds: 007b es: 007b ss: 0068 > Mar 14 03:42:25 Mimosa kernel: Process events/0 (pid: 3, ti=c119a000 > task=c118f030 task.ti=c119a000) > Mar 14 03:42:25 Mimosa kernel: Stack: c1213a10 161c9ed5 c1210010 > c1210010 c121 161c9ed5 c1176560 c014d201 > Mar 14 03:42:25 Mimosa kernel: c1180420 c1176560 > c1180d60 c014d220 c014d26b > Mar 14 03:42:25 Mimosa kernel:c03b7ae0 c03b7ae0 0282 > c0123d37 c118f13c 007b 508b > Mar 14 03:42:25 Mimosa kernel: Call Trace: > Mar 14 03:42:25 Mimosa kernel: [] drain_array+0x91/0xb0 > Mar 14 03:42:25 Mimosa kernel: [] cache_reap+0x0/0xf0 > Mar 14 03:42:25 Mimosa kernel: [] cache_reap+0x4b/0xf0 > Mar 14 03:42:25 Mimosa kernel: [] run_workqueue+0x67/0x130 > Mar 14 03:42:25 Mimosa kernel: [] worker_thread+0x13a/0x170 > Mar 14 03:42:25 Mimosa kernel: [] > default_wake_function+0x0/0x10 > Mar 14 03:42:25 Mimosa kernel: [] __wake_up_common+0x37/0x70 > Mar 14 03:42:25 Mimosa kernel: [] > default_wake_function+0x0/0x10 > Mar 14 03:42:25 Mimosa kernel: [] worker_thread+0x0/0x170 > Mar 14 03:42:25 Mimosa kernel: [] kthread+0xb6/0xc0 > Mar 14 03:42:25 Mimosa kernel: [] kthread+0x0/0xc0 > Mar 14 03:42:25 Mimosa kernel: [] > kernel_thread_helper+0x7/0x14 > Mar 14 03:42:25 Mimosa kernel: === > Mar 14 03:42:25 Mimosa kernel: Code: ff 83 c4 0c 5b 5e 5f 5d c3 8b 57 20 > 29 d0 89 da 89 46 18 89 f8 e8 78 f1 ff ff eb da 89 33 8b 46 04 89 5e 04 > 89 18 89 43 04 eb cb <0f> 0b 90 8d 74 26 00 eb fe 8b 52 0c e9 57 ff ff > ff 8d b6 00 00 > Mar 14 03:42:25 Mimosa kernel: EIP: [] free_block+0xd9/0xf0 > SS:ESP 0068:c119bef0 Only to tell you, that on the console linux was printing this message: atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 BUG at mm/slab.c:610
On 3/14/07, Marco Berizzi <[EMAIL PROTECTED]> wrote: Only to tell you, that on the console linux was printing this message: atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly. Probably unrelated. CONFIG_SLAB_DEBUG should tell us what's corrupting the slab. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
taskstats accounting info
Hi, Documentation/accounting/delay-accounting.txt says that the getdelays program has a "-c cmd" argument, but that option does not seem to exist in Documentation/account/getdelays.c. Do you have an updated version of getdelays.c? If not, please correct that documentation. Is getdelays.c the best available example of a program using the taskstats netlink interface? Thanks, -- ~Randy PS: Please add your email info to MAINTAINERS or CREDITS or kernel/*.c so that people don't have to search email archives in order to be able to contact you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/2] splice: dont steal
Here are a couple of splice patches I found when digging in the area.
I could be wrong, so I'd appreciate confirmation.
Untested other than compile, because I don't have a good splice test
setup.
Considering these are data corruption / information leak issues, then
we could do worse than to merge them in 2.6.21 and earlier stable
trees.
Does anyone really use splice stealing?
--
Stealing pages with splice is problematic because we cannot just insert
an uptodate page into the pagecache and hope the filesystem can take care
of it later.
We also cannot just ClearPageUptodate, then hope prepare_write does not
write anything into the page, because I don't think prepare_write gives
that guarantee.
Remove support for SPLICE_F_MOVE for now. If we really want to bring it
back, we might be able to do so with a the new filesystem buffered write
aops APIs I'm working on. If we really don't want to bring it back, then
we should decide that sooner rather than later, and remove the flag and
all the stealing infrastructure before anybody starts using it.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/fs/splice.c
===
--- linux-2.6.orig/fs/splice.c
+++ linux-2.6/fs/splice.c
@@ -576,76 +576,51 @@ static int pipe_to_file(struct pipe_inod
if (this_len + offset > PAGE_CACHE_SIZE)
this_len = PAGE_CACHE_SIZE - offset;
- /*
-* Reuse buf page, if SPLICE_F_MOVE is set and we are doing a full
-* page.
-*/
- if ((sd->flags & SPLICE_F_MOVE) && this_len == PAGE_CACHE_SIZE) {
+find_page:
+ page = find_lock_page(mapping, index);
+ if (!page) {
+ ret = -ENOMEM;
+ page = page_cache_alloc_cold(mapping);
+ if (unlikely(!page))
+ goto out_ret;
+
/*
-* If steal succeeds, buf->page is now pruned from the
-* pagecache and we can reuse it. The page will also be
-* locked on successful return.
+* This will also lock the page
*/
- if (buf->ops->steal(pipe, buf))
- goto find_page;
-
- page = buf->page;
- if (add_to_page_cache(page, mapping, index, GFP_KERNEL)) {
- unlock_page(page);
- goto find_page;
- }
-
- page_cache_get(page);
+ ret = add_to_page_cache_lru(page, mapping, index,
+ GFP_KERNEL);
+ if (unlikely(ret))
+ goto out;
+ }
- if (!(buf->flags & PIPE_BUF_FLAG_LRU))
- lru_cache_add(page);
- } else {
-find_page:
- page = find_lock_page(mapping, index);
- if (!page) {
- ret = -ENOMEM;
- page = page_cache_alloc_cold(mapping);
- if (unlikely(!page))
- goto out_ret;
-
- /*
-* This will also lock the page
-*/
- ret = add_to_page_cache_lru(page, mapping, index,
- GFP_KERNEL);
+ /*
+* We get here with the page locked. If the page is also
+* uptodate, we don't need to do more. If it isn't, we
+* may need to bring it in if we are not going to overwrite
+* the full page.
+*/
+ if (!PageUptodate(page)) {
+ if (this_len < PAGE_CACHE_SIZE) {
+ ret = mapping->a_ops->readpage(file, page);
if (unlikely(ret))
goto out;
- }
- /*
-* We get here with the page locked. If the page is also
-* uptodate, we don't need to do more. If it isn't, we
-* may need to bring it in if we are not going to overwrite
-* the full page.
-*/
- if (!PageUptodate(page)) {
- if (this_len < PAGE_CACHE_SIZE) {
- ret = mapping->a_ops->readpage(file, page);
- if (unlikely(ret))
- goto out;
-
- lock_page(page);
-
- if (!PageUptodate(page)) {
- /*
-* Page got invalidated, repeat.
-*/
- if (!page->mapping) {
- unlock_page(page);
- page_cache_release(page);
- goto find_page;
- }
[patch 2/2] splice: dont readpage
Splice does not need to readpage to bring the page uptodate before writing
to it, because prepare_write will take care of that for us.
Splice is also wrong to SetPageUptodate before the page is actually uptodate.
This results in the old uninitialised memory leak. This gets fixed as a
matter of course when removing the readpage logic.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/fs/splice.c
===
--- linux-2.6.orig/fs/splice.c
+++ linux-2.6/fs/splice.c
@@ -593,36 +593,6 @@ find_page:
goto out;
}
- /*
-* We get here with the page locked. If the page is also
-* uptodate, we don't need to do more. If it isn't, we
-* may need to bring it in if we are not going to overwrite
-* the full page.
-*/
- if (!PageUptodate(page)) {
- if (this_len < PAGE_CACHE_SIZE) {
- ret = mapping->a_ops->readpage(file, page);
- if (unlikely(ret))
- goto out;
-
- lock_page(page);
-
- if (!PageUptodate(page)) {
- /*
-* Page got invalidated, repeat.
-*/
- if (!page->mapping) {
- unlock_page(page);
- page_cache_release(page);
- goto find_page;
- }
- ret = -EIO;
- goto out;
- }
- } else
- SetPageUptodate(page);
- }
-
ret = mapping->a_ops->prepare_write(file, page, offset,
offset+this_len);
if (unlikely(ret)) {
loff_t isize = i_size_read(mapping->host);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 8040] Hang before INIT when CONFIG_HIGHMEM4G=y
> > None whatsoever. Three people are reporting this and it's a drop-dead > > showstopper for a 2.6.21 release so we just have to wait until someone > > wakes up and thinks about it. The topic should be "when CONFIG_HIGHMEM64G=y" imo. I'll try to do my first bi-sect today. -- Leroy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/kallsyms race vs module unload
Alexey Dobriyan wrote: On Tue, Mar 13, 2007 at 06:49:50PM +, Paulo Marques wrote: Alexey Dobriyan wrote: [...] What happens is that module_get_kallsym() drops module_mutex, returns "struct module *", module unloaded, "struct module *" used. The only use for the "struct module *" is to display the name of the module. Ehh? This can be solved by adding a "char mod_name[MODULE_NAME_LEN];" field to "kallsym_iter" and copy the name of the module over, while still holding module_mutex. It would be slightly slower, but safer. iter->owner = module_get_kallsym(iter->pos - kallsyms_num_syms, &iter->value, &iter->type, iter->name, sizeof(iter->name)); if (iter->owner == NULL) return 0; /* Label it "global" if it is exported, "local" if not exported. */ iter->type = is_exported(iter->name, iter->owner) ^^^ Yes, there is this "is_exported" call, but his can be moved completely into "module_get_kallsym" and have the "type" returned be already upper / lower case. That, together with filling the module name "module_get_kallsym()" would make the returned "struct module *" unneeded. Since kallsyms is the only caller of that function, we can change its interface to not return a "struct module *" at all, and return just an integer that means "symbol found" or "no more symbols". I'm still volunteering to do that patch, but you seem more active than me at the moment... -- Paulo Marques Software Development Department - Grupo PIE, S.A. Phone: +351 252 290600, Fax: +351 252 290601 Web: www.grupopie.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] ahci.c: fix ati sb600 sata IRQ_TF_ERR
Hello,
Conke Hu wrote:
>When there is no media in SATA CD/DVD drive or media is not ready,
> AHCI controller fails to execute the ATAPI commands TEST_UNIT_READY,
> READ_CAPACITY or READ_TOC and reports PORT_IRQ_TF_ERR. But ATI SB600
> SATA controller sets SERR_INTERNAL bit in the error register at the
> same time, which is not necessary. This patch is just to ignore the
> INTERNAL ERROR in such case. Without this patch, ahci error handler
> will report many errors as below:
Whoa, SERR_INTERNAL on ATAPI check condition? Just for fun, here's what
the spec says about SERR_INTERNAL.
E Internal error: The host bus adapter experienced an internal error
that caused the operation to fail and may have put the host bus adapter
into an error state. Host software should reset the interface before
re-trying the operation. If the condition persists, the host bus adapter
may suffer from a design issue rendering it incompatible with the
attached device.
Anyways thanks for fixing this. Just a few comments.
> --- linux-2.6.21-rc3-git8/drivers/ata/ahci.c.orig2007-03-25
> 20:57:31.0 +0800
> +++ linux-2.6.21-rc3-git8/drivers/ata/ahci.c2007-03-25
> 21:03:54.0 +0800
> @@ -80,6 +80,7 @@ enum {
> board_ahci_pi= 1,
> board_ahci_vt8251= 2,
> board_ahci_ign_iferr= 3,
> +board_ahci_ati= 4,
>
> /* global controller registers */
> HOST_CAP= 0x00, /* host capabilities */
> @@ -168,6 +169,7 @@ enum {
> AHCI_FLAG_NO_NCQ= (1 << 24),
> AHCI_FLAG_IGN_IRQ_IF_ERR= (1 << 25), /* ignore IRQ_IF_ERR */
> AHCI_FLAG_HONOR_PI= (1 << 26), /* honor PORTS_IMPL */
> +AHCI_FLAG_TF_ERR_FIX= (1 << 27), /* ignore INTERNAL ERROR on
> IRQ_TF_ERROR */
Can we use board_ahci_ign_interr and AHCI_FLAG_IGN_SERR_INTERNAL to keep
it more consistent with the other IGN flag?
> -{ PCI_VDEVICE(ATI, 0x4380), board_ahci }, /* ATI SB600 non-raid */
> +{ PCI_VDEVICE(ATI, 0x4380), board_ahci_ati }, /* ATI SB600 non-raid */
> { PCI_VDEVICE(ATI, 0x4381), board_ahci }, /* ATI SB600 raid */
4381 isn't affected while 4380 is?
Hmmm... Okay, this is weird. I'm feeling very strong deja vu.
Well, I must be getting alzheimer. I did almost the same patch a month
ago and was waiting for verification to properly submit the patch.
http://thread.gmane.org/gmane.linux.ide/16049/focus=16437
Anyways, Conke Hu, can you please take a look at my patch from a month
ago? It's almost identical but SERR_INTERNAL is always ignored on both
SB600 PCI IDs, which I think is safer. Does this fix what you're seeing?
Thanks.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [6/6] 2.6.21-rc3: known regressions
Adrian Bunk napsal(a): On Tue, Mar 13, 2007 at 09:46:17PM +0100, Thomas Gleixner wrote: On Tue, 2007-03-13 at 13:50 +0100, Adrian Bunk wrote: This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: Clocksource tsc unstable (delta = -154983451 ns) References : http://lkml.org/lkml/2007/3/9/271 Submitter : Jiri Slaby <[EMAIL PROTECTED]> Status : unknown That's not a regression. That's an informal message, when the TSC watchdog detects that the TSC is unreliable. Looking at [1], there's also be a probably related "doesn't boot" problem. My first guess would be commit 6bb74df481223731af6c7e0ff3adb31f6442cfcd "clocksource init adjustments (fix bug #7426)". Jiri, is the message also present with 2.6.21-rc2 (at a different place of the dmesg) for you? Yes, it's present there too, some lines below the place, where it is placed in -rc3. regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: taskstats accounting info
Randy.Dunlap wrote: Hi, Documentation/accounting/delay-accounting.txt says that the getdelays program has a "-c cmd" argument, but that option does not seem to exist in Documentation/account/getdelays.c. Do you have an updated version of getdelays.c? If not, please correct that documentation. Yes, I did, but then I changed my laptop. I should have it archived at some place, I'll dig it out or correct the documentation. Is getdelays.c the best available example of a program using the taskstats netlink interface? It's the most portable example, since it does not depend on libnl. It needs some cleaning up. I hope to get to it after the OLS paper submission deadline. Thanks, Thanks for bringing the issue to my notice, -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 58/59] sysctl: Reimplement the sysctl proc support
* Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> On 3/14/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > #define PROCNAME_PML"sys/kernel/preempt_max_latency"
> >
> > static __init int latency_fs_init(void)
> > {
> > struct proc_dir_entry *entry;
> >
> > if (!(entry = create_proc_entry(PROCNAME_PML, 0644, NULL)))
> > printk("latency_fs_init(): can't create %s\n",
> >PROCNAME_PML);
> >
> > with your change that broke because beyond /proc/sys/ there are no
> > real proc entries anymore, there's no de->subdir directory for
> > xlate_proc_name() to find. While the latency tracer isnt upstream,
> > this change in semantics does not seem to be intended (the changelog
> > is certainly silent about it).
>
> Use register_sysctl_table() for sysctls.
yes - i just wanted to point out the incompatibility and subtle breakage
that this change caused. I'll now have to convert the current code over
to sysctl_table, which isnt that hard but not trivial either, and i
certainly could make use that time for other purposes.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [Patch 1/1] IBAC Patch
On Tue, 2007-03-13 at 10:31 -0500, Serge E. Hallyn wrote: > Quoting Mimi Zohar ([EMAIL PROTECTED]): > > On Thu, 2007-03-08 at 22:19 -0500, [EMAIL PROTECTED] wrote: > > > On Thu, 08 Mar 2007 17:58:16 EST, Mimi Zohar said: > > > > This is a request for comments for a new Integrity Based Access > > > > Control(IBAC) LSM module which bases access control decisions > > > > on the new integrity framework services. > > > > > > > > (Hopefully this will help clarify the interaction between an LSM > > > > module and LIM module.) > > > > > > OK, between this and the additional LIM hooks I didn't notice in an > > > earlier > > > patch, we're starting to see the API. The only problem is that although > > > it may be the right API for *your* code, I suspect it's a non-starter > > > without > > > a discussion about whether it's the right *generic* API for an LIM (which > > > will > > > require at least one dramatic bun fight about what "Integrity" means). > > > > Absolutely, we need to make sure that the set of LIM hooks is complete and > > that > > nothing is missing in order to implement different types of LIM providers. > > I'm > > copying the digsig mailing list for their input on requirements, which this > > API > > might not satisfy or perhaps address. > > (Could you resend the IBAC patch to the disec list as well?) Sure, I'm just about to post a new version of IBAC with the changes based on comments from the lsm and lkml lists. > Is IBAC basically a 'demo' lsm? It only hooks bprm_security, so you > can't execute anything with a bad hash, right? So really if you were to > also hook mmap, this would completely do away with the need for digsig? > IBAC is automatically able to use any integrity measurement modules you > write, whether they use gpg like digsig does right now, or use the tpm? You're absolutely correct on all accounts. > It also shows how simple it would be to hook selinux, though I guess > there are several ways we might want to hook selinux - 1. to check only > security.selinux xattrs, 2. to check integrity of entry point types, 3. > to check integrity of any files labeled by the integrity measurement > module as needing to be checked. Correct. Verifying the integrity of security.selinux xattrs would require adding security.selinux to /etc/evm.conf and calls within SELinux to integrity_verify_metadata() as needed. Verifying the integrity of files, would require labeling the files with integrity measurements and adding calls within SELinux to integrity_verify_data() as needed. > Is there any way for the LSM itself to direct which data and metadata > will be measured? It looks like this is done by separately configuring > the integrity measurement module - which seems fine to me. Actually the current EVM implementation as an integrity provider relies on an LSM module, or for that matter any other kernel module, to make calls to the integrity API: integrity_verify_metadata(), integrity_verify_data(), and integrity_measure(). The decision as to which files are to be measured is left up to the LSM module. For example, as you previously noted, IBAC only verifies the metadata and data integrity of executables, whereas SLIM verifies the metadata and data integrity of SYSTEM level files and all executables. Mimi Zohar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] [Patch 1/1] IBAC Patch
This is a posting of an updated IBAC patch, based on comments from the
LSM and LKML mailing lists, which include the following fixes:
- Updated Kconfig SECURITY_IBAC description
and SECURITY_IBAC_BOOTPARAM default value
- Prefixed all log messages with "ibac:"
- Redefined a couple of 'int' variables as 'static int'
This is a request for comments for a new Integrity Based Access
Control(IBAC) LSM module which bases access control decisions
on the new integrity framework services.
(Hopefully this will help clarify the interaction between an LSM
module and LIM module.)
Index: linux-2.6.21-rc3-mm2/security/ibac/Kconfig
===
--- /dev/null
+++ linux-2.6.21-rc3-mm2/security/ibac/Kconfig
@@ -0,0 +1,41 @@
+config SECURITY_IBAC
+ boolean "IBAC support"
+ depends on SECURITY && SECURITY_NETWORK && INTEGRITY
+ help
+ Integrity Based Access Control(IBAC) uses the Linux
+ Integrity Module(LIM) API calls to verify an executable's
+ metadata and data's integrity. Based on the results,
+ execution permission is permitted/denied. Integrity
+ providers may implement the LIM hooks differently. For
+ more information on integrity verification refer to the
+ specific integrity provider documentation.
+
+config SECURITY_IBAC_BOOTPARAM
+ bool "IBAC boot parameter"
+ depends on SECURITY_IBAC
+ default n
+ help
+ This option adds a kernel parameter 'ibac', which allows IBAC
+ to be disabled at boot. If this option is selected, IBAC
+ functionality can be disabled with ibac=0 on the kernel
+ command line. The purpose of this option is to allow a
+ single kernel image to be distributed with IBAC built in,
+ but not necessarily enabled.
+
+ If you are unsure how to answer this question, answer N.
+
+config SECURITY_IBAC_BOOTPARAM_VALUE
+ int "IBAC boot parameter default value"
+ depends on SECURITY_IBAC_BOOTPARAM
+ range 0 1
+ default 0
+ help
+ This option sets the default value for the kernel parameter
+ 'ibac', which allows IBAC to be disabled at boot. If this
+ option is set to 0 (zero), the IBAC kernel parameter will
+ default to 0, disabling IBAC at bootup. If this option is
+ set to 1 (one), the IBAC kernel parameter will default to 1,
+ enabling IBAC at bootup.
+
+ If you are unsure how to answer this question, answer 0.
+
Index: linux-2.6.21-rc3-mm2/security/ibac/Makefile
===
--- /dev/null
+++ linux-2.6.21-rc3-mm2/security/ibac/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for building IBAC
+#
+
+obj-$(CONFIG_SECURITY_IBAC) += ibac.o
+ibac-y := ibac_main.o
Index: linux-2.6.21-rc3-mm2/security/ibac/ibac_main.c
===
--- /dev/null
+++ linux-2.6.21-rc3-mm2/security/ibac/ibac_main.c
@@ -0,0 +1,126 @@
+/*
+ * Integrity Based Access Control (IBAC)
+ *
+ * Copyright (C) 2007 IBM Corporation
+ * Author: Mimi Zohar <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_SECURITY_IBAC_BOOTPARAM
+static int ibac_enabled = CONFIG_SECURITY_IBAC_BOOTPARAM_VALUE;
+
+static int __init ibac_enabled_setup(char *str)
+{
+ ibac_enabled = simple_strtol(str, NULL, 0);
+ return 1;
+}
+
+__setup("ibac=", ibac_enabled_setup);
+#else
+static int ibac_enabled = 0;
+#endif
+
+static unsigned int integrity_enforce;
+static int __init integrity_enforce_setup(char *str)
+{
+ integrity_enforce = simple_strtol(str, NULL, 0);
+ return 1;
+}
+
+__setup("ibac_enforce=", integrity_enforce_setup);
+
+#define XATTR_NAME "security.evm.hash"
+
+static inline int is_kernel_thread(struct task_struct *tsk)
+{
+ return (!tsk->mm) ? 1 : 0;
+}
+
+static int ibac_bprm_check_security(struct linux_binprm *bprm)
+{
+ struct dentry *dentry = bprm->file->f_dentry;
+ int xattr_len;
+ char *xattr_value = NULL;
+ int rc, status;
+
+ rc = integrity_verify_metadata(dentry, XATTR_NAME,
+ &xattr_value, &xattr_len, &status);
+ if (rc == -EOPNOTSUPP) {
+ kfree(xattr_value);
+ return 0;
+ }
+
+ if (rc < 0) {
+ printk(KERN_INFO "ibac: verify_metadata %s failed "
+ "(rc: %d - status: %d)\n", bprm->filename, rc, status);
+ if (!integrity_enforce)
+ rc = 0;
+ goto out;
+ }
+ if (status != INTEGRITY_PASS) { /* FAIL | NO_LABEL */
+ i
Re: [PATCH 1/2] avoid OPEN_MAX in SCM_MAX_FD
Hi, On 14 Mar 2007, at 01:15, Linus Torvalds wrote: On Tue, 13 Mar 2007, Roland McGrath wrote: Ok, fine. But PATH_MAX is a real constant that has some meaning in the kernel. It's perfectly correct to use PATH_MAX as a constant on a system like Linux that defines it and means what it says. Conversely, OPEN_MAX has no useful relationship with anything the kernel is doing at all. Sure. I'm just saying that some people may use OPEN_MAX the way I know people use PATH_MAX - whether it's what you're supposed to or not. To contribute a data point here: searching for the regular expression \[\ *OPEN_MAX\ *\] on google code search [1] gives 25 hits for me. Replacing OPEN_MAX with PATH_MAX results in "about 19,700" hits. [1] http://www.google.com/codesearch?hl=en&q=+%5C%5B%5C+*OPEN_MAX%5C+* %5C%5D&start=20&sa=N I hope this helps, Jochen -- http://seehuhn.de/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] iproute2 2.6.20-070313
On Tuesday 13 of March 2007, Stephen Hemminger wrote: > This is an experimental to the iproute2 command set. > > The version number includes the kernel version to denote what features are > supported. The same source should build on older systems, but obviously the > newer kernel features won't be available. As much as possible, this package > tries to be source compatible across releases. > > It can be downloaded from: > > http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.20-070313.tar. >gz This patch http://www.mail-archive.com/netdev@vger.kernel.org/msg27506.html didn't make into upstream linux kernel it seems. The question is - are patches adding some functionality that's not in upstream kernel accepted? There is one wrr patch for iproute floating around that I'm thinking about. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] iproute2 2.6.20-070313
On Wednesday 14 of March 2007, Arkadiusz Miskiewicz wrote: Of course I mean: > This patch > > http://www.mail-archive.com/netdev@vger.kernel.org/msg27506.html > adds functionality that... > didn't make into upstream linux kernel it seems. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [Patch 1/1] IBAC Patch
On Tue, 2007-03-13 at 19:27 -0700, Seth Arnold wrote:
> On Thu, Mar 08, 2007 at 05:58:16PM -0500, Mimi Zohar wrote:
> > This is a request for comments for a new Integrity Based Access
> > Control(IBAC) LSM module which bases access control decisions
> > on the new integrity framework services.
>
> Thanks Mimi, nice to see an example of how the integrity framework ought
> to be used.
>
> > (Hopefully this will help clarify the interaction between an LSM
> > module and LIM module.)
>
> Is this module intended to clarify an interface, or be useful in and of
> itself?
It's a little bit of both. :-) Initially it was written to help me with
implementing and testing the integrity provider. But it could definitely stand
on it's own. As Serge Hallyn commented http://lkml.org/lkml/2007/3/13/220, by
adding the mmap hook, IBAC could replace the LSM aspect of digsig and a gpg
based integrity provider, could be written, instead of EVM, which is TPM based.
> > Index: linux-2.6.21-rc3-mm2/security/ibac/Makefile
> > ===
> > --- /dev/null
> > +++ linux-2.6.21-rc3-mm2/security/ibac/Makefile
> > @@ -0,0 +1,6 @@
> > +#
> > +# Makefile for building IBAC
> > +#
> > +
> > +obj-$(CONFIG_SECURITY_IBAC) += ibac.o
> > +ibac-y := ibac_main.o
> > Index: linux-2.6.21-rc3-mm2/security/ibac/ibac_main.c
> > ===
> > --- /dev/null
> > +++ linux-2.6.21-rc3-mm2/security/ibac/ibac_main.c
> > @@ -0,0 +1,126 @@
> > +/*
> > + * Integrity Based Access Control (IBAC)
> > + *
> > + * Copyright (C) 2007 IBM Corporation
> > + * Author: Mimi Zohar <[EMAIL PROTECTED]>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify
> > + * it under the terms of the GNU General Public License as published
> > by
> > + * the Free Software Foundation, version 2 of the License.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#ifdef CONFIG_SECURITY_IBAC_BOOTPARAM
> > +int ibac_enabled = CONFIG_SECURITY_IBAC_BOOTPARAM_VALUE;
> > +
> > +static int __init ibac_enabled_setup(char *str)
> > +{
> > + ibac_enabled = simple_strtol(str, NULL, 0);
> > + return 1;
> > +}
> > +
> > +__setup("ibac=", ibac_enabled_setup);
> > +#else
> > +int ibac_enabled = 0;
> > +#endif
>
> If the command line option isn't enabled, how will ibac_enabled ever be
> set to '1'? Have I overlooked or forgotten some helper routine elsewhere?
I guess I was a bit over zealous in preventing IBAC from running
unintentionally. Will fix in the next IBAC patch release.
> > +static unsigned int integrity_enforce = 0;
> > +static int __init integrity_enforce_setup(char *str)
> > +{
> > + integrity_enforce = simple_strtol(str, NULL, 0);
> > + return 1;
> > +}
> > +
> > +__setup("ibac_enforce=", integrity_enforce_setup);
> > +
> > +#define XATTR_NAME "security.evm.hash"
>
> Is this name unique to this IBAC module? Or should it be kept in sync
> with the integrity framework?
In order to verify the metadata integrity, an xattr needs to be
specified on the integrity_verify_metadata() call. As IBAC does not
define an xattr of its own, I used this one, which at the time worked.
But as EVM is only one integrity provider, this probably is not a good
idea. To resolve this problem, I guess the integrity_verify_metadata()
API call should respond without requiring an actual xattr.
> > +static inline int is_kernel_thread(struct task_struct *tsk)
> > +{
> > + return (!tsk->mm) ? 1 : 0;
> > +}
> > +
> > +static int ibac_bprm_check_security(struct linux_binprm *bprm)
> > +{
> > + struct dentry *dentry = bprm->file->f_dentry;
> > + int xattr_len;
> > + char *xattr_value = NULL;
> > + int rc, status;
> > +
> > + rc = integrity_verify_metadata(dentry, XATTR_NAME,
> > + &xattr_value, &xattr_len, &status);
> > + if (rc < 0 && rc == -EOPNOTSUPP) {
> > + kfree(xattr_value);
> > + return 0;
> > + }
> > +
> > + if (rc < 0) {
> > + printk(KERN_INFO "verify_metadata %s failed "
> > + "(rc: %d - status: %d)\n", bprm->filename, rc, status);
> > + if (!integrity_enforce)
> > + rc = 0;
> > + goto out;
> > + }
> > + if (status != INTEGRITY_PASS) { /* FAIL | NO_LABEL */
> > + if (!is_kernel_thread(current)) {
>
> Please remind me why kernel threads are exempt?
You really don't want to prevent kernel threads from working. Nasty things
happen.
> > + printk(KERN_INFO "verify_metadata %s "
> > + "(Integrity status: FAIL)\n", bprm->filename);
>
> Integrity status may be FAIL or NO_LABEL at this point -- would it be
> more useful to report the whole truth?
FAIL here indicates that the integrity of the metadata was bad, while
NOLABEL indicates, in the case of EVM, that there was no HMAC. I'll
upd
[PATCH] Race between cat /proc/kallsyms and rmmod
Iterating code of /proc/kallsyms calls module_get_kallsym() which grabs
and drops module_mutex internally and returns "struct module *",
module is removed, aforementioned "struct module *" is used in non-trivial
way.
So, grab module_mutex for entire operation like /proc/modules does.
Steps to reproduce:
while true; do modprobe xfs; rmmod xfs; done
vs
while true; do cat /proc/kallsyms >/dev/null; done
[where xfs could be any module, I haven't tried]
BUG: unable to handle kernel paging request at virtual address e19f808c
printing eip:
c01dc361
*pde = 1ff5f067
*pte =
Oops: [#1]
PREEMPT
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010297 (2.6.21-rc3-8b9909ded6922c33c221b105b26917780cfa497d #2)
EIP is at vsnprintf+0x2af/0x48c
eax: e19f808c ebx: ecx: e19f808c edx: fffe
esi: dbe7aa84 edi: dbe2bf3c ebp: esp: dbe2bec4
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process cat (pid: 7242, ti=dbe2b000 task=df5790b0 task.ti=dbe2b000)
Stack: e19d6fde 0010 0008 0001 0598 dbe7aa68
0002f362 0010 dbe7b000 c034bbe0 dbe7aa68 dfd31880
dfa31e80 1000 c01586b0 dbe2bf2c dbe2bf2c dfd31880 dfd31880 c01289f6
Call Trace:
[] seq_printf+0x2e/0x4b
[] s_show+0x4b/0x7f
[] seq_read+0x196/0x278
[] seq_read+0x0/0x278
[] vfs_read+0x72/0x93
[] sys_read+0x41/0x67
[] sysenter_past_esp+0x5f/0x85
===
Code: 74 24 28 73 03 c6 06 20 46 4d 85 ed 7f f1 e9 b9 00 00 00 8b 0f 81 f9 ff
0f 00 00 b8 ea 45 36 c0 0f 46 c8 8b 54 24 30 89 c8 eb 06 <80> 38 00 74 07 40 4a
83 fa ff 75 f4 29 c8 89 c3 89 e8 f6 44 24
EIP: [] vsnprintf+0x2af/0x48c SS:ESP 0068:dbe2bec4
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
kernel/kallsyms.c |4
kernel/module.c |5 +
2 files changed, 5 insertions(+), 4 deletions(-)
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -40,6 +40,8 @@ extern const u16 kallsyms_token_index[]
extern const unsigned long kallsyms_markers[] __attribute__((weak));
+extern struct mutex module_mutex;
+
static inline int is_kernel_inittext(unsigned long addr)
{
if (addr >= (unsigned long)_sinittext
@@ -369,6 +371,7 @@ static void *s_next(struct seq_file *m,
static void *s_start(struct seq_file *m, loff_t *pos)
{
+ mutex_lock(&module_mutex);
if (!update_iter(m->private, *pos))
return NULL;
return m->private;
@@ -376,6 +379,7 @@ static void *s_start(struct seq_file *m,
static void s_stop(struct seq_file *m, void *p)
{
+ mutex_unlock(&module_mutex);
}
static int s_show(struct seq_file *m, void *p)
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -62,7 +62,7 @@ #define INIT_OFFSET_MASK (1UL << (BITS_P
static DEFINE_SPINLOCK(modlist_lock);
/* List of modules, protected by module_mutex AND modlist_lock */
-static DEFINE_MUTEX(module_mutex);
+DEFINE_MUTEX(module_mutex);
static LIST_HEAD(modules);
static BLOCKING_NOTIFIER_HEAD(module_notify_list);
@@ -2124,19 +2124,16 @@ struct module *module_get_kallsym(unsign
{
struct module *mod;
- mutex_lock(&module_mutex);
list_for_each_entry(mod, &modules, list) {
if (symnum < mod->num_symtab) {
*value = mod->symtab[symnum].st_value;
*type = mod->symtab[symnum].st_info;
strlcpy(name, mod->strtab + mod->symtab[symnum].st_name,
namelen);
- mutex_unlock(&module_mutex);
return mod;
}
symnum -= mod->num_symtab;
}
- mutex_unlock(&module_mutex);
return 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/
Re: [PATCH] Race between cat /proc/kallsyms and rmmod
Alexey Dobriyan <[EMAIL PROTECTED]> writes: > > --- a/kernel/kallsyms.c > +++ b/kernel/kallsyms.c > @@ -40,6 +40,8 @@ extern const u16 kallsyms_token_index[] > > extern const unsigned long kallsyms_markers[] __attribute__((weak)); > > +extern struct mutex module_mutex; No externs in .c files -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] Race between cat /proc/kallsyms and rmmod
Iterating code of /proc/kallsyms calls module_get_kallsym() which grabs
and drops module_mutex internally and returns "struct module *",
module is removed, aforementioned "struct module *" is used in non-trivial
way.
So, grab module_mutex for entire operation like /proc/modules does.
Steps to reproduce:
while true; do modprobe xfs; rmmod xfs; done
vs
while true; do cat /proc/kallsyms >/dev/null; done
[where xfs could be any module, I haven't tried]
BUG: unable to handle kernel paging request at virtual address e19f808c
printing eip:
c01dc361
*pde = 1ff5f067
*pte =
Oops: [#1]
PREEMPT
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010297 (2.6.21-rc3-8b9909ded6922c33c221b105b26917780cfa497d #2)
EIP is at vsnprintf+0x2af/0x48c
eax: e19f808c ebx: ecx: e19f808c edx: fffe
esi: dbe7aa84 edi: dbe2bf3c ebp: esp: dbe2bec4
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process cat (pid: 7242, ti=dbe2b000 task=df5790b0 task.ti=dbe2b000)
Stack: e19d6fde 0010 0008 0001 0598 dbe7aa68
0002f362 0010 dbe7b000 c034bbe0 dbe7aa68 dfd31880
dfa31e80 1000 c01586b0 dbe2bf2c dbe2bf2c dfd31880 dfd31880 c01289f6
Call Trace:
[] seq_printf+0x2e/0x4b
[] s_show+0x4b/0x7f
[] seq_read+0x196/0x278
[] seq_read+0x0/0x278
[] vfs_read+0x72/0x93
[] sys_read+0x41/0x67
[] sysenter_past_esp+0x5f/0x85
===
Code: 74 24 28 73 03 c6 06 20 46 4d 85 ed 7f f1 e9 b9 00 00 00 8b 0f 81 f9 ff
0f 00 00 b8 ea 45 36 c0 0f 46 c8 8b 54 24 30 89 c8 eb 06 <80> 38 00 74 07 40 4a
83 fa ff 75 f4 29 c8 89 c3 89 e8 f6 44 24
EIP: [] vsnprintf+0x2af/0x48c SS:ESP 0068:dbe2bec4
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
include/linux/module.h |2 ++
kernel/kallsyms.c |2 ++
kernel/module.c|5 +
3 files changed, 5 insertions(+), 4 deletions(-)
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -20,6 +20,8 @@ #include
#include
+extern struct mutex module_mutex;
+
/* Not Yet Implemented */
#define MODULE_SUPPORTED_DEVICE(name)
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -369,6 +369,7 @@ static void *s_next(struct seq_file *m,
static void *s_start(struct seq_file *m, loff_t *pos)
{
+ mutex_lock(&module_mutex);
if (!update_iter(m->private, *pos))
return NULL;
return m->private;
@@ -376,6 +377,7 @@ static void *s_start(struct seq_file *m,
static void s_stop(struct seq_file *m, void *p)
{
+ mutex_unlock(&module_mutex);
}
static int s_show(struct seq_file *m, void *p)
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -62,7 +62,7 @@ #define INIT_OFFSET_MASK (1UL << (BITS_P
static DEFINE_SPINLOCK(modlist_lock);
/* List of modules, protected by module_mutex AND modlist_lock */
-static DEFINE_MUTEX(module_mutex);
+DEFINE_MUTEX(module_mutex);
static LIST_HEAD(modules);
static BLOCKING_NOTIFIER_HEAD(module_notify_list);
@@ -2124,19 +2124,16 @@ struct module *module_get_kallsym(unsign
{
struct module *mod;
- mutex_lock(&module_mutex);
list_for_each_entry(mod, &modules, list) {
if (symnum < mod->num_symtab) {
*value = mod->symtab[symnum].st_value;
*type = mod->symtab[symnum].st_info;
strlcpy(name, mod->strtab + mod->symtab[symnum].st_name,
namelen);
- mutex_unlock(&module_mutex);
return mod;
}
symnum -= mod->num_symtab;
}
- mutex_unlock(&module_mutex);
return 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/
3c59x regression (transmission stop)
Hi. I have a problem with 3c59x network driver. After some time (now it happened after 6 days of uptime) the card stops transmitting packets. Interrupt counter increments, the card recieves and trasmits some buffers, but the more time, the less packets are trasmitted and in the end it stops trasmitting at all. I don't know how to debug this, rmmod and modprobe of the module back helps to solve this for some time. What kind of info should I post and how to track this nasty thing down? Note, that this is server and hence things like bisecting is no-go for me. # lspci -vvxs 00:0e 00:0e.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 64) Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 32 (2500ns min, 2500ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at a800 [size=128] Region 1: Memory at f500 (32-bit, non-prefetchable) [size=128] [virtual] Expansion ROM at 3000 [disabled] [size=128K] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: b7 10 55 90 17 00 10 02 64 00 00 02 08 20 00 00 10: 01 a8 00 00 00 00 00 f5 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 55 90 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 0a 0a # cat /proc/interrupts CPU0 0: 524969030XT-PIC-XTtimer 1: 2270XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 5: 1357XT-PIC-XTuhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3 6: 5XT-PIC-XTfloppy 7: 78XT-PIC-XTparport0 8: 1XT-PIC-XTrtc 9: 0XT-PIC-XTacpi 10: 55418579XT-PIC-XTCMI8738-MC6, eth0 11: 31568244XT-PIC-XTnvidia 12: 12934XT-PIC-XTi8042 14:1946936XT-PIC-XTide0 15:1293985XT-PIC-XTide1 NMI: 0 ERR: 0 I know, that I have disabled APIC, I noted it yesterday and rebuilt the kernel with the APIC support, but still didn't reboot. If this is required I'll do so, but before that, there was running smp kernel and that kind of hangs appeared too. There is nothing significant in dmesg, 2.6.17-rc5 was fine, so this is definitely a regression. thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 00/18] Make common x86 arch area for i386 and x86_64 - Take 2
On Wed, 2007-03-14 at 11:36 +0100, Andi Kleen wrote: > Steven Rostedt <[EMAIL PROTECTED]> writes: > > > > So I spent last night hacking up something to try to make a common ground > > for all code that is shared between x86_64 and i386. I called this > > > >arch/x86 > > NACK. I think the current ways work just fine. Fine. The thing is others and I (and you) are working on getting paravirt_ops working for x86_64. There's a lot of overlap between i386 and x86_64. Right now the i386 is ahead of x86_64 and the code seems to be put more in the arch/i386 arch. So now we are going to introduce a new ../../i386 hack to get to a shared paravirt_shared.c(?). Or do we just continue on keeping the x86_64 as a separate entity, with a lot of duplicate code? I'm OK with either way. I just wanted to set a standard while it's still early enough to set one. -- 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/
