Re: [Sdhci-devel] [PATCH 2.6.20-rc2] Add a quirk to allow ENE PCI SD card readers to work again
Hi Darren,
It has come to my attention that the current routine for setting power
is not compliant with the specification. As such, I'd like you to try
the following and see if removes the need for your patch:
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index dc1b04a..13ac2fe 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -685,23 +690,21 @@ static void sdhci_set_power(struct sdhci_host
*host, unsigned short power)
if (power == (unsigned short)-1)
goto out;
- pwr = SDHCI_POWER_ON;
-
switch (power) {
case MMC_VDD_170:
case MMC_VDD_180:
case MMC_VDD_190:
- pwr |= SDHCI_POWER_180;
+ pwr = SDHCI_POWER_180;
break;
case MMC_VDD_290:
case MMC_VDD_300:
case MMC_VDD_310:
- pwr |= SDHCI_POWER_300;
+ pwr = SDHCI_POWER_300;
break;
case MMC_VDD_320:
case MMC_VDD_330:
case MMC_VDD_340:
- pwr |= SDHCI_POWER_330;
+ pwr = SDHCI_POWER_330;
break;
default:
BUG();
@@ -709,6 +712,10 @@ static void sdhci_set_power(struct sdhci_host
*host, unsigned short power)
writeb(pwr, host->ioaddr + SDHCI_POWER_CONTROL);
+ pwr |= SDHCI_POWER_ON;
+
+ writeb(pwr, host->ioaddr + SDHCI_POWER_CONTROL);
+
out:
host->power = power;
}
I'd appreciate if you could test this sooner rather than later as the
merge window is just around the corner.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.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: [PATCH 4 of 4] Introduce aio system call submission and completion system calls
> Isn't that kind of information supposed to be captured in nfs_open_context ? > Which is associated with the open file instance ... Or a refcounted struct cred. Which would be needed for strict POSIX thread semantics likely anyways. But there never was enough incentive to go down that path and it would be likely somewhat slow. > > I know this has been a traditional issue with network filesystems, and I > haven't kept up with the latest code and decisions in that respect, but how > would you do background writeback if there is an assumption of running in > the context of the original submitter ? AFAIK (Trond will hopefully correct me if I'm wrong) in the special case of NFS there isn't much problem because the server does the (passive) authentication and there is no background writeback from server to client. The client just does the usual checks at open time and then forgets about it. The server threads don't have own credentials but just check those of others. I can't think of any cases where you would need to do authentication in the client for every read() or write() Overall the arguments for reusing current don't seem to be strong to me. -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: C header files for vmware
Philippe Dhont (Sea-ro) wrote: hello, i downloaded latest kernel 2.6.19.2 and installed it and it works fine. Now i am trying to install vmware and it asks the location of the directory of the C header files. So i pointed it to my download/install directory /data/kernel/2.6.19.2/linux-2.6.19.2/include/ and i get the error that the directory of kernel headers does not match my running kernel ?? what am i doing wrong ? do i need to download something else ? Error message most probably also contains additional details... There may be couple of reasons - one of them may be that your product is too old to run on 2.6.19.2 kernel without additional changes. You should discuss these issues on http://www.vmware.com/community/index.jspa. If you are quite sure that you've built your kernel from these sources, and you did not run 'make clean' (or make *config) after build kernel, then you most probably have to download http://knihovny.cvut.cz/ftp/pub/vmware/vmware-any-any-update107.tar.gz, untar/ungzip it, run runme.pl from package, and follow directions... It should work with all released Linux products. If you are using Workstation 6.0 beta, you should contact VMware beta support. Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: remove_proc_entry and read_proc
Hi Alexey, > I believe, barriers not needed, not now. > > This scheme relies on the fact that remove_proc_entry() will be the only > place that will clear ->proc_fops and, once cleared, ->proc_fops will > never be resurrected. Clearing of ->proc_fops will eventually propagate > to CPU doing first check, thus preveting refcount bumps from this CPU. > What can be missed is some "rogue" readers or writers¹. Big deal. I don't understand you. Without memory barriers, remove_proc_entry will most of the time, but not all of the time, wait for all readers and writers to finish before exiting. Since the whole point of your patch was to ensure that all readers and writers finish before remove_proc_entry exits, I don't understand why you don't just put the memory barriers in and make it correct. Also, I do consider it a big deal: > ¹ Sigh, modules should do removals of proc entries first. And I should > check for that. Modules should of course call remove_proc_entry before exiting. However right now, even with your patch, a read or write method can still be running when remove_proc_entry returns [1], so could still be running when the module is removed (if they sleep; I guess this applies mostly to write methods). This is very bad - why not put in memory barriers and fix it? Also, plenty of proc read and write methods access private data that is allocated before calling create_proc_entry and freed after calling remove_proc_entry. If a read or write method is still running after remove_proc_entry returns, then it can access freed memory - very bad. Ciao, Duncan. [1] proc_get_inode does a try_module_get, so it is possible that module unloading is not a problem - not sure. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6-mm3
On Fri, Feb 02 2007, David Chinner wrote: > On Thu, Feb 01, 2007 at 08:18:57PM +0100, Jens Axboe wrote: > > That down() probably wants a replug to precede it. Probably something > > like: > > > > if (atomic_read(>b_io_remaining)) > > blk_replug_current_nested(); > > > > for xfs_buf_wait_unpin() and xfs_buf_lock(). Does this fix it? > > Jens, this patch looks like you originally removed the explicit > unplug calls that XFS used to prevent metadata I/O hangs and now you > are putting them back. Correct? > > Reading on from Andrew's earlier comments, shouldn't XFS have > worked unchanged? I'm just trying to understand why you removed > the explicit unplugs in the first place. It should, the problem is if someone has plugged higher up in the hierarchy, then you do need the explicit replug to drain that before going to sleep and waiting for IO to complete. Not very happy about that situation, I'd prefer if that happened automagically. I'll likely change the code to fix that, so we don't have to sprinkle blk_replug_current_nested() and always call io_schedule() instead of schedule(). It's just going to cause too many problems. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Unable to handle kernel NULL pointer dereference...as_move_to_dispatch+0x11/0x135
On Mon, 22 Jan 2007 10:35:10 -0800 Andrew Vasquez <[EMAIL PROTECTED]> wrote:
> All,
>
> We've been trying to track down a nagging regression seen during some
> port-disable/enable testing. The problem occurs anywhere from
> 20 minutes to 120 minutes of testing under very minimal I/O load:
>
> [ 1143.890598] Unable to handle kernel NULL pointer dereference at
> 0028 RIP:
> [ 1143.896087] [] as_move_to_dispatch+0x11/0x135
> [ 1143.904574] PGD 120ba067 PUD 31e8c067 PMD 0
> [ 1143.908895] Oops: [1] SMP
> [ 1143.912065] CPU 1
> [ 1143.914092] Modules linked in: qla2xxx scsi_transport_fc
> [ 1143.919453] Pid: 8362, comm: dt Not tainted 2.6.19 #39
> [ 1143.924588] RIP: 0010:[] []
> as_move_to_dispatch+0x11/0x135
> [ 1143.933300] RSP: 0018:8100021f7cf0 EFLAGS: 00010046
> [ 1143.938610] RAX: RBX: 8100261392f0 RCX:
>
> [ 1143.945736] RDX: RSI: RDI:
> 8100261392f0
> [ 1143.952865] RBP: R08: 804d0928 R09:
> 8100351a96e0
> [ 1143.959992] R10: 8100351a96e0 R11: R12:
>
> [ 1143.967118] R13: R14: 0282 R15:
> 0001
> [ 1143.974248] FS: () GS:8100021c5930()
> knlGS:
> [ 1143.982327] CS: 0010 DS: ES: CR0: 8005003b
> [ 1143.988070] CR2: 0028 CR3: 3493b000 CR4:
> 06e0
> [ 1143.995198] Process dt (pid: 8362, threadinfo 8100207a2000, task
> 810023d86840)
> [ 1144.003103] Stack: 8100261392f0
> 0001
> [ 1144.011183] 802ed591
> 810035795990
> [ 1144.018640] 81000f11b3f8 810035795990 810035795990
> 802e53d6
> [ 1144.025906] Call Trace:
> [ 1144.028548][]
> as_dispatch_request+0x39d/0x3aa
> [ 1144.035274] [] elv_next_request+0x45/0x151
> [ 1144.041015] [] scsi_request_fn+0x7a/0x375
> [ 1144.046667] [] blk_run_queue+0x42/0x74
> [ 1144.052062] [] scsi_next_command+0x2d/0x39
> [ 1144.057805] [] scsi_end_request+0xc0/0xce
> [ 1144.063460] [] scsi_io_completion+0x149/0x351
> [ 1144.069464] [] sd_rw_intr+0x247/0x256
> [ 1144.074770] [] scsi_finish_command+0x88/0x8d
> [ 1144.080686] [] scsi_softirq_done+0xe7/0xef
> [ 1144.086429] [] blk_done_softirq+0x63/0x71
> [ 1144.092082] [] __do_softirq+0x51/0xbd
> [ 1144.097394] [] call_softirq+0x1c/0x28
> [ 1144.102701] [] do_softirq+0x2e/0x94
> [ 1144.107836] [] do_IRQ+0xae/0xc8
> [ 1144.112625] [] ret_from_intr+0x0/0xb
> [ 1144.117845][] __bio_add_page+0x1b8/0x1bf
> [ 1144.124135] [] blkdev_direct_IO+0x2c9/0x420
> [ 1144.129964] [] __activate_task+0x2d/0x3f
> [ 1144.135537] [] _spin_unlock_irq+0x6/0x9
> [ 1144.141024] [] generic_file_direct_IO+0xa6/0xe8
> [ 1144.147196] [] __wake_up_common+0x42/0x6c
> [ 1144.152852] [] generic_file_aio_read+0xcc/0x19d
> [ 1144.159029] [] do_sync_read+0xc8/0x10b
> [ 1144.164426] [] autoremove_wake_function+0x0/0x2e
> [ 1144.170684] [] _spin_unlock_irq+0x6/0x9
> [ 1144.176166] [] do_filp_open+0x2d/0x3d
> [ 1144.181480] [] poison_obj+0x35/0x44
> [ 1144.186620] [] vfs_read+0xac/0x14f
> [ 1144.191668] [] sys_read+0x45/0x6e
> [ 1144.196630] [] system_call+0x7e/0x83
> [ 1144.201852]
>
> ...
>
> Basically what is happening from the FC side is the initiator executes
> a simple dt test:
>
> dt of=/dev/raw/raw1 procs=8 oncerr=abort bs=16k disable=stats
> limit=2m passes=100 pattern=iot dlimit=2048
>
> against a single lun (a very basic Windows target mode driver).
> During the test a port-enable, port-disable script is running agains
> the switch's port that is connected to the target (this occurs every
> sixty seconds (for a disabled duration of 2 seconds). Additionally,
> the target itself is set to LOGO (logout) or drop off the topology
> every 30 seconds.
I don't understand what effect the port-enable/port-disable has upon the
system. Will it cause I/O errors, or what?
> This test runs fine up to 2.6.19.
One thing we did in there was to give direct-io-against-blockdevs some
special-case bio-preparation code. Perhaps this is tickling a bug somehow.
We can revert that change like this:
diff -puN fs/block_dev.c~a fs/block_dev.c
--- a/fs/block_dev.c~a
+++ a/fs/block_dev.c
@@ -196,8 +196,47 @@ static void blk_unget_page(struct page *
pvec->page[--pvec->idx] = page;
}
+static int
+blkdev_get_blocks(struct inode *inode, sector_t iblock,
+ struct buffer_head *bh, int create)
+{
+ sector_t end_block =
Re: [patch 9/9] Make use of the Master Timer
On Thursday 01 February 2007 15:29, Jiri Bohac wrote: > If I do: > rdtscll(a) > ... > rdtscll(b) > is it guaranteed that (b > a) ? It's not architecturally -- unless you have a barrier. On P4 the micro architecture guarantees it, but there the barrier in get_cycles_sync is patched away. On other x86-64s it is generally needed. The effect can be also seen between CPUs. > Because of the __vxtime.cpu[cpu].tsc_invalid flag. We may be You can still precompute it for the HPET etc. case. They are already slow, but saving a condition there might be still worth it. -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: [rfc][patch] mm: half-fix page tail zeroing on write problem
On Fri, Feb 02, 2007 at 05:29:06PM +1100, Neil Brown wrote: > On Friday February 2, [EMAIL PROTECTED] wrote: > > Hi, > > > > For no important reason, I've again looked at those zeroing patches that > > Neil did a while back. I've always thought that a simple > > `write(fd, NULL, size)` would cause the same sorts of problems. > > Yeh, but who in their right mind would do that??? > Oh, you did :-) Well that's the test-case. Obviously not many people do it, but that's all the more reason to be careful about correct behaviour. > I cannot see why you make a change to fault_in_pages_writeable. Is it > just for symmetry? Yes. > For the rest, it certainly makes sense to return an early -EFAULT if > you cannot fault in the page. I think so. Thanks, Nick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 9/9] Make use of the Master Timer
> > Hmm, I wasn't sure. Why is it needed? How outdated can the > > result of RDTSC / RDTSCP be? > > > > If I do: > > rdtscll(a) > > ... > > rdtscll(b) > > is it guaranteed that (b > a) ? > > On a single CPU this is always guaranteed. Even on AMD. It's not guaranteed on Intel at least (but happens to work on P4) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/9] Remove the TSC synchronization on SMP machines
On Thursday 01 February 2007 14:17, Jiri Bohac wrote: > On Thu, Feb 01, 2007 at 12:14:23PM +0100, Andi Kleen wrote: > > On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote: > > > TSC is either synchronized by design or not reliable > > > to be used for anything, let alone timekeeping. > > > > In my tree this is already done better by a patch from Ingo. > > Check if they look synchronized and don't use TSC if they are not. > > The whole purpose of this patchset is to make use of TSC even if > it's not synchronized. It's still useful as a double check for platforms (like Intel single node) which are supposed to be synchronized. > Synchronizing it will not make anything better in any way -- the > implementation just does not care whether TSCs are synchronized. > That's why I think the synchronization code is not needed. It doesn't actively synchronize it, just checks if they look synchronized. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/9] Remove the TSC synchronization on SMP machines
On Thursday 01 February 2007 16:16, Vojtech Pavlik wrote: > It might even make sense to desycnhronize the TSCs on such (AMD) > machines on purpose, so that applications that rely on TSC break > immediately and not after some time when the error becomes too large. They won't because they're normally single threaded (and most people still use single core systems anyways) I've threatened to just disable RDTSC for ring 3 before, but it'll likely never happen because too many programs use it. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/9] x86_64: reliable TSC-based gettimeofday
On Friday 02 February 2007 05:22, Andrew Morton wrote: > On Thu, 01 Feb 2007 10:59:52 +0100 [EMAIL PROTECTED] wrote: > > > TSC-based x86_64 timekeeping implementation > > I worry about the relationship between this work and all the time-management > changes in -mm. If Andi to were to merge all this stuff under that then I > expect various catastrophes would ensue. > > Have you checked to determine the severity of the overlaps? The overlap is quite total. They both overhaul the time code completely. I suspect the way to go is to reimplement Jiri's patch on top of clock sources (Hopefully now with working algorithms that shouldn't be too hard). But I'm still waiting for Jiri's assessment on how feasible this is. -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: i386 and x86-64 bitops function prototypes differ
> > So I'd say that x86_64 is wrong, and should be changed to take ulong*. I'm trying to remember why I used void * -- I think there was a reason, but it's lost in the myst of time. Anyways, I suspect changing it now would have quite some fallout on other code, but hopefully limited to arch/x86_64/*. But fixing these up will hopefully not be too hard. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4 of 4] Introduce aio system call submission and completion system calls
On Thu, Feb 01, 2007 at 11:50:06AM -0800, Trond Myklebust wrote: > On Thu, 2007-02-01 at 16:43 +0530, Suparna Bhattacharya wrote: > > Wooo ...hold on ... I think this is swinging out of perspective :) > > > > I have said some of this before, but let me try again. > > > > As you already discovered when going down the fibril path, there are > > two kinds of accesses to current-> state, (1) common state > > for a given call chain (e.g. journal info etc), and (2) for > > various validations against the caller's process (uid, ulimit etc). > > > > (1) is not an issue when it comes to execution in background threads > > (the VFS already uses background writeback for example). > > > > As for (2), such checks need to happen upfront at the time of IO submission, > > so again are not an issue. > > Wrong! These checks can and do occur well after the time of I/O > submission in the case of remote filesystems with asynchronous writeback > support. > > Consider, for instance, the cases where the server reboots and loses all > state. Then there is the case of failover and/or migration events, where > the entire filesystem gets moved from one server to another, and again > you may have to recover state, etc... > > > I don't see any other reason why IO paths should be assuming that they are > > running in the original caller's context, midway through doing the IO. If > > that were the case background writeouts and readaheads could be fragile as > > well (or ptrace). The reason it isn't is because of this conceptual > > division of > > responsibility. > > The problem with this is that the security context is getting > progressively more heavy as we add more and more features. In addition > to the original uid/gid/fsuid/fsgid/groups, we now have stuff like > keyrings to carry around. Then there is all the context needed to > support selinux,... Isn't that kind of information supposed to be captured in nfs_open_context ? Which is associated with the open file instance ... I know this has been a traditional issue with network filesystems, and I haven't kept up with the latest code and decisions in that respect, but how would you do background writeback if there is an assumption of running in the context of the original submitter ? Regards Suparna > In the end, you end up recreating most of struct task_struct... > > Cheers > Trond > > -- > To unsubscribe, send a message with 'unsubscribe linux-aio' in > the body to [EMAIL PROTECTED] For more info on Linux AIO, > see: http://www.kvack.org/aio/ > Don't email: mailto:"[EMAIL PROTECTED]">[EMAIL PROTECTED] -- Suparna Bhattacharya ([EMAIL PROTECTED]) Linux Technology Center IBM Software Lab, India - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Cpuset aware writeback
On Thu, 1 Feb 2007 21:29:06 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Thu, 1 Feb 2007, Andrew Morton wrote: > > > > Peter Zilkstra addressed the NFS issue. > > > > Did he? Are you yet in a position to confirm that? > > He provided a solution to fix the congestion issue in NFS. I thought > that is what you were looking for? That should make NFS behave more > like a block device right? We hope so. The cpuset-aware-writeback patches were explicitly written to hide the bug which Peter's patches hopefully address. They hence remove our best way of confirming that Peter's patches fix the problem which you've observed in a proper fashion. Until we've confirmed that the NFS problem is nailed, I wouldn't want to merge cpuset-aware-writeback. I'm hoping to be able to do that with fake-numa on x86-64 but haven't got onto it yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4 of 4] Introduce aio system call submission and completion system calls
On Thu, Feb 01, 2007 at 01:29:41PM -0800, Zach Brown wrote: > >I want to try it on from a userspace perspective. > > Frankly, I'm not sure its ready for that yet. You're welcome to give > it a try, but it's early enough that you're sure to hit problems > almost immediately. I'm counting on it - what I want to taste is if the concept is a match for the things I want to do. Thanks! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.18-stable release plans?
[EMAIL PROTECTED] wrote: "With 100 million computers in use today, we should expect roughly 6 million single bit errors per year. Computer hardware and software companies must receive thousands of "side effect" bug reports and support calls due to memory errors alone. The costs of NOT including parity memory must be huge!" I must be weird or something, but I often think about this and the sheer number of clock cycles executing at any one time around the world. Have you ever stopped to think how many copies of schedule() (or whatever) are currently running somewhere in the world? It's just nuts :-) More seriously, if nobody cared about this stuff then we wouldn't have all this MCE reporting and tools to handle differentiating between actual failing DRAMs and temporary bit transitions in ECC memory. Jon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Cpuset aware writeback
On Thursday February 1, [EMAIL PROTECTED] wrote: > > > The network stack is of course a different (much harder) problem. > > An NFS solution is possible without solving the network stack issue? NFS is currently able to make more than max_dirty_ratio of memory Dirty/Writeback without being effectively throttled. So it can use up way more than it should and put pressure in the network stack. If NFS were throttled like other block-based filesystems (which Peter's patch should do), then there will normally be a lot more head room and the network stack will normally be able to cope. There might still be situations were you can run out of memory to the extent that NFS cannot make forward progress, but they will be substantially less likely (I think you need lots of TCP streams with slow consumers and fast producers so that TCP is forced to use up it reserves). The block layer guarantees not to run out of memory. The network layer makes a best effort as long as nothing goes crazy. NFS (currently) doesn't do quite enough to stop things going crazy. At least, that is my understanding. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sky2 hangs
Hello Stephen, > I can reproduce the problem now (on mac mini). Interestingly it seems > to whack the whole ethernet switch when it happens. wow. I have Linksys wrt54g has 'ethernet switch' and my Snom 320 VoIP phone still works when the mini network card goes down. On the other side the wrt54g isn't exactly a switch but more like a bunch of network cards which use the linux bridging code IIRC. > If you do: > ethtool -r eth0 > it cause a PHY reset (renegotiation) and clears the problem. But this isn't related to my problen (on mac mini), is it? Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should io(read|write)(8|16|32)_rep take (const|) volatile u(8|16|32) __iomem *addr?
Jeff Garzik wrote: Volatile is usually reserved for a specific need on a specific arch. I doubt it is correct to force it on all arches. They already are volatile; the issue is adding "const". All io(read|write)* pointers are volatile, IIRC. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Please revert "fix typo in geode_configre()@cyrix.c"
Linus, please revert commit e4f0ae0ea63caceff37a13f281a72652b7ea71ba Rationale: The thread starting with http://lkml.org/lkml/2007/1/9/63 contains a discussion about what might be a correct patch. Somehow the first patch of this discussion made it into 2.6.20-rc, but the ones considered more correct are later in the thread. Since there is AFAIK no actually observed problem fixed by this, it should be safe to simply revert the patch for 2.6.20. TIA 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: [rfc][patch] mm: half-fix page tail zeroing on write problem
On Friday February 2, [EMAIL PROTECTED] wrote: > Hi, > > For no important reason, I've again looked at those zeroing patches that > Neil did a while back. I've always thought that a simple > `write(fd, NULL, size)` would cause the same sorts of problems. Yeh, but who in their right mind would do that??? Oh, you did :-) > > Turns out it does. If you first write all 1s into a page, then do the > `write(fd, NULL, size)` at the same position, you end up with all 0s in > the page (test-case available on request). Incredible; surely this > violates the spec? Does it? I guess filling with zeros isn't what one would expect, but you could make a case for it being right. write(fd, 0, size) writes 'size' 0s. Cool. Ok, bad-cool. > > The buffered-write fixes I've got actually fix this properly, but they > don't look like getting merged any time soon. We could do this simple > patch which just reduces the chance of corruption from a certainty down > to a small race. > > Any thoughts? I cannot see why you make a change to fault_in_pages_writeable. Is it just for symmetry? For the rest, it certainly makes sense to return an early -EFAULT if you cannot fault in the page. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sky2 hangs
Hello Fagyal, > - a previously suggested fix - passing idle=poll to the kernel - did not > work for me at the end same for me. I tried the two module parameters and the kernel parameter: pci=nomsi sky2.disable_msi=1 sky2.idle_timeout=1000 > - the locks I have happen very periodically (somewhere around every 22-28 > hours), as if the chip would die after a given amount of data transferred; > I know this looks stupid but I thought I might mention it I had a dedicated server with sky2 which had the same symptoms but I disabled the onboard sky2 to and added a e100. On my mac mini I can reproduce it nearly immediately. Just have to scp a kernel tar tree over and it hangs. > - unloading the sky2 module totally freezes the computer for me For me it works pretty good. Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: epoll handling in the alpha port
On Friday 02 February 2007, Willy Tarreau wrote: > I think it would be reasonable to use the NR_epoll* names first, and to > declare NR_sys_epoll* aliases which will point to NR_epoll*. You would > then add a comment with the date of the change, stating that you keep > them just in case there are some old apps. Then, someone coming on the > comment in 3 or 4 years could reasonably suggest removing those aliases. fair enough, sounds like a plan man ... patch attached to do that Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]> --- diff --git a/include/asm-alpha/unistd.h b/include/asm-alpha/unistd.h index 84313d1..e58a427 100644 --- a/include/asm-alpha/unistd.h +++ b/include/asm-alpha/unistd.h @@ -342,9 +342,14 @@ #define __NR_io_cancel 402 #define __NR_exit_group405 #define __NR_lookup_dcookie406 -#define __NR_sys_epoll_create 407 -#define __NR_sys_epoll_ctl 408 -#define __NR_sys_epoll_wait409 +#define __NR_epoll_create 407 +#define __NR_epoll_ctl 408 +#define __NR_epoll_wait409 +/* Feb 2007: These three sys_epoll defines shouldn't be here but culling + * them would break userspace apps ... we'll kill them off in 2010 :) */ +#define __NR_sys_epoll_create __NR_epoll_create +#define __NR_sys_epoll_ctl __NR_epoll_ctl +#define __NR_sys_epoll_wait__NR_epoll_wait #define __NR_remap_file_pages 410 #define __NR_set_tid_address 411 #define __NR_restart_syscall 412 pgpaK1K0Qwz69.pgp Description: PGP signature
Re: [RFC 0/8] Cpuset aware writeback
On Fri, 2 Feb 2007, Neil Brown wrote: > md/raid doesn't cause any problems here. It preallocates enough to be > sure that it can always make forward progress. In general the entire > block layer from generic_make_request down can always successfully > write a block out in a reasonable amount of time without requiring > kmalloc to succeed (with obvious exceptions like loop and nbd which go > back up to a higher layer). Hmmm... I wonder if that could be generalized. A device driver could make a reservation by increasing min_free_kbytes? Additional drivers in a chain could make additional reservations in such a way that enough memory is set aside for the worst case? > The network stack is of course a different (much harder) problem. An NFS solution is possible without solving the network stack issue? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Ban module license tag string termination trick
Arjan van de Ven wrote: But you're right, the MODULE_LICENSE tag really does imply that licenses other than the GPL are ok. yup.. BSD licensed modules are clearly ok as well.. So I guess we're going to go with Jan's change then. I just wanted to discuss this briefly since I'm very keen for the kernel not to enforce legal/DRM type policy at all - this isn't quite the same discussion as we've had previously but the point remains: it should be for people to realize when they are violating a license as software unfortunately cannot ever be intelligent to catch all the baddies. Personally, I am less worried if people use an obvious "PROPRIETARY" label because they're at least admitting and saying it how it is - then if later it can be shown that they are in fact violating kernel copyright, they've helped to sign their own death warrant :-) Jon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should io(read|write)(8|16|32)_rep take (const|) volatile u(8|16|32) __iomem *addr?
Volatile is usually reserved for a specific need on a specific arch. I doubt it is correct to force it on all arches. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Cpuset aware writeback
On Thursday February 1, [EMAIL PROTECTED] wrote: >The NFS problems also exist for non cpuset scenarios > and we have by and large been able to live with it so I think they are > lower priority. It seems that the basic problem is created by the dirty > ratios in a cpuset. Some of our customers haven't been able to live with it. I'm really glad this will soon be fixed in mainline as it means our somewhat less elegant fix in SLES can go away :-) > > BTW the block layer also may be layered with raid and stuff and then we > have similar issues. There is no general way so far of handling these > situations except by twiddling around with min_free_kbytes praying 5 Hail > Mary's and trying again. md/raid doesn't cause any problems here. It preallocates enough to be sure that it can always make forward progress. In general the entire block layer from generic_make_request down can always successfully write a block out in a reasonable amount of time without requiring kmalloc to succeed (with obvious exceptions like loop and nbd which go back up to a higher layer). The network stack is of course a different (much harder) problem. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 000 of 14] knfsd: Preparation for IPv6 support in NFS server.
Roland Dreier wrote: > They are mostly from Chuck Level and make preparating for IPv6 support > in the NFS server. > They are *not* for 2.6.20, but should be ok for .21. Out of curiousity, does this patch series reduce the delta between the NFS/RDMA tree and mainline Linux? In other words does this bring NFS/RDMA closer to merging? NFS/RDMA is IMO more than a little bit questionable, and the likely userbase is also quite small. I'm not sure its worth a mainline merge at this point. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[rfc][patch] mm: half-fix page tail zeroing on write problem
Hi,
For no important reason, I've again looked at those zeroing patches that
Neil did a while back. I've always thought that a simple
`write(fd, NULL, size)` would cause the same sorts of problems.
Turns out it does. If you first write all 1s into a page, then do the
`write(fd, NULL, size)` at the same position, you end up with all 0s in
the page (test-case available on request). Incredible; surely this
violates the spec?
The buffered-write fixes I've got actually fix this properly, but they
don't look like getting merged any time soon. We could do this simple
patch which just reduces the chance of corruption from a certainty down
to a small race.
Any thoughts?
--
Index: linux-2.6/include/linux/pagemap.h
===
--- linux-2.6.orig/include/linux/pagemap.h 2007-02-02 13:41:21.0
+1100
+++ linux-2.6/include/linux/pagemap.h 2007-02-02 13:42:09.0 +1100
@@ -198,6 +198,9 @@ static inline int fault_in_pages_writeab
{
int ret;
+ if (unlikely(size == 0))
+ return 0;
+
/*
* Writing zeroes into userspace here is OK, because we know that if
* the zero gets there, we'll be overwriting it.
@@ -217,19 +220,23 @@ static inline int fault_in_pages_writeab
return ret;
}
-static inline void fault_in_pages_readable(const char __user *uaddr, int size)
+static inline int fault_in_pages_readable(const char __user *uaddr, int size)
{
volatile char c;
int ret;
+ if (unlikely(size == 0))
+ return 0;
+
ret = __get_user(c, uaddr);
if (ret == 0) {
const char __user *end = uaddr + size - 1;
if (((unsigned long)uaddr & PAGE_MASK) !=
((unsigned long)end & PAGE_MASK))
- __get_user(c, end);
+ ret = __get_user(c, end);
}
+ return ret;
}
#endif /* _LINUX_PAGEMAP_H */
Index: linux-2.6/mm/filemap.c
===
--- linux-2.6.orig/mm/filemap.c 2007-02-02 13:42:40.0 +1100
+++ linux-2.6/mm/filemap.c 2007-02-02 14:00:19.0 +1100
@@ -2112,7 +2112,10 @@ generic_file_buffered_write(struct kiocb
* same page as we're writing to, without it being marked
* up-to-date.
*/
- fault_in_pages_readable(buf, bytes);
+ if (fault_in_pages_readable(buf, bytes)) {
+ status = -EFAULT;
+ break;
+ }
page = __grab_cache_page(mapping,index,_page,_pvec);
if (!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/
2.6.20-rc7: known regressions
This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19 that are not yet fixed in Linus' tree. 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: NULL pointer dereference at as_move_to_dispatch() References : http://lkml.org/lkml/2007/1/22/141 Submitter : Andrew Vasquez <[EMAIL PROTECTED]> Status : unknown Subject: pktcdvd doesn't work with libata pata drivers References : http://bugzilla.kernel.org/show_bug.cgi?id=7810 http://lkml.org/lkml/2007/1/25/128 http://bugzilla.kernel.org/show_bug.cgi?id=7910 http://lkml.org/lkml/2007/1/30/289 Submitter : Gerhard Dirschl <[EMAIL PROTECTED]> Luca Tettamanti <[EMAIL PROTECTED]> Caused-By : Christoph Hellwig <[EMAIL PROTECTED]> commit 3b00315799d78f76531b71435fbc2643cd71ae4c commit 406c9b605cbc45151c03ac9a3f95e9acf050808c Status : unknown Subject: powerpc64: performance monitor exception References : http://ozlabs.org/pipermail/linuxppc-dev/2007-January/030045.html Submitter : Livio Soares <[EMAIL PROTECTED]> Caused-By : Paul Mackerras <[EMAIL PROTECTED]> commit d04c56f73c30a5e593202ecfcf25ed43d42363a2 Status : unknown Subject: reboot instead of powerdown (CONFIG_USB_SUSPEND) References : http://lkml.org/lkml/2006/12/25/40 http://bugzilla.kernel.org/show_bug.cgi?id=7828 Submitter : Berthold Cogel <[EMAIL PROTECTED]> François Valenduc <[EMAIL PROTECTED]> Handled-By : Alan Stern <[EMAIL PROTECTED]> Status : problem is being debugged Subject: usb somehow broken (CONFIG_USB_SUSPEND) References : http://lkml.org/lkml/2007/1/11/146 Submitter : Prakash Punnoor <[EMAIL PROTECTED]> Handled-By : Oliver Neukum <[EMAIL PROTECTED]> Alan Stern <[EMAIL PROTECTED]> Status : problem is being debugged Subject: BUG: at fs/inotify.c:172 set_dentry_child_flags() References : http://bugzilla.kernel.org/show_bug.cgi?id=7785 Submitter : Cijoml Cijomlovic Cijomlov <[EMAIL PROTECTED]> Handled-By : Nick Piggin <[EMAIL PROTECTED]> Status : problem is being debugged Subject: fix geode_configure() References : http://lkml.org/lkml/2007/1/9/216 Submitter : Lennart Sorensen <[EMAIL PROTECTED]> Caused-By : takada <[EMAIL PROTECTED]> commit e4f0ae0ea63caceff37a13f281a72652b7ea71ba Handled-By : takada <[EMAIL PROTECTED]> Lennart Sorensen <[EMAIL PROTECTED]> Status : patches are being discussed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: epoll handling in the alpha port
On Fri, Feb 02, 2007 at 12:19:35AM -0500, Mike Frysinger wrote: > On Friday 02 February 2007, Andrew Morton wrote: > > It might be to late to fix this - we risk breaking userspace which worked > > around it. > > we'd be breaking userspace API, but not ABI ... and the largest consumers out > there (glibc/uclibc) have not been accounting for this, so we wouldnt be > breaking them > > that's how we noticed the issue in Gentoo ... all the epoll calls are > automatically declared -ENOSYS stubs in glibc's libc.so > > is there some other large consumer i'm not thinking of ? Not necessarily some large consumers, but epoll() is quite older than its kernel inclusion, so there certainly are some apps still using the syscall without going through libc. > > It would be safer to add the correct definitions while leaving the old ones > > in place. > > in the end, either works for me ... i can see linux's pretty hard 'dont break > userspace' policy coming into play here I think it would be reasonable to use the NR_epoll* names first, and to declare NR_sys_epoll* aliases which will point to NR_epoll*. You would then add a comment with the date of the change, stating that you keep them just in case there are some old apps. Then, someone coming on the comment in 3 or 4 years could reasonably suggest removing those aliases. Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20-rc6] pktcdvd doesn't work
On Thu, Feb 01, 2007 at 08:07:12PM -0800, Andrew Morton wrote:
> On Fri, 2 Feb 2007 03:33:43 +0100 Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Feb 01, 2007 at 06:21:47PM -0800, Andrew Morton wrote:
> > > On Fri, 2 Feb 2007 00:07:52 +0100 Luca Tettamanti <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > Il Thu, Feb 01, 2007 at 12:30:44AM +0100, Adrian Bunk ha scritto:
> > > > > On Tue, Jan 30, 2007 at 08:53:19PM +0100, Luca Tettamanti wrote:
> > > > > > Hi,
> > > > > > pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file
> > > > > > that
> > > > > > is written to the device is lost after umount.
> > > > > > I rarely use pktcdvd but at some point it used to work on my system.
> > > > > >
> > > > > > This is what I'm doing:
> > > > > >
> > > > > > [EMAIL PROTECTED]:/tmp# cdrwtool -d /dev/scd0 -q
> > > > > > using device /dev/scd0
> > > > > > 1029KB internal buffer
> > > > > > setting write speed to 12x
> > > > > > Settings for /dev/scd0:
> > > > > > Fixed packets, size 32
> > > > > > Mode-2 disc
> > > > > >...
> > > > >
> > > > > Does 2.6.20-rc7 work?
> > > > > If no, does it work after applying the attached patch?
> > > > > If no, does 2.6.19.2 work?
> > > >
> > > > Git current + the following patch works.
> > > >
> > > > > diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> > > > > index 6246219..7c95c76 100644
> > > > > --- a/drivers/block/pktcdvd.c
> > > > > +++ b/drivers/block/pktcdvd.c
> > > > > @@ -765,34 +765,47 @@ static inline struct bio
> > > > > *pkt_get_list_first(struct bio **list_head, struct bio
> > > > > */
> > > > > static int pkt_generic_packet(struct pktcdvd_device *pd, struct
> > > > > packet_command *cgc)
> > > > > {
> > > > > - request_queue_t *q = bdev_get_queue(pd->bdev);
> > > > > + char sense[SCSI_SENSE_BUFFERSIZE];
> > >
> > > Where did this patch come from?
> >
> > It's a revert of the commits 3b00315799d78f76531b71435fbc2643cd71ae4c
> > and 406c9b605cbc45151c03ac9a3f95e9acf050808c
> >
>
> Oh. That's
>
> [SCSI] untangle scsi_prep_fn
> and
> [PATCH] Fix BUG at drivers/scsi/scsi_lib.c:1118 caused by "pktsetup dvd /dev
>
> so this is a post-2.6.18 regression, yes?
No, a post-2.6.19 regression.
> do we know why this is happening?
No.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] Create ZONE_MOVABLE to partition memory between movable and non-movable pages
On Tue, 30 Jan 2007, Peter Zijlstra wrote: > I'm guessing this will involve page migration. Not necessarily. The approach also works without page migration. Depends on an intelligent allocation scheme that stays off the areas of interest to those restricted to low area allocations as much as possible and then is able to reclaim from a section of a zone if necessary. The implementation of alloc_pages_range() that I did way back did not reply on page migration. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Cpuset aware writeback
On Thu, 1 Feb 2007, Andrew Morton wrote: > > Peter Zilkstra addressed the NFS issue. > > Did he? Are you yet in a position to confirm that? He provided a solution to fix the congestion issue in NFS. I thought that is what you were looking for? That should make NFS behave more like a block device right? As I said before I think NFS is inherently unfixable given the layering of a block device on top of the network stack (which consists of an unknown number of additional intermediate layers). Cpuset writeback needs to work in the same way as in a machine without cpusets. If fails then at least let the cpuset behave as if we had a machine all on our own and fail in both cases in the same way. Right now we create dangerous low memory conditions due to high dirty ratios in a cpuset created by not having a throttling method. The NFS problems also exist for non cpuset scenarios and we have by and large been able to live with it so I think they are lower priority. It seems that the basic problem is created by the dirty ratios in a cpuset. BTW the block layer also may be layered with raid and stuff and then we have similar issues. There is no general way so far of handling these situations except by twiddling around with min_free_kbytes praying 5 Hail Mary's and trying again. Maybe we are able allocate all needed memory from PF_MEMALLOC processes during reclaim and hopefully there is now enough memory for these allocations and those that happen to occur during an interrupt while we reclaim. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: smp and irq conflict
On Thursday 01 February 2007 23:32, Andrew Morton wrote: > On Thu, 1 Feb 2007 18:46:00 +0100 "Lapo TIN" <[EMAIL PROTECTED]> wrote: > > > Dear all, > > I have a problem with IRQs. > > > > My pc has a CPU PentiumD945 (dual core) and a 2.6.19smp kernel. > > I have two video acquisition board (four bt8t8 each) in the only two pci > > slots of my motherboard. Thus I have a total of 8 bttv modules that are > > working together, and the /proc/interrupts is as follows: > > # cat /proc/interrupts > >CPU0 CPU1 > > 0: 13575 0 IO-APIC-edge timer > > 1: 2 0 IO-APIC-edge i8042 > > 4: 11 0 IO-APIC-edge serial > > 8: 1 0 IO-APIC-edge rtc > > 9: 0 0 IO-APIC-fasteoi acpi > > 12: 4 0 IO-APIC-edge i8042 > > 14: 22286 0 IO-APIC-edge ide0 > > 17: 7073 2097 IO-APIC-fasteoi uhci_hcd:usb5, eth0 > > 18: 2525 0 IO-APIC-fasteoi bttv0, bttv7 > > 19: 2829 0 IO-APIC-fasteoi bttv1, bttv4 > > 20: 2526 0 IO-APIC-fasteoi bttv2, bttv5 > > 21: 2226 0 IO-APIC-fasteoi bttv3, bttv6 The assignment of the interrupt pins from the bttv cards is dictated by how the motherboard routed the physical wires from the PCI slots to the IO APIC pins. Sometimes these can be re-routed by an interrupt router on the board controlled by PIRQ tables or ACPI PCI Interrupt Link devices -- but in the case of a dekstop board with an IOAPIC they are usually just hard coded in a "barber poll" fashion like above, and you will not be able to change them except by moving cards between slots. The complete output from dmesg -s64000 will tell us. -Len > > 22: 2 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb4 > > 23: 86 0 IO-APIC-fasteoi uhci_hcd:usb2 > > 24: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 > > NMI: 0 0 > > LOC: 13484 13502 > > ERR: 0 > > MIS: 0 > > You can see that IRQ18 is shared between bttv0 and bttv7, IRQ19 between > > bttv1 and bttv4 and so on. > > > > Sometimes it crashes. It seems a matter of conflict in IRQ. > > With only one video board everything is ok, but with two, they shared irq > > and something goes wrong... > > How can I tell to the kernel to not to share the IRQ for these boards ? > > I think (I don't know if I'm right) that this could be the problem. > > > > I even tried with another motherboard, and doing cat /proc/interrupts the > > situation was the same, except for 'eth0' that was together with bttv0 and > > bttv7... so it was even worst ! it crashes after few minutes. > > > > I tried to read IO-APIC.txt in Documentation/i386/ folder, but I didn't > > understand how to avoid the coupling of IRQ. > > Thanks > > Should be OK. Can you provide us with any kernel output from these crashes? > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] Create ZONE_MOVABLE to partition memory between movable and non-movable pages
On Mon, 29 Jan 2007, Andrew Morton wrote: > On Mon, 29 Jan 2007 15:37:29 -0800 (PST) > Christoph Lameter <[EMAIL PROTECTED]> wrote: > > > With a alloc_pages_range() one would be able to specify upper and lower > > boundaries. > > Is there a proposal anywhere regarding how this would be implemented? Yes it was discussed a while back in August. Look for alloc_pages_range. Sadly I have not been able to do work on it since there are too many other issues. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: epoll handling in the alpha port
On Friday 02 February 2007, Andrew Morton wrote: > It might be to late to fix this - we risk breaking userspace which worked > around it. we'd be breaking userspace API, but not ABI ... and the largest consumers out there (glibc/uclibc) have not been accounting for this, so we wouldnt be breaking them that's how we noticed the issue in Gentoo ... all the epoll calls are automatically declared -ENOSYS stubs in glibc's libc.so is there some other large consumer i'm not thinking of ? > It would be safer to add the correct definitions while leaving the old ones > in place. in the end, either works for me ... i can see linux's pretty hard 'dont break userspace' policy coming into play here -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: epoll handling in the alpha port
On Thu, 1 Feb 2007 15:20:45 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > the alpha linux port differs from all others when it comes to the epoll > functions in that it uses '__NR_sys_epoll_XXX' instead of '__NR_epoll_XXX' in > the asm/unistd.h header ... the trouble with this is that glibc maps the > function name directly to an __NR_ define, so when it maps > like 'epoll_create', it expects '__NR_epoll_create' (which it gets with all > other architectures) > > is there some obvious thing i'm missing here ? or is the attached patch OK ? > > Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]> > --- > --- a/include/asm-alpha/unistd.h > +++ b/include/asm-alpha/unistd.h > @@ -342,9 +342,9 @@ > #define __NR_io_cancel 402 > #define __NR_exit_group 405 > #define __NR_lookup_dcookie 406 > -#define __NR_sys_epoll_create407 > -#define __NR_sys_epoll_ctl 408 > -#define __NR_sys_epoll_wait 409 > +#define __NR_epoll_create407 > +#define __NR_epoll_ctl 408 > +#define __NR_epoll_wait 409 > #define __NR_remap_file_pages410 > #define __NR_set_tid_address 411 > #define __NR_restart_syscall 412 It might be to late to fix this - we risk breaking userspace which worked around it. It would be safer to add the correct definitions while leaving the old ones in place. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 000 of 14] knfsd: Preparation for IPv6 support in NFS server.
On Thursday February 1, [EMAIL PROTECTED] wrote: > > They are mostly from Chuck Level and make preparating for IPv6 support > > in the NFS server. > > They are *not* for 2.6.20, but should be ok for .21. > > Out of curiousity, does this patch series reduce the delta between the > NFS/RDMA tree and mainline Linux? In other words does this bring > NFS/RDMA closer to merging? > > - R. No idea. I haven't seen any RDMA patches. I seem to remember hearing them mentioned some time ago, but I haven't gone looking for them. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
On Wed, 31 Jan 2007 21:20:06 +0100 Greg KH wrote: > On Wed, Jan 31, 2007 at 02:06:32PM +0100, Nicolas Mailhot wrote: >> I'd really love if the same offer was extended to GPL out-of-tree >> driver trees. > > This kind of offer has _always_ been there for out-of-tree GPL > drivers. I have contacted many different groups and driver authors > over the years to offer my help in trying to get their code into the > mainline kernel. > > Some take me up on the offer, others ignore it, and still others > activly refuse to do so, saying they want to stay out-of-the tree > (lirc is one of these examples...) I'm the LIRC maintainer. I don't know what let's you think LIRC wants to stay out-of-the-tree. I just made clear that I don't have the time to do the merging of LIRC drivers to the kernel myself. In fact a lot of work still needs to be done before LIRC drivers are ready to be included into the kernel. Spreading the impression that LIRC refuses to work with kernel developers is not particularly helpful... Any help welcome. Christoph Pls Cc me on replies, I'm not subscribed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND] [PATCH 012 of 14] knfsd: SUNRPC: Support IPv6 addresses in svc_tcp_accept
Sorry, missed a cast in a dprintk that I could remove (and a '&' that
had to go too).
NeilBrown
### Comments for Changeset
From: Chuck Lever <[EMAIL PROTECTED]>
Modify svc_tcp_accept to support connecting on IPv6 sockets.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-02-02 15:48:21.0 +1100
+++ ./net/sunrpc/svcsock.c 2007-02-02 15:48:39.0 +1100
@@ -949,7 +949,8 @@ static inline int svc_port_is_privileged
static void
svc_tcp_accept(struct svc_sock *svsk)
{
- struct sockaddr_in sin;
+ struct sockaddr_storage addr;
+ struct sockaddr *sin = (struct sockaddr *)
struct svc_serv *serv = svsk->sk_server;
struct socket *sock = svsk->sk_sock;
struct socket *newsock;
@@ -976,8 +977,7 @@ svc_tcp_accept(struct svc_sock *svsk)
set_bit(SK_CONN, >sk_flags);
svc_sock_enqueue(svsk);
- slen = sizeof(sin);
- err = kernel_getpeername(newsock, (struct sockaddr *) , );
+ err = kernel_getpeername(newsock, sin, );
if (err < 0) {
if (net_ratelimit())
printk(KERN_WARNING "%s: peername failed (err %d)!\n",
@@ -989,16 +989,14 @@ svc_tcp_accept(struct svc_sock *svsk)
* hosts here, but when we get encryption, the IP of the host won't
* tell us anything. For now just warn about unpriv connections.
*/
- if (!svc_port_is_privileged((struct sockaddr *) )) {
+ if (!svc_port_is_privileged(sin)) {
dprintk(KERN_WARNING
"%s: connect from unprivileged port: %s\n",
serv->sv_name,
- __svc_print_addr((struct sockaddr *) , buf,
- sizeof(buf)));
+ __svc_print_addr(sin, buf, sizeof(buf)));
}
dprintk("%s: connect from %s\n", serv->sv_name,
- __svc_print_addr((struct sockaddr *) , buf,
-sizeof(buf)));
+ __svc_print_addr(sin, buf, sizeof(buf)));
/* make sure that a write doesn't block forever when
* low on memory
@@ -1008,7 +1006,7 @@ svc_tcp_accept(struct svc_sock *svsk)
if (!(newsvsk = svc_setup_socket(serv, newsock, ,
(SVC_SOCK_ANONYMOUS | SVC_SOCK_TEMPORARY
goto failed;
- memcpy(>sk_remote, , slen);
+ memcpy(>sk_remote, sin, slen);
newsvsk->sk_remotelen = slen;
svc_sock_received(newsvsk);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 000 of 14] knfsd: Preparation for IPv6 support in NFS server.
> They are mostly from Chuck Level and make preparating for IPv6 support > in the NFS server. > They are *not* for 2.6.20, but should be ok for .21. Out of curiousity, does this patch series reduce the delta between the NFS/RDMA tree and mainline Linux? In other words does this bring NFS/RDMA closer to merging? - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: [PATCH 1/10] cxgb3 - main header files]
> Have you had a chance to review this? Still on my list. Can we trade? Can you look at the IPoIB connected mode stuff in the ipoib-cm branch in git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git and let me know if you see anything you don't like? - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 008 of 14] knfsd: SUNRPC: Provide room in svc_rqst for larger addresses
From: Chuck Lever <[EMAIL PROTECTED]>
Expand the rq_addr field to allow it to contain larger addresses.
Specifically, we replace a 'sockaddr_in' with a 'sockaddr_storage',
then everywhere the 'sockaddr_in' was referenced, we use instead
an accessor function (svc_addr_in) which safely casts the _storage
to _in.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/lockd/host.c|2 +-
./fs/lockd/svc4proc.c|6 --
./fs/lockd/svcproc.c |6 --
./fs/nfs/callback.c |2 +-
./fs/nfs/callback_xdr.c |4 ++--
./fs/nfsd/nfs4state.c| 18 +-
./fs/nfsd/nfscache.c |2 +-
./include/linux/sunrpc/svc.h | 17 +++--
./net/sunrpc/svcauth_unix.c |3 ++-
./net/sunrpc/svcsock.c | 19 ---
10 files changed, 51 insertions(+), 28 deletions(-)
diff .prev/fs/lockd/host.c ./fs/lockd/host.c
--- .prev/fs/lockd/host.c 2007-02-02 15:15:10.0 +1100
+++ ./fs/lockd/host.c 2007-02-02 15:22:32.0 +1100
@@ -191,7 +191,7 @@ struct nlm_host *
nlmsvc_lookup_host(struct svc_rqst *rqstp,
const char *hostname, int hostname_len)
{
- return nlm_lookup_host(1, >rq_addr,
+ return nlm_lookup_host(1, svc_addr_in(rqstp),
rqstp->rq_prot, rqstp->rq_vers,
hostname, hostname_len);
}
diff .prev/fs/lockd/svc4proc.c ./fs/lockd/svc4proc.c
--- .prev/fs/lockd/svc4proc.c 2007-02-02 15:22:31.0 +1100
+++ ./fs/lockd/svc4proc.c 2007-02-02 15:22:32.0 +1100
@@ -224,7 +224,7 @@ nlm4svc_proc_granted(struct svc_rqst *rq
resp->cookie = argp->cookie;
dprintk("lockd: GRANTED called\n");
- resp->status = nlmclnt_grant(>rq_addr, >lock);
+ resp->status = nlmclnt_grant(svc_addr_in(rqstp), >lock);
dprintk("lockd: GRANTED status %d\n", ntohl(resp->status));
return rpc_success;
}
@@ -421,7 +421,9 @@ static __be32
nlm4svc_proc_sm_notify(struct svc_rqst *rqstp, struct nlm_reboot *argp,
void *resp)
{
- struct sockaddr_in saddr = rqstp->rq_addr;
+ struct sockaddr_in saddr;
+
+ memcpy(, svc_addr_in(rqstp), sizeof(saddr));
dprintk("lockd: SM_NOTIFY called\n");
if (saddr.sin_addr.s_addr != htonl(INADDR_LOOPBACK)
diff .prev/fs/lockd/svcproc.c ./fs/lockd/svcproc.c
--- .prev/fs/lockd/svcproc.c2007-02-02 15:22:31.0 +1100
+++ ./fs/lockd/svcproc.c2007-02-02 15:22:32.0 +1100
@@ -253,7 +253,7 @@ nlmsvc_proc_granted(struct svc_rqst *rqs
resp->cookie = argp->cookie;
dprintk("lockd: GRANTED called\n");
- resp->status = nlmclnt_grant(>rq_addr, >lock);
+ resp->status = nlmclnt_grant(svc_addr_in(rqstp), >lock);
dprintk("lockd: GRANTED status %d\n", ntohl(resp->status));
return rpc_success;
}
@@ -452,7 +452,9 @@ static __be32
nlmsvc_proc_sm_notify(struct svc_rqst *rqstp, struct nlm_reboot *argp,
void *resp)
{
- struct sockaddr_in saddr = rqstp->rq_addr;
+ struct sockaddr_in saddr;
+
+ memcpy(, svc_addr_in(rqstp), sizeof(saddr));
dprintk("lockd: SM_NOTIFY called\n");
if (saddr.sin_addr.s_addr != htonl(INADDR_LOOPBACK)
diff .prev/fs/nfs/callback.c ./fs/nfs/callback.c
--- .prev/fs/nfs/callback.c 2007-02-02 15:22:31.0 +1100
+++ ./fs/nfs/callback.c 2007-02-02 15:22:32.0 +1100
@@ -166,7 +166,7 @@ void nfs_callback_down(void)
static int nfs_callback_authenticate(struct svc_rqst *rqstp)
{
- struct sockaddr_in *addr = >rq_addr;
+ struct sockaddr_in *addr = svc_addr_in(rqstp);
struct nfs_client *clp;
char buf[RPC_MAX_ADDRBUFLEN];
diff .prev/fs/nfs/callback_xdr.c ./fs/nfs/callback_xdr.c
--- .prev/fs/nfs/callback_xdr.c 2007-02-02 15:15:10.0 +1100
+++ ./fs/nfs/callback_xdr.c 2007-02-02 15:22:32.0 +1100
@@ -176,7 +176,7 @@ static __be32 decode_getattr_args(struct
status = decode_fh(xdr, >fh);
if (unlikely(status != 0))
goto out;
- args->addr = >rq_addr;
+ args->addr = svc_addr_in(rqstp);
status = decode_bitmap(xdr, args->bitmap);
out:
dprintk("%s: exit with status = %d\n", __FUNCTION__, status);
@@ -188,7 +188,7 @@ static __be32 decode_recall_args(struct
__be32 *p;
__be32 status;
- args->addr = >rq_addr;
+ args->addr = svc_addr_in(rqstp);
status = decode_stateid(xdr, >stateid);
if (unlikely(status != 0))
goto out;
diff .prev/fs/nfsd/nfs4state.c ./fs/nfsd/nfs4state.c
--- .prev/fs/nfsd/nfs4state.c 2007-02-02 15:15:10.0 +1100
+++ ./fs/nfsd/nfs4state.c
[PATCH 003 of 14] knfsd: SUNRPC: aplit svc_sock_enqueue out of svc_setup_socket.
Rather than calling svc_sock_enqueue at the end of svc_setup_socket,
we now call it (via svc_sock_recieved) after calling svc_setup_socket
at each call site.
We do this because a subsequent patch will insert some code between
the two calls at one call site.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-02-02 15:15:11.0 +1100
+++ ./net/sunrpc/svcsock.c 2007-02-02 15:18:37.0 +1100
@@ -925,7 +925,7 @@ svc_tcp_accept(struct svc_sock *svsk)
if (!(newsvsk = svc_setup_socket(serv, newsock, ,
(SVC_SOCK_ANONYMOUS | SVC_SOCK_TEMPORARY
goto failed;
-
+ svc_sock_received(newsvsk);
/* make sure that we don't have too many active connections.
* If we have, something must be dropped.
@@ -1532,8 +1532,6 @@ static struct svc_sock *svc_setup_socket
dprintk("svc: svc_setup_socket created %p (inet %p)\n",
svsk, svsk->sk_sk);
- clear_bit(SK_BUSY, >sk_flags);
- svc_sock_enqueue(svsk);
return svsk;
}
@@ -1557,8 +1555,10 @@ int svc_addsock(struct svc_serv *serv,
err = -EISCONN;
else {
svsk = svc_setup_socket(serv, so, , SVC_SOCK_DEFAULTS);
- if (svsk)
+ if (svsk) {
+ svc_sock_received(svsk);
err = 0;
+ }
}
if (err) {
sockfd_put(so);
@@ -1609,8 +1609,10 @@ static int svc_create_socket(struct svc_
goto bummer;
}
- if ((svsk = svc_setup_socket(serv, sock, , flags)) != NULL)
+ if ((svsk = svc_setup_socket(serv, sock, , flags)) != NULL) {
+ svc_sock_received(svsk);
return ntohs(inet_sk(svsk->sk_sk)->sport);
+ }
bummer:
dprintk("svc: svc_create_socket error = %d\n", -error);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 004 of 14] knfsd: SUNRPC: Cache remote peer's address in svc_sock.
From: Chuck Lever <[EMAIL PROTECTED]>
The remote peer's address won't change after the socket has been
accepted. We don't need to call ->getname on every incoming request.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./include/linux/sunrpc/svcsock.h |3 +++
./net/sunrpc/svcsock.c | 14 --
2 files changed, 11 insertions(+), 6 deletions(-)
diff .prev/include/linux/sunrpc/svcsock.h ./include/linux/sunrpc/svcsock.h
--- .prev/include/linux/sunrpc/svcsock.h2007-02-02 15:17:11.0
+1100
+++ ./include/linux/sunrpc/svcsock.h2007-02-02 15:21:28.0 +1100
@@ -57,6 +57,9 @@ struct svc_sock {
/* cache of various info for TCP sockets */
void*sk_info_authunix;
+
+ struct sockaddr_storage sk_remote; /* remote peer's address */
+ int sk_remotelen; /* length of address */
};
/*
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-02-02 15:18:37.0 +1100
+++ ./net/sunrpc/svcsock.c 2007-02-02 15:21:55.0 +1100
@@ -560,12 +560,13 @@ svc_recv_available(struct svc_sock *svsk
static int
svc_recvfrom(struct svc_rqst *rqstp, struct kvec *iov, int nr, int buflen)
{
+ struct svc_sock *svsk = rqstp->rq_sock;
struct msghdr msg;
struct socket *sock;
- int len, alen;
+ int len;
rqstp->rq_addrlen = sizeof(rqstp->rq_addr);
- sock = rqstp->rq_sock->sk_sock;
+ sock = svsk->sk_sock;
msg.msg_name= >rq_addr;
msg.msg_namelen = sizeof(rqstp->rq_addr);
@@ -577,11 +578,9 @@ svc_recvfrom(struct svc_rqst *rqstp, str
len = kernel_recvmsg(sock, , iov, nr, buflen, MSG_DONTWAIT);
/* sock_recvmsg doesn't fill in the name/namelen, so we must..
-* possibly we should cache this in the svc_sock structure
-* at accept time. FIXME
*/
- alen = sizeof(rqstp->rq_addr);
- kernel_getpeername(sock, (struct sockaddr *)>rq_addr, );
+ memcpy(>rq_addr, >sk_remote, svsk->sk_remotelen);
+ rqstp->rq_addrlen = svsk->sk_remotelen;
dprintk("svc: socket %p recvfrom(%p, %Zu) = %d\n",
rqstp->rq_sock, iov[0].iov_base, iov[0].iov_len, len);
@@ -925,6 +924,9 @@ svc_tcp_accept(struct svc_sock *svsk)
if (!(newsvsk = svc_setup_socket(serv, newsock, ,
(SVC_SOCK_ANONYMOUS | SVC_SOCK_TEMPORARY
goto failed;
+ memcpy(>sk_remote, , slen);
+ newsvsk->sk_remotelen = slen;
+
svc_sock_received(newsvsk);
/* make sure that we don't have too many active connections.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 009 of 14] knfsd: SUNRPC: Make rq_daddr field address-version independent
From: Chuck Lever <[EMAIL PROTECTED]>
The rq_daddr field must support larger addresses.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./include/linux/sunrpc/svc.h | 15 +++
./net/sunrpc/svcsock.c |4 ++--
2 files changed, 13 insertions(+), 6 deletions(-)
diff .prev/include/linux/sunrpc/svc.h ./include/linux/sunrpc/svc.h
--- .prev/include/linux/sunrpc/svc.h2007-02-02 15:22:32.0 +1100
+++ ./include/linux/sunrpc/svc.h2007-02-02 15:22:32.0 +1100
@@ -11,6 +11,7 @@
#define SUNRPC_SVC_H
#include
+#include
#include
#include
#include
@@ -191,7 +192,13 @@ static inline void svc_putu32(struct kve
iov->iov_len += sizeof(__be32);
}
-
+union svc_addr_u {
+struct in_addr addr;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+struct in6_addraddr6;
+#endif
+};
+
/*
* The context of a single thread, including the request currently being
* processed.
@@ -227,8 +234,8 @@ struct svc_rqst {
unsigned short
rq_secure : 1; /* secure port */
-
- __be32 rq_daddr; /* dest addr of request - reply
from here */
+ union svc_addr_urq_daddr; /* dest addr of request
+* - reply from here */
void * rq_argp;/* decoded arguments */
void * rq_resp;/* xdr'd results */
@@ -308,7 +315,7 @@ struct svc_deferred_req {
struct svc_sock *svsk;
struct sockaddr_storage addr; /* where reply must go */
size_t addrlen;
- __be32 daddr; /* where reply must come from */
+ union svc_addr_udaddr; /* where reply must come from */
struct cache_deferred_req handle;
int argslen;
__be32 args[0];
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-02-02 15:22:32.0 +1100
+++ ./net/sunrpc/svcsock.c 2007-02-02 15:22:32.0 +1100
@@ -476,7 +476,7 @@ svc_sendto(struct svc_rqst *rqstp, struc
cmh->cmsg_level = SOL_IP;
cmh->cmsg_type = IP_PKTINFO;
pki->ipi_ifindex = 0;
- pki->ipi_spec_dst.s_addr = rqstp->rq_daddr;
+ pki->ipi_spec_dst.s_addr = rqstp->rq_daddr.addr.s_addr;
if (sock_sendmsg(sock, , 0) < 0)
goto out;
@@ -750,7 +750,7 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
rqstp->rq_addrlen = sizeof(struct sockaddr_in);
/* Remember which interface received this request */
- rqstp->rq_daddr = skb->nh.iph->daddr;
+ rqstp->rq_daddr.addr.s_addr = skb->nh.iph->daddr;
if (skb_is_nonlinear(skb)) {
/* we have to copy */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 014 of 14] knfsd: SUNRPC: fix up svc_create_socket() to take a sockaddr struct + length
From: Chuck Lever <[EMAIL PROTECTED]>
Replace existing svc_create_socket() API to allow callers to pass addresses
larger than a sockaddr_in.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-02-02 15:22:58.0 +1100
+++ ./net/sunrpc/svcsock.c 2007-02-02 15:22:59.0 +1100
@@ -1691,7 +1691,7 @@ EXPORT_SYMBOL_GPL(svc_addsock);
* Create socket for RPC service.
*/
static int svc_create_socket(struct svc_serv *serv, int protocol,
- struct sockaddr_in *sin, int flags)
+ struct sockaddr *sin, int len, int flags)
{
struct svc_sock *svsk;
struct socket *sock;
@@ -1701,8 +1701,7 @@ static int svc_create_socket(struct svc_
dprintk("svc: svc_create_socket(%s, %d, %s)\n",
serv->sv_program->pg_name, protocol,
- __svc_print_addr((struct sockaddr *) sin, buf,
- sizeof(buf)));
+ __svc_print_addr(sin, buf, sizeof(buf)));
if (protocol != IPPROTO_UDP && protocol != IPPROTO_TCP) {
printk(KERN_WARNING "svc: only UDP and TCP "
@@ -1711,15 +1710,15 @@ static int svc_create_socket(struct svc_
}
type = (protocol == IPPROTO_UDP)? SOCK_DGRAM : SOCK_STREAM;
- if ((error = sock_create_kern(PF_INET, type, protocol, )) < 0)
+ error = sock_create_kern(sin->sa_family, type, protocol, );
+ if (error < 0)
return error;
svc_reclassify_socket(sock);
if (type == SOCK_STREAM)
- sock->sk->sk_reuse = 1; /* allow address reuse */
- error = kernel_bind(sock, (struct sockaddr *) sin,
- sizeof(*sin));
+ sock->sk->sk_reuse = 1; /* allow address reuse */
+ error = kernel_bind(sock, sin, len);
if (error < 0)
goto bummer;
@@ -1799,7 +1798,8 @@ int svc_makesock(struct svc_serv *serv,
};
dprintk("svc: creating socket proto = %d\n", protocol);
- return svc_create_socket(serv, protocol, , flags);
+ return svc_create_socket(serv, protocol, (struct sockaddr *) ,
+ sizeof(sin), flags);
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 013 of 14] knfsd: SUNRPC: support IPv6 addresses in RPC server's UDP receive path.
From: Chuck Lever <[EMAIL PROTECTED]>
Add support for IPv6 addresses in the RPC server's UDP receive path.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./include/linux/sunrpc/svc.h |5 +++
./net/sunrpc/svcsock.c | 55 +++
2 files changed, 50 insertions(+), 10 deletions(-)
diff .prev/include/linux/sunrpc/svc.h ./include/linux/sunrpc/svc.h
--- .prev/include/linux/sunrpc/svc.h2007-02-02 15:22:32.0 +1100
+++ ./include/linux/sunrpc/svc.h2007-02-02 15:22:58.0 +1100
@@ -270,6 +270,11 @@ static inline struct sockaddr_in *svc_ad
return (struct sockaddr_in *) >rq_addr;
}
+static inline struct sockaddr_in6 *svc_addr_in6(struct svc_rqst *rqst)
+{
+ return (struct sockaddr_in6 *) >rq_addr;
+}
+
static inline struct sockaddr *svc_addr(struct svc_rqst *rqst)
{
return (struct sockaddr *) >rq_addr;
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-02-02 15:22:40.0 +1100
+++ ./net/sunrpc/svcsock.c 2007-02-02 15:22:58.0 +1100
@@ -715,13 +715,55 @@ svc_write_space(struct sock *sk)
}
}
+static void svc_udp_get_sender_address(struct svc_rqst *rqstp,
+ struct sk_buff *skb)
+{
+ switch (rqstp->rq_sock->sk_sk->sk_family) {
+ case AF_INET:
+ /* this seems to come from net/ipv4/udp.c:udp_recvmsg */
+ do {
+ struct sockaddr_in *sin = svc_addr_in(rqstp);
+
+ sin->sin_family = AF_INET;
+ sin->sin_port = skb->h.uh->source;
+ sin->sin_addr.s_addr = skb->nh.iph->saddr;
+ rqstp->rq_addrlen = sizeof(struct sockaddr_in);
+ /* Remember which interface received this request */
+ rqstp->rq_daddr.addr.s_addr = skb->nh.iph->daddr;
+ } while (0);
+ break;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+ case AF_INET6:
+ /* this is derived from net/ipv6/udp.c:udpv6_recvmesg */
+ do {
+ struct sockaddr_in6 *sin6 = svc_addr_in6(rqstp);
+
+ sin6->sin6_family = AF_INET6;
+ sin6->sin6_port = skb->h.uh->source;
+ sin6->sin6_flowinfo = 0;
+ sin6->sin6_scope_id = 0;
+ if (ipv6_addr_type(>sin6_addr) &
+ IPV6_ADDR_LINKLOCAL)
+ sin6->sin6_scope_id = IP6CB(skb)->iif;
+ ipv6_addr_copy(>sin6_addr,
+ >nh.ipv6h->saddr);
+ rqstp->rq_addrlen = sizeof(struct sockaddr_in);
+ /* Remember which interface received this request */
+ ipv6_addr_copy(>rq_daddr.addr6,
+ >nh.ipv6h->saddr);
+ } while (0);
+ break;
+#endif
+ }
+ return;
+}
+
/*
* Receive a datagram from a UDP socket.
*/
static int
svc_udp_recvfrom(struct svc_rqst *rqstp)
{
- struct sockaddr_in *sin = svc_addr_in(rqstp);
struct svc_sock *svsk = rqstp->rq_sock;
struct svc_serv *serv = svsk->sk_server;
struct sk_buff *skb;
@@ -774,16 +816,9 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
len = skb->len - sizeof(struct udphdr);
rqstp->rq_arg.len = len;
- rqstp->rq_prot= IPPROTO_UDP;
-
- /* Get sender address */
- sin->sin_family = AF_INET;
- sin->sin_port = skb->h.uh->source;
- sin->sin_addr.s_addr = skb->nh.iph->saddr;
- rqstp->rq_addrlen = sizeof(struct sockaddr_in);
+ rqstp->rq_prot = IPPROTO_UDP;
- /* Remember which interface received this request */
- rqstp->rq_daddr.addr.s_addr = skb->nh.iph->daddr;
+ svc_udp_get_sender_address(rqstp, skb);
if (skb_is_nonlinear(skb)) {
/* we have to copy */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 010 of 14] knfsd: SUNRPC: teach svc_sendto() to deal with IPv6 addresses
From: Chuck Lever <[EMAIL PROTECTED]>
CMSG_DATA comes in different sizes, depending on address family.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 67 -
1 file changed, 50 insertions(+), 17 deletions(-)
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-02-02 15:22:32.0 +1100
+++ ./net/sunrpc/svcsock.c 2007-02-02 15:22:32.0 +1100
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -438,6 +439,45 @@ svc_wake_up(struct svc_serv *serv)
}
}
+union svc_pktinfo_u {
+ struct in_pktinfo pkti;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+ struct in6_pktinfo pkti6;
+#endif
+};
+
+static void svc_set_cmsg_data(struct svc_rqst *rqstp, struct cmsghdr *cmh)
+{
+ switch (rqstp->rq_sock->sk_sk->sk_family) {
+ case AF_INET:
+ do {
+ struct in_pktinfo *pki = CMSG_DATA(cmh);
+
+ cmh->cmsg_level = SOL_IP;
+ cmh->cmsg_type = IP_PKTINFO;
+ pki->ipi_ifindex = 0;
+ pki->ipi_spec_dst.s_addr = rqstp->rq_daddr.addr.s_addr;
+ cmh->cmsg_len = CMSG_LEN(sizeof(*pki));
+ } while (0);
+ break;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+ case AF_INET6:
+ do {
+ struct in6_pktinfo *pki = CMSG_DATA(cmh);
+
+ cmh->cmsg_level = SOL_IPV6;
+ cmh->cmsg_type = IPV6_PKTINFO;
+ pki->ipi6_ifindex = 0;
+ ipv6_addr_copy(>ipi6_addr,
+ >rq_daddr.addr6);
+ cmh->cmsg_len = CMSG_LEN(sizeof(*pki));
+ } while (0);
+ break;
+#endif
+ }
+ return;
+}
+
/*
* Generic sendto routine
*/
@@ -447,9 +487,8 @@ svc_sendto(struct svc_rqst *rqstp, struc
struct svc_sock *svsk = rqstp->rq_sock;
struct socket *sock = svsk->sk_sock;
int slen;
- charbuffer[CMSG_SPACE(sizeof(struct in_pktinfo))];
+ charbuffer[CMSG_SPACE(sizeof(union svc_pktinfo_u))];
struct cmsghdr *cmh = (struct cmsghdr *)buffer;
- struct in_pktinfo *pki = (struct in_pktinfo *)CMSG_DATA(cmh);
int len = 0;
int result;
int size;
@@ -462,21 +501,15 @@ svc_sendto(struct svc_rqst *rqstp, struc
slen = xdr->len;
if (rqstp->rq_prot == IPPROTO_UDP) {
- /* set the source and destination */
- struct msghdr msg;
- msg.msg_name= >rq_addr;
- msg.msg_namelen = rqstp->rq_addrlen;
- msg.msg_iov = NULL;
- msg.msg_iovlen = 0;
- msg.msg_flags = MSG_MORE;
-
- msg.msg_control = cmh;
- msg.msg_controllen = sizeof(buffer);
- cmh->cmsg_len = CMSG_LEN(sizeof(*pki));
- cmh->cmsg_level = SOL_IP;
- cmh->cmsg_type = IP_PKTINFO;
- pki->ipi_ifindex = 0;
- pki->ipi_spec_dst.s_addr = rqstp->rq_daddr.addr.s_addr;
+ struct msghdr msg = {
+ .msg_name = >rq_addr,
+ .msg_namelen= rqstp->rq_addrlen,
+ .msg_control= cmh,
+ .msg_controllen = sizeof(buffer),
+ .msg_flags = MSG_MORE,
+ };
+
+ svc_set_cmsg_data(rqstp, cmh);
if (sock_sendmsg(sock, , 0) < 0)
goto out;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 011 of 14] knfsd: SUNRPC: add a "generic" function to see if the peer uses a secure port.
From: Chuck Lever <[EMAIL PROTECTED]>
The only reason svcsock.c looks at a sockaddr's port is to check whether
the remote peer is connecting from a privileged port. Refactor this check
to hide processing that is specific to address format.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-02-02 15:22:32.0 +1100
+++ ./net/sunrpc/svcsock.c 2007-02-02 15:22:33.0 +1100
@@ -927,6 +927,22 @@ svc_tcp_data_ready(struct sock *sk, int
wake_up_interruptible(sk->sk_sleep);
}
+static inline int svc_port_is_privileged(struct sockaddr *sin)
+{
+ switch (sin->sa_family) {
+ case AF_INET:
+ return ntohs(((struct sockaddr_in *)sin)->sin_port)
+ < PROT_SOCK;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+ case AF_INET6:
+ return ntohs(((struct sockaddr_in6 *)sin)->sin6_port)
+ < PROT_SOCK;
+#endif
+ default:
+ return 0;
+ }
+}
+
/*
* Accept a TCP connection
*/
@@ -973,7 +989,7 @@ svc_tcp_accept(struct svc_sock *svsk)
* hosts here, but when we get encryption, the IP of the host won't
* tell us anything. For now just warn about unpriv connections.
*/
- if (ntohs(sin.sin_port) >= 1024) {
+ if (!svc_port_is_privileged((struct sockaddr *) )) {
dprintk(KERN_WARNING
"%s: connect from unprivileged port: %s\n",
serv->sv_name,
@@ -1322,7 +1338,6 @@ int
svc_recv(struct svc_rqst *rqstp, long timeout)
{
struct svc_sock *svsk = NULL;
- struct sockaddr_in *sin = svc_addr_in(rqstp);
struct svc_serv *serv = rqstp->rq_server;
struct svc_pool *pool = rqstp->rq_pool;
int len, i;
@@ -1419,7 +1434,7 @@ svc_recv(struct svc_rqst *rqstp, long ti
svsk->sk_lastrecv = get_seconds();
clear_bit(SK_OLD, >sk_flags);
- rqstp->rq_secure = ntohs(sin->sin_port) < PROT_SOCK;
+ rqstp->rq_secure = svc_port_is_privileged(svc_addr(rqstp));
rqstp->rq_chandle.defer = svc_defer;
if (serv->sv_stats)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 012 of 14] knfsd: SUNRPC: Support IPv6 addresses in svc_tcp_accept
From: Chuck Lever <[EMAIL PROTECTED]>
Modify svc_tcp_accept to support connecting on IPv6 sockets.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-02-02 15:22:33.0 +1100
+++ ./net/sunrpc/svcsock.c 2007-02-02 15:22:40.0 +1100
@@ -949,7 +949,8 @@ static inline int svc_port_is_privileged
static void
svc_tcp_accept(struct svc_sock *svsk)
{
- struct sockaddr_in sin;
+ struct sockaddr_storage addr;
+ struct sockaddr *sin = (struct sockaddr *)
struct svc_serv *serv = svsk->sk_server;
struct socket *sock = svsk->sk_sock;
struct socket *newsock;
@@ -976,8 +977,7 @@ svc_tcp_accept(struct svc_sock *svsk)
set_bit(SK_CONN, >sk_flags);
svc_sock_enqueue(svsk);
- slen = sizeof(sin);
- err = kernel_getpeername(newsock, (struct sockaddr *) , );
+ err = kernel_getpeername(newsock, sin, );
if (err < 0) {
if (net_ratelimit())
printk(KERN_WARNING "%s: peername failed (err %d)!\n",
@@ -989,12 +989,11 @@ svc_tcp_accept(struct svc_sock *svsk)
* hosts here, but when we get encryption, the IP of the host won't
* tell us anything. For now just warn about unpriv connections.
*/
- if (!svc_port_is_privileged((struct sockaddr *) )) {
+ if (!svc_port_is_privileged(sin)) {
dprintk(KERN_WARNING
"%s: connect from unprivileged port: %s\n",
serv->sv_name,
- __svc_print_addr((struct sockaddr *) , buf,
- sizeof(buf)));
+ __svc_print_addr(sin, buf, sizeof(buf)));
}
dprintk("%s: connect from %s\n", serv->sv_name,
__svc_print_addr((struct sockaddr *) , buf,
@@ -1008,7 +1007,7 @@ svc_tcp_accept(struct svc_sock *svsk)
if (!(newsvsk = svc_setup_socket(serv, newsock, ,
(SVC_SOCK_ANONYMOUS | SVC_SOCK_TEMPORARY
goto failed;
- memcpy(>sk_remote, , slen);
+ memcpy(>sk_remote, sin, slen);
newsvsk->sk_remotelen = slen;
svc_sock_received(newsvsk);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 005 of 14] knfsd: SUNRPC: Don't set msg_name and msg_namelen when calling sock_recvmsg
From: Chuck Lever <[EMAIL PROTECTED]>
Clean-up: msg_name and msg_namelen are not used by sock_recvmsg, so
don't bother to set them in svc_recvfrom.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-02-02 15:21:55.0 +1100
+++ ./net/sunrpc/svcsock.c 2007-02-02 15:22:22.0 +1100
@@ -561,21 +561,13 @@ static int
svc_recvfrom(struct svc_rqst *rqstp, struct kvec *iov, int nr, int buflen)
{
struct svc_sock *svsk = rqstp->rq_sock;
- struct msghdr msg;
- struct socket *sock;
- int len;
-
- rqstp->rq_addrlen = sizeof(rqstp->rq_addr);
- sock = svsk->sk_sock;
-
- msg.msg_name= >rq_addr;
- msg.msg_namelen = sizeof(rqstp->rq_addr);
- msg.msg_control = NULL;
- msg.msg_controllen = 0;
-
- msg.msg_flags = MSG_DONTWAIT;
+ struct msghdr msg = {
+ .msg_flags = MSG_DONTWAIT,
+ };
+ int len;
- len = kernel_recvmsg(sock, , iov, nr, buflen, MSG_DONTWAIT);
+ len = kernel_recvmsg(svsk->sk_sock, , iov, nr, buflen,
+ msg.msg_flags);
/* sock_recvmsg doesn't fill in the name/namelen, so we must..
*/
@@ -583,7 +575,7 @@ svc_recvfrom(struct svc_rqst *rqstp, str
rqstp->rq_addrlen = svsk->sk_remotelen;
dprintk("svc: socket %p recvfrom(%p, %Zu) = %d\n",
- rqstp->rq_sock, iov[0].iov_base, iov[0].iov_len, len);
+ svsk, iov[0].iov_base, iov[0].iov_len, len);
return len;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 007 of 14] knfsd: SUNRPC: Use sockaddr_storage to store address in svc_deferred_req
From: Chuck Lever <[EMAIL PROTECTED]>
Sockaddr_storage will allow us to store arbitrary socket addresses in
the svc_deferred_req struct.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./include/linux/sunrpc/svc.h |5 +++--
./net/sunrpc/svcsock.c |6 --
2 files changed, 7 insertions(+), 4 deletions(-)
diff .prev/include/linux/sunrpc/svc.h ./include/linux/sunrpc/svc.h
--- .prev/include/linux/sunrpc/svc.h2007-02-02 15:22:31.0 +1100
+++ ./include/linux/sunrpc/svc.h2007-02-02 15:22:31.0 +1100
@@ -292,8 +292,9 @@ static inline void svc_free_res_pages(st
struct svc_deferred_req {
u32 prot; /* protocol (UDP or TCP) */
- struct sockaddr_in addr;
- struct svc_sock *svsk; /* where reply must go */
+ struct svc_sock *svsk;
+ struct sockaddr_storage addr; /* where reply must go */
+ size_t addrlen;
__be32 daddr; /* where reply must come from */
struct cache_deferred_req handle;
int argslen;
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-02-02 15:22:31.0 +1100
+++ ./net/sunrpc/svcsock.c 2007-02-02 15:22:31.0 +1100
@@ -1761,7 +1761,8 @@ svc_defer(struct cache_req *req)
dr->handle.owner = rqstp->rq_server;
dr->prot = rqstp->rq_prot;
- dr->addr = rqstp->rq_addr;
+ memcpy(>addr, >rq_addr, rqstp->rq_addrlen);
+ dr->addrlen = rqstp->rq_addrlen;
dr->daddr = rqstp->rq_daddr;
dr->argslen = rqstp->rq_arg.len >> 2;
memcpy(dr->args, rqstp->rq_arg.head[0].iov_base-skip,
dr->argslen<<2);
@@ -1785,7 +1786,8 @@ static int svc_deferred_recv(struct svc_
rqstp->rq_arg.page_len = 0;
rqstp->rq_arg.len = dr->argslen<<2;
rqstp->rq_prot= dr->prot;
- rqstp->rq_addr= dr->addr;
+ memcpy(>rq_addr, >addr, dr->addrlen);
+ rqstp->rq_addrlen = dr->addrlen;
rqstp->rq_daddr = dr->daddr;
rqstp->rq_respages= rqstp->rq_pages;
return dr->argslen<<2;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 002 of 14] knfsd: SUNRPC: allow creating an RPC service without registering with portmapper
From: Chuck Lever <[EMAIL PROTECTED]>
Sometimes we need to create an RPC service but not register it with the
local portmapper. NFSv4 delegation callback, for example.
Change the svc_makesock() API to allow optionally creating temporary or
permanent sockets, optionally registering with the local portmapper, and
make it return the ephemeral port of the new socket.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/lockd/svc.c | 26 --
./fs/nfs/callback.c | 20 +---
./fs/nfsd/nfssvc.c |6 --
./include/linux/sunrpc/svcsock.h |2 +-
./net/sunrpc/svcsock.c |6 --
5 files changed, 34 insertions(+), 26 deletions(-)
diff .prev/fs/lockd/svc.c ./fs/lockd/svc.c
--- .prev/fs/lockd/svc.c2007-02-02 14:31:52.0 +1100
+++ ./fs/lockd/svc.c2007-02-02 14:40:41.0 +1100
@@ -223,23 +223,29 @@ static int find_socket(struct svc_serv *
return found;
}
+/*
+ * Make any sockets that are needed but not present.
+ * If nlm_udpport or nlm_tcpport were set as module
+ * options, make those sockets unconditionally
+ */
static int make_socks(struct svc_serv *serv, int proto)
{
- /* Make any sockets that are needed but not present.
-* If nlm_udpport or nlm_tcpport were set as module
-* options, make those sockets unconditionally
-*/
- static int warned;
+ static int warned;
int err = 0;
+
if (proto == IPPROTO_UDP || nlm_udpport)
if (!find_socket(serv, IPPROTO_UDP))
- err = svc_makesock(serv, IPPROTO_UDP, nlm_udpport);
- if (err == 0 && (proto == IPPROTO_TCP || nlm_tcpport))
+ err = svc_makesock(serv, IPPROTO_UDP, nlm_udpport,
+ SVC_SOCK_DEFAULTS);
+ if (err >= 0 && (proto == IPPROTO_TCP || nlm_tcpport))
if (!find_socket(serv, IPPROTO_TCP))
- err= svc_makesock(serv, IPPROTO_TCP, nlm_tcpport);
- if (!err)
+ err = svc_makesock(serv, IPPROTO_TCP, nlm_tcpport,
+ SVC_SOCK_DEFAULTS);
+
+ if (err >= 0) {
warned = 0;
- else if (warned++ == 0)
+ err = 0;
+ } else if (warned++ == 0)
printk(KERN_WARNING
"lockd_up: makesock failed, error=%d\n", err);
return err;
diff .prev/fs/nfs/callback.c ./fs/nfs/callback.c
--- .prev/fs/nfs/callback.c 2007-02-02 14:31:52.0 +1100
+++ ./fs/nfs/callback.c 2007-02-02 14:40:41.0 +1100
@@ -106,7 +106,6 @@ static void nfs_callback_svc(struct svc_
int nfs_callback_up(void)
{
struct svc_serv *serv;
- struct svc_sock *svsk;
int ret = 0;
lock_kernel();
@@ -119,17 +118,14 @@ int nfs_callback_up(void)
ret = -ENOMEM;
if (!serv)
goto out_err;
- /* FIXME: We don't want to register this socket with the portmapper */
- ret = svc_makesock(serv, IPPROTO_TCP, nfs_callback_set_tcpport);
- if (ret < 0)
+
+ ret = svc_makesock(serv, IPPROTO_TCP, nfs_callback_set_tcpport,
+ SVC_SOCK_ANONYMOUS);
+ if (ret <= 0)
goto out_destroy;
- if (!list_empty(>sv_permsocks)) {
- svsk = list_entry(serv->sv_permsocks.next,
- struct svc_sock, sk_list);
- nfs_callback_tcpport = ntohs(inet_sk(svsk->sk_sk)->sport);
- dprintk ("Callback port = 0x%x\n", nfs_callback_tcpport);
- } else
- BUG();
+ nfs_callback_tcpport = ret;
+ dprintk("Callback port = 0x%x\n", nfs_callback_tcpport);
+
ret = svc_create_thread(nfs_callback_svc, serv);
if (ret < 0)
goto out_destroy;
@@ -140,6 +136,8 @@ out:
unlock_kernel();
return ret;
out_destroy:
+ dprintk("Couldn't create callback socket or server thread; err = %d\n",
+ ret);
svc_destroy(serv);
out_err:
nfs_callback_info.users--;
diff .prev/fs/nfsd/nfssvc.c ./fs/nfsd/nfssvc.c
--- .prev/fs/nfsd/nfssvc.c 2007-02-02 14:31:52.0 +1100
+++ ./fs/nfsd/nfssvc.c 2007-02-02 14:40:41.0 +1100
@@ -235,7 +235,8 @@ static int nfsd_init_socks(int port)
error = lockd_up(IPPROTO_UDP);
if (error >= 0) {
- error = svc_makesock(nfsd_serv, IPPROTO_UDP, port);
+ error = svc_makesock(nfsd_serv, IPPROTO_UDP, port,
+ SVC_SOCK_DEFAULTS);
if (error < 0)
lockd_down();
}
@@ -245,7 +246,8 @@ static int nfsd_init_socks(int port)
#ifdef CONFIG_NFSD_TCP
error =
[PATCH 006 of 14] knfsd: SUNRPC: Add a function to format the address in an svc_rqst for printing
From: Chuck Lever <[EMAIL PROTECTED]>
There are loads of places where the RPC server assumes that the rq_addr
fields contains an IPv4 address. Top among these are error and debugging
messages that display the server's IP address.
Let's refactor the address printing into a separate function that's smart
enough to figure out the difference between IPv4 and IPv6 addresses.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/lockd/svc.c |6 +--
./fs/lockd/svc4proc.c|7 +--
./fs/lockd/svcproc.c |7 +--
./fs/nfs/callback.c | 12 --
./fs/nfsd/nfsfh.c|7 ++-
./fs/nfsd/nfsproc.c |7 ++-
./include/linux/sunrpc/svc.h |3 +
./net/sunrpc/svcsock.c | 80 +++
8 files changed, 88 insertions(+), 41 deletions(-)
diff .prev/fs/lockd/svc4proc.c ./fs/lockd/svc4proc.c
--- .prev/fs/lockd/svc4proc.c 2007-02-02 15:15:10.0 +1100
+++ ./fs/lockd/svc4proc.c 2007-02-02 15:22:31.0 +1100
@@ -426,10 +426,9 @@ nlm4svc_proc_sm_notify(struct svc_rqst *
dprintk("lockd: SM_NOTIFY called\n");
if (saddr.sin_addr.s_addr != htonl(INADDR_LOOPBACK)
|| ntohs(saddr.sin_port) >= 1024) {
- printk(KERN_WARNING
- "lockd: rejected NSM callback from %08x:%d\n",
- ntohl(rqstp->rq_addr.sin_addr.s_addr),
- ntohs(rqstp->rq_addr.sin_port));
+ char buf[RPC_MAX_ADDRBUFLEN];
+ printk(KERN_WARNING "lockd: rejected NSM callback from %s\n",
+ svc_print_addr(rqstp, buf, sizeof(buf)));
return rpc_system_err;
}
diff .prev/fs/lockd/svc.c ./fs/lockd/svc.c
--- .prev/fs/lockd/svc.c2007-02-02 15:15:10.0 +1100
+++ ./fs/lockd/svc.c2007-02-02 15:22:31.0 +1100
@@ -141,6 +141,7 @@ lockd(struct svc_rqst *rqstp)
*/
while ((nlmsvc_users || !signalled()) && nlmsvc_pid == current->pid) {
long timeout = MAX_SCHEDULE_TIMEOUT;
+ char buf[RPC_MAX_ADDRBUFLEN];
if (signalled()) {
flush_signals(current);
@@ -175,11 +176,10 @@ lockd(struct svc_rqst *rqstp)
break;
}
- dprintk("lockd: request from %08x\n",
- (unsigned)ntohl(rqstp->rq_addr.sin_addr.s_addr));
+ dprintk("lockd: request from %s\n",
+ svc_print_addr(rqstp, buf, sizeof(buf)));
svc_process(rqstp);
-
}
flush_signals(current);
diff .prev/fs/lockd/svcproc.c ./fs/lockd/svcproc.c
--- .prev/fs/lockd/svcproc.c2007-02-02 15:15:10.0 +1100
+++ ./fs/lockd/svcproc.c2007-02-02 15:22:31.0 +1100
@@ -457,10 +457,9 @@ nlmsvc_proc_sm_notify(struct svc_rqst *r
dprintk("lockd: SM_NOTIFY called\n");
if (saddr.sin_addr.s_addr != htonl(INADDR_LOOPBACK)
|| ntohs(saddr.sin_port) >= 1024) {
- printk(KERN_WARNING
- "lockd: rejected NSM callback from %08x:%d\n",
- ntohl(rqstp->rq_addr.sin_addr.s_addr),
- ntohs(rqstp->rq_addr.sin_port));
+ char buf[RPC_MAX_ADDRBUFLEN];
+ printk(KERN_WARNING "lockd: rejected NSM callback from %s\n",
+ svc_print_addr(rqstp, buf, sizeof(buf)));
return rpc_system_err;
}
diff .prev/fs/nfs/callback.c ./fs/nfs/callback.c
--- .prev/fs/nfs/callback.c 2007-02-02 15:15:10.0 +1100
+++ ./fs/nfs/callback.c 2007-02-02 15:22:31.0 +1100
@@ -71,6 +71,8 @@ static void nfs_callback_svc(struct svc_
complete(_callback_info.started);
for(;;) {
+ char buf[RPC_MAX_ADDRBUFLEN];
+
if (signalled()) {
if (nfs_callback_info.users == 0)
break;
@@ -88,8 +90,8 @@ static void nfs_callback_svc(struct svc_
__FUNCTION__, -err);
break;
}
- dprintk("%s: request from %u.%u.%u.%u\n", __FUNCTION__,
- NIPQUAD(rqstp->rq_addr.sin_addr.s_addr));
+ dprintk("%s: request from %s\n", __FUNCTION__,
+ svc_print_addr(rqstp, buf, sizeof(buf)));
svc_process(rqstp);
}
@@ -166,13 +168,17 @@ static int nfs_callback_authenticate(str
{
struct sockaddr_in *addr = >rq_addr;
struct nfs_client *clp;
+ char buf[RPC_MAX_ADDRBUFLEN];
/* Don't talk to strangers */
clp = nfs_find_client(addr, 4);
if (clp == NULL)
return SVC_DROP;
- dprintk("%s: %u.%u.%u.%u NFSv4
[PATCH 000 of 14] knfsd: Preparation for IPv6 support in NFS server.
Hi Andrew, could you please remove knfsd-sunrpc-update-internal-api-separate-pmap-register-and-temp-sockets.patch knfsd-sunrpc-allow-creating-an-rpc-service-without-registering-with-portmapper.patch knfsd-sunrpc-cache-remote-peers-address-in-svc_sock.patch knfsd-sunrpc-use-sockaddr_storage-to-store-address-in-svc_deferred_req.patch knfsd-sunrpc-add-a-function-to-format-the-address-in-an-svc_rqst-for-printing.patch and #knfsd-sunrpc-provide-room-in-svc_rqst-for-larger-addresses.patch #knfsd-sunrpc-make-rq_daddr-field-address-version-independent.patch #knfsd-sunrpc-teach-svc_sendto-to-deal-with-ipv6-addresses.patch #knfsd-sunrpc-add-a-generic-function-to-see-if-the-peer-uses-a-secure-port.patch #knfsd-sunrpc-support-ipv6-addresses-in-svc_tcp_accept.patch #knfsd-sunrpc-support-ipv6-addresses-in-rpc-servers-udp-receive-path.patch #knfsd-sunrpc-fix-up-svc_create_socket-to-take-a-sockaddr-struct-length.patch and include the following 14 patches instead? They are mostly from Chuck Level and make preparating for IPv6 support in the NFS server. They are *not* for 2.6.20, but should be ok for .21. Thanks, NeilBrown [PATCH 001 of 14] knfsd: SUNRPC: update internal API: separate pmap register and temp sockets [PATCH 002 of 14] knfsd: SUNRPC: allow creating an RPC service without registering with portmapper [PATCH 003 of 14] knfsd: SUNRPC: aplit svc_sock_enqueue out of svc_setup_socket. [PATCH 004 of 14] knfsd: SUNRPC: Cache remote peer's address in svc_sock. [PATCH 005 of 14] knfsd: SUNRPC: Don't set msg_name and msg_namelen when calling sock_recvmsg [PATCH 006 of 14] knfsd: SUNRPC: Add a function to format the address in an svc_rqst for printing [PATCH 007 of 14] knfsd: SUNRPC: Use sockaddr_storage to store address in svc_deferred_req [PATCH 008 of 14] knfsd: SUNRPC: Provide room in svc_rqst for larger addresses [PATCH 009 of 14] knfsd: SUNRPC: Make rq_daddr field address-version independent [PATCH 010 of 14] knfsd: SUNRPC: teach svc_sendto() to deal with IPv6 addresses [PATCH 011 of 14] knfsd: SUNRPC: add a "generic" function to see if the peer uses a secure port. [PATCH 012 of 14] knfsd: SUNRPC: Support IPv6 addresses in svc_tcp_accept [PATCH 013 of 14] knfsd: SUNRPC: support IPv6 addresses in RPC server's UDP receive path. [PATCH 014 of 14] knfsd: SUNRPC: fix up svc_create_socket() to take a sockaddr struct + length - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 001 of 14] knfsd: SUNRPC: update internal API: separate pmap register and temp sockets
From: Chuck Lever <[EMAIL PROTECTED]>
Currently in the RPC server, registering with the local portmapper and
creating "permanent" sockets are tied together. Expand the internal APIs
to allow these two socket characteristics to be separately specified.
This will be externalized in the next patch.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./include/linux/sunrpc/svcsock.h |7 +
./net/sunrpc/svcsock.c | 47 ++-
2 files changed, 34 insertions(+), 20 deletions(-)
diff .prev/include/linux/sunrpc/svcsock.h ./include/linux/sunrpc/svcsock.h
--- .prev/include/linux/sunrpc/svcsock.h2007-02-02 14:32:25.0
+1100
+++ ./include/linux/sunrpc/svcsock.h2007-02-02 14:39:07.0 +1100
@@ -74,4 +74,11 @@ int svc_addsock(struct svc_serv *serv,
char *name_return,
int *proto);
+/*
+ * svc_makesock socket characteristics
+ */
+#define SVC_SOCK_DEFAULTS (0U)
+#define SVC_SOCK_ANONYMOUS (1U << 0) /* don't register with pmap */
+#define SVC_SOCK_TEMPORARY (1U << 1) /* flag socket as temporary */
+
#endif /* SUNRPC_SVCSOCK_H */
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-02-02 14:32:25.0 +1100
+++ ./net/sunrpc/svcsock.c 2007-02-02 14:39:07.0 +1100
@@ -69,7 +69,7 @@
static struct svc_sock *svc_setup_socket(struct svc_serv *, struct socket *,
-int *errp, int pmap_reg);
+int *, int);
static voidsvc_udp_data_ready(struct sock *, int);
static int svc_udp_recvfrom(struct svc_rqst *);
static int svc_udp_sendto(struct svc_rqst *);
@@ -922,7 +922,8 @@ svc_tcp_accept(struct svc_sock *svsk)
*/
newsock->sk->sk_sndtimeo = HZ*30;
- if (!(newsvsk = svc_setup_socket(serv, newsock, , 0)))
+ if (!(newsvsk = svc_setup_socket(serv, newsock, ,
+(SVC_SOCK_ANONYMOUS | SVC_SOCK_TEMPORARY
goto failed;
@@ -1462,12 +1463,14 @@ svc_age_temp_sockets(unsigned long closu
* Initialize socket for RPC use and create svc_sock struct
* XXX: May want to setsockopt SO_SNDBUF and SO_RCVBUF.
*/
-static struct svc_sock *
-svc_setup_socket(struct svc_serv *serv, struct socket *sock,
- int *errp, int pmap_register)
+static struct svc_sock *svc_setup_socket(struct svc_serv *serv,
+ struct socket *sock,
+ int *errp, int flags)
{
struct svc_sock *svsk;
struct sock *inet;
+ int pmap_register = !(flags & SVC_SOCK_ANONYMOUS);
+ int is_temporary = flags & SVC_SOCK_TEMPORARY;
dprintk("svc: svc_setup_socket %p\n", sock);
if (!(svsk = kzalloc(sizeof(*svsk), GFP_KERNEL))) {
@@ -1509,7 +1512,7 @@ svc_setup_socket(struct svc_serv *serv,
svc_tcp_init(svsk);
spin_lock_bh(>sv_lock);
- if (!pmap_register) {
+ if (is_temporary) {
set_bit(SK_TEMP, >sk_flags);
list_add(>sk_list, >sv_tempsocks);
serv->sv_tmpcnt++;
@@ -1553,7 +1556,7 @@ int svc_addsock(struct svc_serv *serv,
else if (so->state > SS_UNCONNECTED)
err = -EISCONN;
else {
- svsk = svc_setup_socket(serv, so, , 1);
+ svsk = svc_setup_socket(serv, so, , SVC_SOCK_DEFAULTS);
if (svsk)
err = 0;
}
@@ -1569,8 +1572,8 @@ EXPORT_SYMBOL_GPL(svc_addsock);
/*
* Create socket for RPC service.
*/
-static int
-svc_create_socket(struct svc_serv *serv, int protocol, struct sockaddr_in *sin)
+static int svc_create_socket(struct svc_serv *serv, int protocol,
+ struct sockaddr_in *sin, int flags)
{
struct svc_sock *svsk;
struct socket *sock;
@@ -1606,8 +1609,8 @@ svc_create_socket(struct svc_serv *serv,
goto bummer;
}
- if ((svsk = svc_setup_socket(serv, sock, , 1)) != NULL)
- return 0;
+ if ((svsk = svc_setup_socket(serv, sock, , flags)) != NULL)
+ return ntohs(inet_sk(svsk->sk_sk)->sport);
bummer:
dprintk("svc: svc_create_socket error = %d\n", -error);
@@ -1657,19 +1660,23 @@ svc_delete_socket(struct svc_sock *svsk)
svc_sock_put(svsk);
}
-/*
- * Make a socket for nfsd and lockd
+/**
+ * svc_makesock - Make a socket for nfsd and lockd
+ * @serv: RPC server structure
+ * @protocol: transport protocol to use
+ * @port: port to use
+ *
*/
-int
-svc_makesock(struct svc_serv *serv, int protocol, unsigned short port)
+int svc_makesock(struct svc_serv
Re: smp and irq conflict
On Thu, 1 Feb 2007 18:46:00 +0100 "Lapo TIN" <[EMAIL PROTECTED]> wrote: > Dear all, > I have a problem with IRQs. > > My pc has a CPU PentiumD945 (dual core) and a 2.6.19smp kernel. > I have two video acquisition board (four bt8t8 each) in the only two pci > slots of my motherboard. Thus I have a total of 8 bttv modules that are > working together, and the /proc/interrupts is as follows: > # cat /proc/interrupts >CPU0 CPU1 > 0: 13575 0 IO-APIC-edge timer > 1: 2 0 IO-APIC-edge i8042 > 4: 11 0 IO-APIC-edge serial > 8: 1 0 IO-APIC-edge rtc > 9: 0 0 IO-APIC-fasteoi acpi > 12: 4 0 IO-APIC-edge i8042 > 14: 22286 0 IO-APIC-edge ide0 > 17: 7073 2097 IO-APIC-fasteoi uhci_hcd:usb5, eth0 > 18: 2525 0 IO-APIC-fasteoi bttv0, bttv7 > 19: 2829 0 IO-APIC-fasteoi bttv1, bttv4 > 20: 2526 0 IO-APIC-fasteoi bttv2, bttv5 > 21: 2226 0 IO-APIC-fasteoi bttv3, bttv6 > 22: 2 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb4 > 23: 86 0 IO-APIC-fasteoi uhci_hcd:usb2 > 24: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 > NMI: 0 0 > LOC: 13484 13502 > ERR: 0 > MIS: 0 > You can see that IRQ18 is shared between bttv0 and bttv7, IRQ19 between > bttv1 and bttv4 and so on. > > Sometimes it crashes. It seems a matter of conflict in IRQ. > With only one video board everything is ok, but with two, they shared irq > and something goes wrong... > How can I tell to the kernel to not to share the IRQ for these boards ? > I think (I don't know if I'm right) that this could be the problem. > > I even tried with another motherboard, and doing cat /proc/interrupts the > situation was the same, except for 'eth0' that was together with bttv0 and > bttv7... so it was even worst ! it crashes after few minutes. > > I tried to read IO-APIC.txt in Documentation/i386/ folder, but I didn't > understand how to avoid the coupling of IRQ. > Thanks Should be OK. Can you provide us with any kernel output from these crashes? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/9] x86_64: reliable TSC-based gettimeofday
On Thu, 01 Feb 2007 10:59:52 +0100 [EMAIL PROTECTED] wrote: > TSC-based x86_64 timekeeping implementation I worry about the relationship between this work and all the time-management changes in -mm. If Andi to were to merge all this stuff under that then I expect various catastrophes would ensue. Have you checked to determine the severity of the overlaps? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20-rc6] pktcdvd doesn't work
On Fri, 2 Feb 2007 03:33:43 +0100 Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 01, 2007 at 06:21:47PM -0800, Andrew Morton wrote:
> > On Fri, 2 Feb 2007 00:07:52 +0100 Luca Tettamanti <[EMAIL PROTECTED]> wrote:
> >
> > > Il Thu, Feb 01, 2007 at 12:30:44AM +0100, Adrian Bunk ha scritto:
> > > > On Tue, Jan 30, 2007 at 08:53:19PM +0100, Luca Tettamanti wrote:
> > > > > Hi,
> > > > > pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
> > > > > is written to the device is lost after umount.
> > > > > I rarely use pktcdvd but at some point it used to work on my system.
> > > > >
> > > > > This is what I'm doing:
> > > > >
> > > > > [EMAIL PROTECTED]:/tmp# cdrwtool -d /dev/scd0 -q
> > > > > using device /dev/scd0
> > > > > 1029KB internal buffer
> > > > > setting write speed to 12x
> > > > > Settings for /dev/scd0:
> > > > > Fixed packets, size 32
> > > > > Mode-2 disc
> > > > >...
> > > >
> > > > Does 2.6.20-rc7 work?
> > > > If no, does it work after applying the attached patch?
> > > > If no, does 2.6.19.2 work?
> > >
> > > Git current + the following patch works.
> > >
> > > > diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> > > > index 6246219..7c95c76 100644
> > > > --- a/drivers/block/pktcdvd.c
> > > > +++ b/drivers/block/pktcdvd.c
> > > > @@ -765,34 +765,47 @@ static inline struct bio
> > > > *pkt_get_list_first(struct bio **list_head, struct bio
> > > > */
> > > > static int pkt_generic_packet(struct pktcdvd_device *pd, struct
> > > > packet_command *cgc)
> > > > {
> > > > - request_queue_t *q = bdev_get_queue(pd->bdev);
> > > > + char sense[SCSI_SENSE_BUFFERSIZE];
> >
> > Where did this patch come from?
>
> It's a revert of the commits 3b00315799d78f76531b71435fbc2643cd71ae4c
> and 406c9b605cbc45151c03ac9a3f95e9acf050808c
>
Oh. That's
[SCSI] untangle scsi_prep_fn
and
[PATCH] Fix BUG at drivers/scsi/scsi_lib.c:1118 caused by "pktsetup dvd /dev
so this is a post-2.6.18 regression, yes?
do we know why this is happening?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.20-rc6-mm3
On Thu, Feb 01, 2007 at 08:18:57PM +0100, Jens Axboe wrote: > That down() probably wants a replug to precede it. Probably something > like: > > if (atomic_read(>b_io_remaining)) > blk_replug_current_nested(); > > for xfs_buf_wait_unpin() and xfs_buf_lock(). Does this fix it? Jens, this patch looks like you originally removed the explicit unplug calls that XFS used to prevent metadata I/O hangs and now you are putting them back. Correct? Reading on from Andrew's earlier comments, shouldn't XFS have worked unchanged? I'm just trying to understand why you removed the explicit unplugs in the first place. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Cpuset aware writeback
On Thu, 1 Feb 2007 18:16:05 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Thu, 1 Feb 2007, Ethan Solomita wrote: > > >Hi Christoph -- has anything come of resolving the NFS / OOM concerns > > that > > Andrew Morton expressed concerning the patch? I'd be happy to see some > > progress on getting this patch (i.e. the one you posted on 1/23) through. > > Peter Zilkstra addressed the NFS issue. Did he? Are you yet in a position to confirm 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: 2.6.18-stable release plans?
On Wed, 24 Jan 2007 22:37:20 GMT, Chris Rankin said: > --- Mark Rustad <[EMAIL PROTECTED]> wrote: > > Well, do you have ECC memory? If not, it is at least possible that > > that the solar flares that occurred last month may have affected your > > system. > > I am going to assume that you are being facaetious, because it would be the > rarified pinnacle of > supreme arrogance to suggest that a cosmic ray event is a more likely > explanation than a bug in > the kernel. Sorry for the late reply, but cosmic ray events (actually, self-induced alpha particle events from decays within the chipset itself) *are* a likely explanation: http://stason.org/TULARC/pc/pc_hardware_faq/2_20_What_does_parity_ECC_memory_protect_the_system_from.html Most important take-away here: "With 100 million computers in use today, we should expect roughly 6 million single bit errors per year. Computer hardware and software companies must receive thousands of "side effect" bug reports and support calls due to memory errors alone. The costs of NOT including parity memory must be huge!" pgpntJpwhIfS4.pgp Description: PGP signature
Re: [Fastboot] [PATCH] kexec: Fix CONFIG_SMP=n compilation (ia64)
On Fri, Feb 02, 2007 at 11:01:21AM +0800, Zou, Nanhai wrote:
> > > > void
> > > > machine_crash_shutdown(struct pt_regs *pt)
> > > > @@ -132,11 +134,12 @@ kdump_cpu_freeze(struct unw_frame_info *
> > > > atomic_inc(_cpu_freezed);
> > > > kdump_status[cpuid] = 1;
> > > > mb();
> > > > - if (cpuid == 0) {
> > > > - for (;;)
> > > > - cpu_relax();
> > > > - } else
> > > > +#ifdef CONFIG_HOTPLUG_CPU
> > > > + if (cpuid != 0)
> > > > ia64_jump_to_sal(_boot_rendez_state[cpuid]);
> > > > +#endif
> > > > + for (;;)
> > > > + cpu_relax();
> > > > }
> > >
> > > I trust ia64_jump_to_sal doesn't return.
> >
> > So do I. The main problem with the compilation seems to be that
> > ia64_jump_to_sal() only exists if CONFIG_HOTPLUG_CPU=y.
> > (include/asm-ia64/sal.h, arch/ia64/kernel/head.S)
> >
> This may cause problem on SN platform.
> I remember SN requires cpu0 return to SAL rendez loop to do IRQ redirection.
> However this needs SGI people to confirm...
Does this mean that CONFIG_HOTPLUG_CPU may be required for kdump
on the SN platform?
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/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/
[PATCH -mm] Make rcupreempt.c compile with CONFIG_RCU_TRACE not set
RCU_TRACE is always defined.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
---
diff -pur rc6-mm2/kernel/rcupreempt.c rc6-mm2-kw/kernel/rcupreempt.c
--- rc6-mm2/kernel/rcupreempt.c 2007-01-30 00:08:21.0 +0100
+++ rc6-mm2-kw/kernel/rcupreempt.c 2007-01-29 11:07:43.0 +0100
@@ -619,7 +619,7 @@ void synchronize_kernel(void)
synchronize_rcu();
}
-#ifdef RCU_TRACE
+#ifdef CONFIG_RCU_TRACE
int *rcupreempt_flipctr(int cpu)
{
return _cpu(rcu_flipctr, cpu)[0];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4 of 4] Introduce aio system call submission and completion system calls
On Thu, Feb 01, 2007 at 02:18:55PM -0800, Zach Brown wrote: > >Wooo ...hold on ... I think this is swinging out of perspective :) > > I'm sorry, but I don't. I think using the EIOCBRETRY method in > complicated code paths requires too much maintenance cost to justify > its benefits. We can agree to disagree on that judgement :). I don't disagree about limitations of the EIOCBRETRY approach, nor do I recommend it for all sorts of complicated code paths. It is only good as an approximation for specific blocking points involving idempotent behaviour, and I was trying to emphasise that that is *all* it was ever intended for. I certainly do not see it as a viable path to make all syscalls asynchronous, or to address all blocking points in filesystem IO. And I do like the general direction of your approach, only need to think deeper about the details like how to reduce stack per IO request so this can scale better. So we don't disagree as much as you think :) The point where we seem to disagree is that I think there is goodness in maintaining the conceptual clarity between what parts of the operation assume that it is executing in the original submitters context. For the IO paths this is what allows things like readahead and writeback to work and to cluster operations which may end up to/from multiple submitters. This means that if there is some context that is needed thereafter it could be associated with the IO request (as an argument or in some other manner), so that this division is still maintained. Regards Suparna > > - z > > -- > To unsubscribe, send a message with 'unsubscribe linux-aio' in > the body to [EMAIL PROTECTED] For more info on Linux AIO, > see: http://www.kvack.org/aio/ > Don't email: mailto:"[EMAIL PROTECTED]">[EMAIL PROTECTED] -- Suparna Bhattacharya ([EMAIL PROTECTED]) Linux Technology Center IBM Software Lab, India - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Should io(read|write)(8|16|32)_rep take (const|) volatile u(8|16|32) __iomem *addr?
Michael K. Edwards wrote: It looks to me, by comparison to memcpy_(from|to)io, as if the volatiles ought to be there. It also looks to me like the void * parameters should be u(8|16|32) * instead, so the compiler knows what alignment to expect (the implementations would generally fail or suck on non-aligned arguments). (That would also be more consistent with the fact that the length parameters are in (8|16|32)-bit units, not octets.) Opinions? The real question is whether or not gcc does anything sane with "const volatile", which may incorrectly sound oxymoronic to some people (it's not, const means "this element must not be written to" and volatile means "reading or writing this element has side effects".) I would argue the right thing to do is to do the patch assuming gcc is sane, and let it sit in -mm for a kernel cycle or two. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 10/10] cxgb3 - Add dual licensing
On Tue, 2007-01-30 at 19:44 -0800, Divy Le Ray wrote: > Dual licensing, needed for OFED 1.2 Hi, did you get permission from all the people who contributed code to your driver ? If not.. that'd be a problem -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.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: [PATCH] Ban module license tag string termination trick
> But you're right, the MODULE_LICENSE tag really does imply that > licenses other than the GPL are ok. yup.. BSD licensed modules are clearly ok as well.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] kexec: Fix CONFIG_SMP=n compilation (ia64)
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Magnus Damm
> Sent: 2007年2月2日 10:39
> To: Andrew Morton
> Cc: Magnus Damm; linux-kernel@vger.kernel.org; linux-ia64@vger.kernel.org;
> Luck, Tony; fastboot@lists.osdl.org
> Subject: Re: [PATCH] kexec: Fix CONFIG_SMP=n compilation (ia64)
>
> On 2/2/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > (added ia64 list)
> > (added ia64 maintainer)
> > (added kexec list)
>
> Sorry about that.
>
> > On Thu, 01 Feb 2007 22:13:47 +0900
> > Magnus Damm <[EMAIL PROTECTED]> wrote:
> >
> > > kexec: Fix CONFIG_SMP=n compilation (ia64)
> > >
> > > This patch makes it possible to compile kexec for ia64 without SMP
> > > support.
> > >
> >
> > Please always include the compiler stderr when fixing build errors or
> > warnings.
>
> Ok, will do. With CONFIG_SMP=n and CONFIG_HOTPLUG_CPU=n:
>
> CC arch/ia64/kernel/machine_kexec.o
> arch/ia64/kernel/machine_kexec.c: In function `machine_shutdown':
> arch/ia64/kernel/machine_kexec.c:77: warning: implicit declaration of
> function `cpu_down'
> AS arch/ia64/kernel/relocate_kernel.o
> CC arch/ia64/kernel/crash.o
> arch/ia64/kernel/crash.c: In function `kdump_cpu_freeze':
> arch/ia64/kernel/crash.c:139: warning: implicit declaration of
> function `ia64_jump_to_sal'
> arch/ia64/kernel/crash.c:139: error: `sal_boot_rendez_state'
> undeclared (first use in this function)
> arch/ia64/kernel/crash.c:139: error: (Each undeclared identifier is
> reported only once
> arch/ia64/kernel/crash.c:139: error: for each function it appears in.)
> arch/ia64/kernel/crash.c: At top level:
> arch/ia64/kernel/crash.c:84: warning: 'kdump_wait_cpu_freeze' defined
> but not used
> make[1]: *** [arch/ia64/kernel/crash.o] Error 1
> make: *** [arch/ia64/kernel] Error 2
> [EMAIL PROTECTED] ~/build/kernel/linux-2.6.20-rc7 $
>
> > > --- 0002/arch/ia64/kernel/crash.c
> > > +++ work/arch/ia64/kernel/crash.c 2007-02-01 12:42:38.0
> +0900
> > > @@ -79,6 +79,7 @@ crash_save_this_cpu()
> > > final_note(buf);
> > > }
> > >
> > > +#ifdef CONFIG_SMP
> > > static int
> > > kdump_wait_cpu_freeze(void)
> > > {
> > > @@ -91,6 +92,7 @@ kdump_wait_cpu_freeze(void)
> > > }
> > > return 1;
> > > }
> > > +#endif
> >
> > I think this is a warning fix?
>
> Yes. The file already has some CONFIG_SMP #ifdeffery in it but not
> enough to compile properly.
>
> > > void
> > > machine_crash_shutdown(struct pt_regs *pt)
> > > @@ -132,11 +134,12 @@ kdump_cpu_freeze(struct unw_frame_info *
> > > atomic_inc(_cpu_freezed);
> > > kdump_status[cpuid] = 1;
> > > mb();
> > > - if (cpuid == 0) {
> > > - for (;;)
> > > - cpu_relax();
> > > - } else
> > > +#ifdef CONFIG_HOTPLUG_CPU
> > > + if (cpuid != 0)
> > > ia64_jump_to_sal(_boot_rendez_state[cpuid]);
> > > +#endif
> > > + for (;;)
> > > + cpu_relax();
> > > }
> >
> > I trust ia64_jump_to_sal doesn't return.
>
> So do I. The main problem with the compilation seems to be that
> ia64_jump_to_sal() only exists if CONFIG_HOTPLUG_CPU=y.
> (include/asm-ia64/sal.h, arch/ia64/kernel/head.S)
>
This may cause problem on SN platform.
I remember SN requires cpu0 return to SAL rendez loop to do IRQ redirection.
However this needs SGI people to confirm...
Thanks
Zou Nan hai
>
> Thanks!
>
> / magnus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi_lib.c: continue after MEDIUM_ERROR
James Bottomley wrote: On Thu, 2007-02-01 at 15:02 -0500, Mark Lord wrote: .. One thing that could be even better than the patch below, would be to have it perhaps skip the entire bio that includes the failed sector, rather than only the bad sector itself. Er ... define "skip over the bio". A bio is simply a block representation for a bunch of sg elements coming in to the elevator. Exactly. Or rather, a block of sg_elements from a single point of request, is it not? Mostly what we see in SCSI is a single bio per request, so skipping the bio is really the current behaviour (to fail the rest of the request). Very good. That's what it's supposed to do. But if each request contained only a single bio, then all of Jens' work on IO scheduling would be for nothing, n'est-ce pas? In the case where a request consists of multiple bio's which have been merged under a single request struct, we really should give at least one attempt to each bio. This way, in most cases, only the process that requested the failed sector(s) will see an error, not the innocent victims that happened to get merged onto the end. Which could be very critical stuff (or not -- it could be quite random). So the time factor works out to one disk I/O timeout per failed bio. That's what would have happened with the NOP scheduler anyway. On the sytems I'm working with, I don't see huge numbers of bad sectors. What they tend to show is just one or two bad sectors, widely scattered. So: I think doing that might address most concerns expressed here. Have you got an alternate suggestion, James? Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] kexec: Fix CONFIG_SMP=n compilation (ia64)
On 2/2/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
(added ia64 list)
(added ia64 maintainer)
(added kexec list)
Sorry about that.
On Thu, 01 Feb 2007 22:13:47 +0900
Magnus Damm <[EMAIL PROTECTED]> wrote:
> kexec: Fix CONFIG_SMP=n compilation (ia64)
>
> This patch makes it possible to compile kexec for ia64 without SMP support.
>
Please always include the compiler stderr when fixing build errors or
warnings.
Ok, will do. With CONFIG_SMP=n and CONFIG_HOTPLUG_CPU=n:
CC arch/ia64/kernel/machine_kexec.o
arch/ia64/kernel/machine_kexec.c: In function `machine_shutdown':
arch/ia64/kernel/machine_kexec.c:77: warning: implicit declaration of
function `cpu_down'
AS arch/ia64/kernel/relocate_kernel.o
CC arch/ia64/kernel/crash.o
arch/ia64/kernel/crash.c: In function `kdump_cpu_freeze':
arch/ia64/kernel/crash.c:139: warning: implicit declaration of
function `ia64_jump_to_sal'
arch/ia64/kernel/crash.c:139: error: `sal_boot_rendez_state'
undeclared (first use in this function)
arch/ia64/kernel/crash.c:139: error: (Each undeclared identifier is
reported only once
arch/ia64/kernel/crash.c:139: error: for each function it appears in.)
arch/ia64/kernel/crash.c: At top level:
arch/ia64/kernel/crash.c:84: warning: 'kdump_wait_cpu_freeze' defined
but not used
make[1]: *** [arch/ia64/kernel/crash.o] Error 1
make: *** [arch/ia64/kernel] Error 2
[EMAIL PROTECTED] ~/build/kernel/linux-2.6.20-rc7 $
> --- 0002/arch/ia64/kernel/crash.c
> +++ work/arch/ia64/kernel/crash.c 2007-02-01 12:42:38.0 +0900
> @@ -79,6 +79,7 @@ crash_save_this_cpu()
> final_note(buf);
> }
>
> +#ifdef CONFIG_SMP
> static int
> kdump_wait_cpu_freeze(void)
> {
> @@ -91,6 +92,7 @@ kdump_wait_cpu_freeze(void)
> }
> return 1;
> }
> +#endif
I think this is a warning fix?
Yes. The file already has some CONFIG_SMP #ifdeffery in it but not
enough to compile properly.
> void
> machine_crash_shutdown(struct pt_regs *pt)
> @@ -132,11 +134,12 @@ kdump_cpu_freeze(struct unw_frame_info *
> atomic_inc(_cpu_freezed);
> kdump_status[cpuid] = 1;
> mb();
> - if (cpuid == 0) {
> - for (;;)
> - cpu_relax();
> - } else
> +#ifdef CONFIG_HOTPLUG_CPU
> + if (cpuid != 0)
> ia64_jump_to_sal(_boot_rendez_state[cpuid]);
> +#endif
> + for (;;)
> + cpu_relax();
> }
I trust ia64_jump_to_sal doesn't return.
So do I. The main problem with the compilation seems to be that
ia64_jump_to_sal() only exists if CONFIG_HOTPLUG_CPU=y.
(include/asm-ia64/sal.h, arch/ia64/kernel/head.S)
> static int
> --- 0002/arch/ia64/kernel/machine_kexec.c
> +++ work/arch/ia64/kernel/machine_kexec.c 2007-02-01 12:35:46.0
+0900
> @@ -70,12 +70,14 @@ void machine_kexec_cleanup(struct kimage
>
> void machine_shutdown(void)
> {
> +#ifdef CONFIG_SMP
> int cpu;
>
> for_each_online_cpu(cpu) {
> if (cpu != smp_processor_id())
> cpu_down(cpu);
> }
> +#endif
> kexec_disable_iosapic();
> }
hm. I suspect this one should have been #ifndef CONFIG_HOTPLUG_CPU?
Yes, you are right.
Maybe we can replace the entire code block above with smp_send_stop()
later on? That would make the code more similar to the i386 and x86_64
code.
I was wondering if we should have stubs for cpu_down() if !CONFIG_HOTPLUG_CPU,
but perhaps that doesn't make sense.
cpu_down() is only used in a few places so I don't think it's worth it.
I wonder why cpu_down() isn't marked as __cpuexit. Maybe because it is
already wrapped in CONFIG_HOTPLUG_CPU.
Thanks!
/ magnus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/9] Fix HPET init race
On Thu, 01 Feb 2007 10:59:53 +0100 [EMAIL PROTECTED] wrote:
> Fix a race in the initialization of HPET, which might result in a
> 5 minute lockup on boot.
>
What race? Please always describe bugs when fixing them.
>
> Index: linux-2.6.20-rc5/arch/x86_64/kernel/apic.c
> ===
> --- linux-2.6.20-rc5.orig/arch/x86_64/kernel/apic.c
> +++ linux-2.6.20-rc5/arch/x86_64/kernel/apic.c
> @@ -764,10 +767,12 @@ static void setup_APIC_timer(unsigned in
>
> /* wait for irq slice */
> if (vxtime.hpet_address && hpet_use_timer) {
> - int trigger = hpet_readl(HPET_T0_CMP);
> - while (hpet_readl(HPET_COUNTER) >= trigger)
> - /* do nothing */ ;
> - while (hpet_readl(HPET_COUNTER) < trigger)
> + int trigger;
> + do
> + trigger = hpet_readl(HPET_T0_CMP);
> + while (hpet_readl(HPET_COUNTER) >= trigger);
> +
Is this signedness-safe and wraparound-safe? It might be better to make
`trigger' unsigned and do
while (hpet_readl(HPET_COUNTER) - trigger >= 0)
> + while (hpet_readl(HPET_COUNTER) < trigger)
> /* do nothing */ ;
ditto.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.20-rc6] pktcdvd doesn't work
On Thu, Feb 01, 2007 at 06:21:47PM -0800, Andrew Morton wrote:
> On Fri, 2 Feb 2007 00:07:52 +0100 Luca Tettamanti <[EMAIL PROTECTED]> wrote:
>
> > Il Thu, Feb 01, 2007 at 12:30:44AM +0100, Adrian Bunk ha scritto:
> > > On Tue, Jan 30, 2007 at 08:53:19PM +0100, Luca Tettamanti wrote:
> > > > Hi,
> > > > pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
> > > > is written to the device is lost after umount.
> > > > I rarely use pktcdvd but at some point it used to work on my system.
> > > >
> > > > This is what I'm doing:
> > > >
> > > > [EMAIL PROTECTED]:/tmp# cdrwtool -d /dev/scd0 -q
> > > > using device /dev/scd0
> > > > 1029KB internal buffer
> > > > setting write speed to 12x
> > > > Settings for /dev/scd0:
> > > > Fixed packets, size 32
> > > > Mode-2 disc
> > > >...
> > >
> > > Does 2.6.20-rc7 work?
> > > If no, does it work after applying the attached patch?
> > > If no, does 2.6.19.2 work?
> >
> > Git current + the following patch works.
> >
> > > diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> > > index 6246219..7c95c76 100644
> > > --- a/drivers/block/pktcdvd.c
> > > +++ b/drivers/block/pktcdvd.c
> > > @@ -765,34 +765,47 @@ static inline struct bio *pkt_get_list_first(struct
> > > bio **list_head, struct bio
> > > */
> > > static int pkt_generic_packet(struct pktcdvd_device *pd, struct
> > > packet_command *cgc)
> > > {
> > > - request_queue_t *q = bdev_get_queue(pd->bdev);
> > > + char sense[SCSI_SENSE_BUFFERSIZE];
>
> Where did this patch come from?
It's a revert of the commits 3b00315799d78f76531b71435fbc2643cd71ae4c
and 406c9b605cbc45151c03ac9a3f95e9acf050808c
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.20-rc6] pktcdvd doesn't work
On Fri, 2 Feb 2007 00:07:52 +0100 Luca Tettamanti <[EMAIL PROTECTED]> wrote:
> Il Thu, Feb 01, 2007 at 12:30:44AM +0100, Adrian Bunk ha scritto:
> > On Tue, Jan 30, 2007 at 08:53:19PM +0100, Luca Tettamanti wrote:
> > > Hi,
> > > pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that
> > > is written to the device is lost after umount.
> > > I rarely use pktcdvd but at some point it used to work on my system.
> > >
> > > This is what I'm doing:
> > >
> > > [EMAIL PROTECTED]:/tmp# cdrwtool -d /dev/scd0 -q
> > > using device /dev/scd0
> > > 1029KB internal buffer
> > > setting write speed to 12x
> > > Settings for /dev/scd0:
> > > Fixed packets, size 32
> > > Mode-2 disc
> > >...
> >
> > Does 2.6.20-rc7 work?
> > If no, does it work after applying the attached patch?
> > If no, does 2.6.19.2 work?
>
> Git current + the following patch works.
>
> > diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> > index 6246219..7c95c76 100644
> > --- a/drivers/block/pktcdvd.c
> > +++ b/drivers/block/pktcdvd.c
> > @@ -765,34 +765,47 @@ static inline struct bio *pkt_get_list_first(struct
> > bio **list_head, struct bio
> > */
> > static int pkt_generic_packet(struct pktcdvd_device *pd, struct
> > packet_command *cgc)
> > {
> > - request_queue_t *q = bdev_get_queue(pd->bdev);
> > + char sense[SCSI_SENSE_BUFFERSIZE];
Where did this patch come from?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Ban module license tag string termination trick
On Fri, 02 Feb 2007 10:51:23 +1000, Trent Waddington said: > On 2/2/07, Tomas Carnecky <[EMAIL PROTECTED]> wrote: > > Can't you put this somewhere into the documentation: it's our kernel, > > play by our rules, and our rules are, the license is what is visible in > > 'printf(license)'? > > Here I was thinking the rules were: all modules must be GPL and the > jerks who make proprietary modules are just blatantly breaking the > law. But you're right, the MODULE_LICENSE tag really does imply that > licenses other than the GPL are ok. Given that the definition of "derived work" in the software world is still quite squishy and not firmed up, it's not at all clear that proprietary modules are "blatantly" breaking the law. In particular, feel free to cite actual statute or case law that proves unequivocally that modules that have a GPL shim that interface between the kernel and a binary blob are breaking the law. Hint: first you have to prove that the kernel API doesn't qualify as 'scenes a faire' - a tough job when calling a function in any way but the one approved one will cause an oops. ;) pgpn34EMEj9ct.pgp Description: PGP signature
Re: [RFC 0/8] Cpuset aware writeback
On Thu, 1 Feb 2007, Ethan Solomita wrote: >Hi Christoph -- has anything come of resolving the NFS / OOM concerns that > Andrew Morton expressed concerning the patch? I'd be happy to see some > progress on getting this patch (i.e. the one you posted on 1/23) through. Peter Zilkstra addressed the NFS issue. I will submit the patch again as soon as the writeback code stabilizes a bit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SLAB] Shutdown cache_reaper when cpu goes down
On Thu, 1 Feb 2007, Andrew Morton wrote: > Is this bug unique to the changes in -mm, or is it in mainline? Mainline is also affected. However, mainline may need a different fix since the hotplug notifier scheme was changed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Cpuset aware writeback
Hi Christoph -- has anything come of resolving the NFS / OOM concerns that Andrew Morton expressed concerning the patch? I'd be happy to see some progress on getting this patch (i.e. the one you posted on 1/23) through. Thanks, -- Ethan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] EFI x86: pass firmware call parameters on the stack
Frederic Riss wrote: 2007/2/1, bibo,mao <[EMAIL PROTECTED]>: currently x86_64 kernel does not support efi, efi convention comply to MS convention. On ia32 parameter is passed on stack, on x86_64 parameter is passed by registers but that is different from x86_64 linux convention. Is an x86_64 EFI firmware required to have 2 entry points, one x86_64 and one in ia32 mode ? If that's not the case, it means that an i386 kernel won't be able to work correctly on an EFI powered x86_64 box... AFAIK x86_64 EFI firmware now has only one entry point, i386 kernel can not boot up with EFI powered x86_64 box. How about adding EFIAPI prefix before efi runtime service function, this prefix has different definition in different architecture. Have you any objection to the second patch I posted? It's not only a matter of passing arguments, ia64 does quite a lot of things in its wrapper functions. I can easily imagine that such additional work could be added in the i386 wrappers if EFI becomes more widely used. I do not object your second patch if there will be more wrapper functions to be added in i386 efi code. I have to give up my patch:) thanks bibo,mao - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] drivers/isdn/gigaset: new M101 driver
On Thu, 1 Feb 2007 22:12:24 +0100
Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> +/* Kbuild sometimes doesn't set this */
> +#ifndef KBUILD_MODNAME
> +#define KBUILD_MODNAME "asy_gigaset"
> +#endif
That's a subtle way of reporting a kbuild bug ;)
What's the story here?
> --- linux-2.6.20-rc6-mm3-orig/drivers/isdn/gigaset/ser-gigaset.c
> 1970-01-01 01:00:00.0 +0100
> +++ local/drivers/isdn/gigaset/ser-gigaset.c 2007-01-29 23:41:39.0
> +0100
> @@ -0,0 +1,853 @@
> +/* This is the serial hardware link layer (HLL) for the Gigaset 307x isdn
> + * DECT base (aka Sinus 45 isdn) using the RS232 DECT data module M101,
> + * written as a line discipline.
> + *
> + * =
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + * =
> + */
> +
> +#include "gigaset.h"
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Version Information */
> +#define DRIVER_AUTHOR "Tilman Schmidt"
> +#define DRIVER_DESC "Serial Driver for Gigaset 307x using Siemens M101"
> +
> +#define GIGASET_MINORS 1
> +#define GIGASET_MINOR 0
> +#define GIGASET_MODULENAME "ser_gigaset"
> +#define GIGASET_DEVNAME"ttyGS"
> +
> +/* length limit according to Siemens 3070usb-protokoll.doc ch. 2.1 */
> +#define IF_WRITEBUF 264
> +
> +MODULE_AUTHOR(DRIVER_AUTHOR);
> +MODULE_DESCRIPTION(DRIVER_DESC);
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS_LDISC(N_GIGASET_M101);
> +
> +static int startmode = SM_ISDN;
> +module_param(startmode, int, S_IRUGO);
> +MODULE_PARM_DESC(startmode, "initial operation mode");
> +static int cidmode = 1;
> +module_param(cidmode, int, S_IRUGO);
> +MODULE_PARM_DESC(cidmode, "stay in CID mode when idle");
> +
> +static struct gigaset_driver *driver = NULL;
Unneeded initialisation.
> +struct ser_cardstate {
> + struct platform_device dev;
> + struct tty_struct *tty;
> + atomic_trefcnt;
> + struct semaphoredead_sem;
> +};
> +
> +static struct platform_driver device_driver = {
> + .driver = {
> + .name = GIGASET_MODULENAME,
> + },
> +};
> +
> +struct ser_bc_state {};
Does this need kernel-wide scope?
> +static void flush_send_queue(struct cardstate *);
> +
> +/* transmit data from current open skb
> + * result: number of bytes sent or error code < 0
> + */
> +static int write_modem(struct cardstate *cs)
> +{
> + struct tty_struct *tty = cs->hw.ser->tty;
> + struct bc_state *bcs = >bcs[0]; /* only one channel */
> + struct sk_buff *skb = bcs->tx_skb;
> + int sent;
> +
> + if (!tty || !tty->driver || !skb)
> + return -EFAULT;
Is EFAULT appropriate?
Can all these things happen?
> + if (!skb->len) {
> + dev_kfree_skb_any(skb);
> + bcs->tx_skb = NULL;
> + return -EINVAL;
> + }
> +
> + set_bit(TTY_DO_WRITE_WAKEUP, >flags);
Is a client of the tty interface supposed to be diddling tty flags like this?
> + sent = tty->driver->write(tty, skb->data, skb->len);
> + gig_dbg(DEBUG_OUTPUT, "write_modem: sent %d", sent);
> + if (sent < 0) {
> + /* error */
> + flush_send_queue(cs);
> + return sent;
> + }
> + skb_pull(skb, sent);
> + if (!skb->len) {
> + /* skb sent completely */
> + gigaset_skb_sent(bcs, skb);
> +
> + gig_dbg(DEBUG_INTR, "kfree skb (Adr: %lx)!",
> + (unsigned long) skb);
> + dev_kfree_skb_any(skb);
> + bcs->tx_skb = NULL;
> + }
> + return sent;
> +}
> +
> +/*
> + * transmit first queued command buffer
> + * result: number of bytes sent or error code < 0
> + */
> +static int send_cb(struct cardstate *cs)
> +{
> + struct tty_struct *tty = cs->hw.ser->tty;
> + struct cmdbuf_t *cb, *tcb;
> + unsigned long flags;
> + int sent = 0;
> +
> + if (!tty || !tty->driver)
> + return -EFAULT;
> +
> + spin_lock_irqsave(>cmdlock, flags);
> + cb = cs->cmdbuf;
> + spin_unlock_irqrestore(>cmdlock, flags);
It is doubtful if the locking here does anything useful.
> + if (!cb)
> + return 0; /* nothing to do */
> +
> + if (cb->len) {
> + set_bit(TTY_DO_WRITE_WAKEUP, >flags);
> + sent = tty->driver->write(tty, cb->buf + cb->offset, cb->len);
> + if (sent < 0) {
> + /* error */
> + gig_dbg(DEBUG_OUTPUT, "send_cb: write error %d", sent);
> + flush_send_queue(cs);
> + return sent;
> + }
> + cb->offset += sent;
> + cb->len -= sent;
> +
Re: smp and irq conflict
Lapo TIN wrote: I need to capture at 25 frame per second from each channel... So 25 x 8 total frames per second on the pci. So do you think I have to change the motherboard ? What is important ? the chipset ? is there specification I need ? What resolution are you using? 720x480 with 24 bits per pixel and 25fps will use about 25MB/sec on the PCI bus, there is no way you can keep up with 8 channels running on a standard 32-bit 33MHz PCI bus which can only transfer 133 MB/sec at most. If you need this much transfer rate, you likely need PCI Express or PCI-X capture cards or at least a motherboard which has multiple PCI buses (which most desktop boards don't typically have). You may be able to reduce the resolution and/or frame rate in order to allow the PCI bus to cope. Also, do you have enough CPU and disk speed in order to cope with all these streams? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SLAB] Shutdown cache_reaper when cpu goes down
On Thu, 1 Feb 2007 11:13:29 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]> wrote: > Shutdown the cache_reaper if the cpu is brought down and set the > cache_reap.func to NULL. Otherwise hotplug shuts down the reaper for good. > > Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> > > Index: linux-2.6.20-rc6-mm2/mm/slab.c > === > --- linux-2.6.20-rc6-mm2.orig/mm/slab.c 2007-01-29 14:27:34.199229828 > -0600 > +++ linux-2.6.20-rc6-mm2/mm/slab.c2007-01-30 13:55:57.936838878 -0600 > @@ -1271,6 +1271,18 @@ static int __cpuinit cpuup_callback(stru > start_cpu_timer(cpu); > break; > #ifdef CONFIG_HOTPLUG_CPU > + case CPU_DOWN_PREPARE: > + /* > + * Shutdown cache reaper. Note that the cache_chain_mutex is > + * held so that cache_reap() cannot modify reap_work > + * concurrently. > + */ > + cancel_rearming_delayed_work(_cpu(reap_work, cpu)); > + per_cpu(reap_work, cpu).work.func = NULL; > + break; > + case CPU_DOWN_FAILED: > + start_cpu_timer(cpu); > + break; > case CPU_DEAD: > /* >* Even if all the cpus of a node are down, we don't free the Is this bug unique to the changes in -mm, or is it in mainline? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Ban module license tag string termination trick
On 2/2/07, Tomas Carnecky <[EMAIL PROTECTED]> wrote: Can't you put this somewhere into the documentation: it's our kernel, play by our rules, and our rules are, the license is what is visible in 'printf(license)'? Here I was thinking the rules were: all modules must be GPL and the jerks who make proprietary modules are just blatantly breaking the law. But you're right, the MODULE_LICENSE tag really does imply that licenses other than the GPL are ok. Trent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc6-mm3 possible circular lock on mmap_sem
I just noticed this in my logs, from the lock checker:
[ 142.299455]
[ 142.299458] ===
[ 142.299473] [ INFO: possible circular locking dependency detected ]
[ 142.299478] 2.6.20-rc6-mm3 #2
[ 142.299482] ---
[ 142.299547] evolution-data-/6909 is trying to acquire lock:
[ 142.299551] (>mmap_sem){}, at: []
do_page_fault+0x3f6/0x8a0
[ 142.299742]
[ 142.299743] but task is already holding lock:
[ 142.299749] (>latch){}, at: []
get_exclusive_access+0x11/0x20
[ 142.299880]
[ 142.299880] which lock already depends on the new lock.
[ 142.299882]
[ 142.299947]
[ 142.299948] the existing dependency chain (in reverse order) is:
[ 142.300010]
[ 142.300011] -> #1 (>latch){}:
[ 142.300138][] __lock_acquire+0xd48/0xff0
[ 142.300390][] lock_acquire+0x4b/0x70
[ 142.300583][] get_exclusive_access+0x11/0x20
[ 142.300833][] down_write+0x34/0x40
[ 142.301084][] get_exclusive_access+0x11/0x20
[ 142.301277][] mmap_unix_file+0x8e/0x1a0
[ 142.301526][] do_mmap_pgoff+0x4eb/0x820
[ 142.301777][] mark_held_locks+0x76/0xa0
[ 142.301969][] _spin_unlock_irq+0x24/0x30
[ 142.302219][] _spin_unlock_irq+0x24/0x30
[ 142.302468][] elf_map+0xa3/0x100
[ 142.302662][] load_elf_binary+0x920/0x1cd0
[ 142.302912][] kfree+0xd5/0xf0
[ 142.303162][] load_aout_binary+0x0/0x990
[ 142.303356][] load_elf_binary+0x0/0x1cd0
[ 142.303606][] search_binary_handler+0x9d/0x240
[ 142.303857][] load_script+0x211/0x240
[ 142.304050][] load_elf_binary+0x0/0x1cd0
[ 142.304300][] load_script+0x0/0x240
[ 142.304549][] load_script+0x0/0x240
[ 142.304741][] search_binary_handler+0x9d/0x240
[ 142.304991][] do_execve+0x17a/0x220
[ 142.305241][] __call_usermodehelper+0x0/0x80
[ 142.305434][] sys_execve+0x44/0xb0
[ 142.305684][] kernel_execve+0x64/0xd0
[ 142.305878][] __call_usermodehelper+0x0/0x80
[ 142.306127][] call_usermodehelper+0x161/0x170
[ 142.306377][] child_rip+0xa/0x12
[ 142.306569][] _spin_unlock_irq+0x24/0x30
[ 142.306818][] restore_args+0x0/0x30
[ 142.307068][] call_usermodehelper+0x0/0x170
[ 142.307260][] child_rip+0x0/0x12
[ 142.307510][] 0x
[ 142.307752]
[ 142.307752] -> #0 (>mmap_sem){}:
[ 142.307878][] print_circular_bug_header+0xdb/0x100
[ 142.308128][] __lock_acquire+0xc07/0xff0
[ 142.308378][] mark_held_locks+0x76/0xa0
[ 142.308570][] lock_acquire+0x4b/0x70
[ 142.308820][] do_page_fault+0x3f6/0x8a0
[ 142.309013][] down_read+0x37/0x40
[ 142.309263][] do_page_fault+0x3f6/0x8a0
[ 142.309513][] mark_held_locks+0x76/0xa0
[ 142.309705][] error_exit+0x0/0x96
[ 142.309954][] file_read_actor+0x43/0x180
[ 142.310147][] __wait_on_bit_lock+0x6f/0x80
[ 142.310399][] do_generic_mapping_read+0x25b/0x580
[ 142.310649][] file_read_actor+0x0/0x180
[ 142.310841][] generic_file_aio_read+0x19a/0x1f0
[ 142.311091][] do_sync_read+0xdb/0x130
[ 142.311340][] wake_bit_function+0x0/0x30
[ 142.311533][] _spin_unlock+0x17/0x20
[ 142.311783][] reiser4_grab+0xae/0xd0
[ 142.311977][] read_unix_file+0xdb/0x450
[ 142.312227][] vma_merge+0x12b/0x1e0
[ 142.312476][] vfs_read+0xba/0x180
[ 142.312669][] sys_read+0x53/0x90
[ 142.312918][] system_call+0x7e/0x83
[ 142.313111][] 0x
[ 142.313361]
[ 142.313361] other info that might help us debug this:
[ 142.313363]
[ 142.313428] 1 lock held by evolution-data-/6909:
[ 142.313432] #0: (>latch){}, at: []
get_exclusive_access+0x11/0x20
[ 142.313619]
[ 142.313619] stack backtrace:
[ 142.313682]
[ 142.313682] Call Trace:
[ 142.313690] [] print_circular_bug_tail+0x74/0x90
[ 142.313754] [] print_circular_bug_header+0xdb/0x100
[ 142.313760] [] __lock_acquire+0xc07/0xff0
[ 142.313766] [] mark_held_locks+0x76/0xa0
[ 142.313830] [] lock_acquire+0x4b/0x70
[ 142.313835] [] do_page_fault+0x3f6/0x8a0
[ 142.313898] [] down_read+0x37/0x40
[ 142.313904] [] do_page_fault+0x3f6/0x8a0
[ 142.313913] [] mark_held_locks+0x76/0xa0
[ 142.313977] [] error_exit+0x0/0x96
[ 142.313985] [] file_read_actor+0x43/0x180
[ 142.313991] [] __wait_on_bit_lock+0x6f/0x80
[ 142.314055] [] do_generic_mapping_read+0x25b/0x580
[ 142.314060] [] file_read_actor+0x0/0x180
[ 142.314071] [] generic_file_aio_read+0x19a/0x1f0
[ 142.314135] [] do_sync_read+0xdb/0x130
[ 142.314143] [] wake_bit_function+0x0/0x30
[ 142.314150] [] _spin_unlock+0x17/0x20
[ 142.314213] [] reiser4_grab+0xae/0xd0
[ 142.314219] [] read_unix_file+0xdb/0x450
[ 142.314225] []
Fw: [patch] posix timers: RCU optimization for clock_gettime()
The attached patch uses RCU to avoid the need to acquire tasklist_lock
in the single-threaded case of clock_gettime(). It still acquires
tasklist_lock when for a (potentially multithreaded) process. This change
allows realtime applications to frequently monitor CPU consumption of
individual tasks, as requested (and now deployed) by some off-list users.
This has been in Ingo Molnar's -rt patchset since late 2005 with no
problems reported, and tests successfully on 2.6.20-rc6, so I believe
that it is long-since ready for mainline adoption.
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
kernel/posix-cpu-timers.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index: linux/kernel/posix-cpu-timers.c
===
--- linux.orig/kernel/posix-cpu-timers.c
+++ linux/kernel/posix-cpu-timers.c
@@ -304,7 +304,7 @@ int posix_cpu_clock_get(const clockid_t
* should be able to see it.
*/
struct task_struct *p;
- read_lock(_lock);
+ rcu_read_lock();
p = find_task_by_pid(pid);
if (p) {
if (CPUCLOCK_PERTHREAD(which_clock)) {
@@ -313,11 +313,13 @@ int posix_cpu_clock_get(const clockid_t
p, );
}
} else if (p->tgid == pid && p->signal) {
+ read_lock(_lock);
error = cpu_clock_sample_group(which_clock,
p, );
+ read_unlock(_lock);
}
}
- read_unlock(_lock);
+ rcu_read_unlock();
}
if (error)
- End forwarded message -
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Should io(read|write)(8|16|32)_rep take (const|) volatile u(8|16|32) __iomem *addr?
Sorry, I wrote this:
(This is not an ARM-specific question, although the example is on ARM.)
and then sent it to linux-arm-kernel anyway. :-P
I'm writing an ALSA driver for an ARM SoC whose PCM audio interface is
MMIO. ALSA provides copy_from_user_toio and copy_to_user_fromio
routines for this purpose, but the results are not sane, perhaps
because STMIA to I/O addresses is bollixed on this core. I suspect
that the right thing to do is to use iowrite32_rep and ioread32_rep,
approximately like so (slightly modified ALSA code):
/**
* copy_u32s_to_user_fromio - copy data from mmio-space to user-space
* @dst: the destination pointer on user-space
* @src: the source pointer on mmio
* @count: the data size to copy in u32s
*
* Copies the data from mmio-space to user-space.
*
* Returns zero if successful, or non-zero on failure.
*/
static int copy_u32s_to_user_fromio(void __user *dst, const volatile
void __iomem *src, size_t count)
{
u32 buf[80];
count <<= 2;
while (count) {
size_t c = count;
if (c > sizeof(buf))
c = sizeof(buf);
ioread32_rep(src, buf, c>>2);
if (copy_to_user(dst, buf, c))
return -EFAULT;
count -= c;
dst += c;
src += c;
}
return 0;
}
/**
* copy_u32s_from_user_toio - copy data from user-space to mmio-space
* @dst: the destination pointer on mmio-space
* @src: the source pointer on user-space
* @count: the data size to copy in u32s
*
* Copies the data from user-space to mmio-space.
*
* Returns zero if successful, or non-zero on failure.
*/
static int copy_u32s_from_user_toio(volatile void __iomem *dst, const
void __user *src, size_t count)
{
u32 buf[80];
count <<= 2;
while (count) {
size_t c = count;
if (c > sizeof(buf))
c = sizeof(buf);
if (copy_from_user(buf, src, c))
return -EFAULT;
iowrite32_rep(dst, buf, c>>2);
count -= c;
dst += c;
src += c;
}
return 0;
}
Compiling (with GCC 4.1.2 RC1) gives these warnings:
foo.c: In function 'copy_u32s_to_user_fromio':
foo.c:56: warning: passing argument 1 of '__raw_readsl' discards
qualifiers from pointer target type
foo.c: In function 'copy_u32s_from_user_toio':
foo.c:86: warning: passing argument 1 of '__raw_writesl' discards
qualifiers from pointer target type
The qualifiers being discarded are the "volatile"s, which are indeed
not present in the declarations of these functions (which happen to be
ARM's implementation of io(read|write)32_rep):
include/asm-arm/io.h:extern void __raw_writesb(void __iomem *addr,
const void *data, int bytelen);
include/asm-arm/io.h:extern void __raw_writesw(void __iomem *addr,
const void *data, int wordlen);
include/asm-arm/io.h:extern void __raw_writesl(void __iomem *addr,
const void *data, int longlen);
include/asm-arm/io.h:extern void __raw_readsb(const void __iomem
*addr, void *data, int bytelen);
include/asm-arm/io.h:extern void __raw_readsw(const void __iomem
*addr, void *data, int wordlen);
include/asm-arm/io.h:extern void __raw_readsl(const void __iomem
*addr, void *data, int longlen);
It looks to me, by comparison to memcpy_(from|to)io, as if the
volatiles ought to be there. It also looks to me like the void *
parameters should be u(8|16|32) * instead, so the compiler knows what
alignment to expect (the implementations would generally fail or suck
on non-aligned arguments). (That would also be more consistent with
the fact that the length parameters are in (8|16|32)-bit units, not
octets.)
Opinions?
Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kexec: Fix CONFIG_SMP=n compilation (ia64)
(added ia64 list)
(added ia64 maintainer)
(added kexec list)
On Thu, 01 Feb 2007 22:13:47 +0900
Magnus Damm <[EMAIL PROTECTED]> wrote:
> kexec: Fix CONFIG_SMP=n compilation (ia64)
>
> This patch makes it possible to compile kexec for ia64 without SMP support.
>
Please always include the compiler stderr when fixing build errors or
warnings.
>
> Applies on top of 2.6.20-rc7.
>
> arch/ia64/kernel/crash.c | 11 +++
> arch/ia64/kernel/machine_kexec.c |2 ++
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> --- 0002/arch/ia64/kernel/crash.c
> +++ work/arch/ia64/kernel/crash.c 2007-02-01 12:42:38.0 +0900
> @@ -79,6 +79,7 @@ crash_save_this_cpu()
> final_note(buf);
> }
>
> +#ifdef CONFIG_SMP
> static int
> kdump_wait_cpu_freeze(void)
> {
> @@ -91,6 +92,7 @@ kdump_wait_cpu_freeze(void)
> }
> return 1;
> }
> +#endif
I think this is a warning fix?
> void
> machine_crash_shutdown(struct pt_regs *pt)
> @@ -132,11 +134,12 @@ kdump_cpu_freeze(struct unw_frame_info *
> atomic_inc(_cpu_freezed);
> kdump_status[cpuid] = 1;
> mb();
> - if (cpuid == 0) {
> - for (;;)
> - cpu_relax();
> - } else
> +#ifdef CONFIG_HOTPLUG_CPU
> + if (cpuid != 0)
> ia64_jump_to_sal(_boot_rendez_state[cpuid]);
> +#endif
> + for (;;)
> + cpu_relax();
> }
I trust ia64_jump_to_sal doesn't return.
> static int
> --- 0002/arch/ia64/kernel/machine_kexec.c
> +++ work/arch/ia64/kernel/machine_kexec.c 2007-02-01 12:35:46.0
> +0900
> @@ -70,12 +70,14 @@ void machine_kexec_cleanup(struct kimage
>
> void machine_shutdown(void)
> {
> +#ifdef CONFIG_SMP
> int cpu;
>
> for_each_online_cpu(cpu) {
> if (cpu != smp_processor_id())
> cpu_down(cpu);
> }
> +#endif
> kexec_disable_iosapic();
> }
hm. I suspect this one should have been #ifndef CONFIG_HOTPLUG_CPU?
I was wondering if we should have stubs for cpu_down() if !CONFIG_HOTPLUG_CPU,
but perhaps that doesn't make sense.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] filesystem: Disk Errors at boot-time caused by probe of partitions
On Thu, 2007-02-01 at 17:10 -0700, Eric D. Mudama wrote: > In the log you posted, the drive posted 51/04 to your out-of-bounds > request, but these are 59/04, do they span the end of the device or > something? As you can see in the error-log including in the Ubuntu bug report, the 51/04 errors are generated in dma_intr() and occur in the initial phase when the driver is using DMA. After a few of these errors it disables DMA and switches to PIO mode, which is when the 59/04 errors are generated in task_in_intr(). TJ. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.20-rc4-mm1 Reiser4 filesystem freeze and corruption
On Thu, 2007-02-01 at 18:54 +0300, Edward Shishkin wrote: [snip] > Thanks for the dump. > > >[ 3138.456588] [] current_atom_finish_all_fq+0x12e/0x280 > >[ 3138.456661] [] autoremove_wake_function+0x0/0x30 > >[ 3138.456674] [] submit_wb_list+0x11c/0x130 > >[ 3138.456690] [] reiser4_txn_end+0x349/0x530 > >[ 3138.456710] [] reiser4_txn_restart+0x9/0x20 > >[ 3138.456781] [] force_commit_atom+0x50/0x60 > >[ 3138.456793] [] writepages_unix_file+0x671/0x780 > >[ 3138.456824] [] do_writepages+0x43/0x80 > >[ 3138.456838] [] __filemap_fdatawrite_range+0x58/0x70 > >[ 3138.456914] [] do_fsync+0x3d/0xe0 > >[ 3138.456930] [] sys_msync+0x143/0x1f0 > >[ 3138.456945] [] system_call+0x7e/0x83 > > > > > > This is waiting for IO completion, and no success because of new plugging > policy introduced by block layer folks. The attached patch should help. > Andrew, please apply. OK, I have been using it with your patch for many hours and it has not frozen up yet. I believe that the patch did indeed fix it. Thank you. -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/1] filesystem: Disk Errors at boot-time caused by probe of partitions
On 2/1/07, TJ <[EMAIL PROTECTED]> wrote:
short extract ---
DC202XX: Primary channel reset.
ide2: reset: success
hde: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest
Error }
hde: task_in_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
end_request: I/O error, dev hde, sector 238276076
printk: 8 messages suppressed.
Buffer I/O error on device hde2, logical block 47279294
hde: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest
Error }
hde: task_in_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hde: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest
Error }
...
The Model number is Maxtor 6Y060L0.
In the log you posted, the drive posted 51/04 to your out-of-bounds
request, but these are 59/04, do they span the end of the device or
something?
I'd be surprised if the drive clunked because of an out of range
command, that model of drive used a very mature interface firmware
with many generations of testing and qualification.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: smp and irq conflict
I need to capture at 25 frame per second from each channel... So 25 x 8 total frames per second on the pci. So do you think I have to change the motherboard ? What is important ? the chipset ? is there specification I need ? -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Robert Hancock Inviato: venerdì 2 febbraio 2007 0.30 A: Lapo TIN Cc: linux-smp@vger.kernel.org; linux-kernel@vger.kernel.org Oggetto: Re: smp and irq conflict Lapo TIN wrote: > Dear all, > I have a problem with IRQs. > > My pc has a CPU PentiumD945 (dual core) and a 2.6.19smp kernel. > I have two video acquisition board (four bt8t8 each) in the only two pci > slots of my motherboard. Thus I have a total of 8 bttv modules that are > working together, and the /proc/interrupts is as follows: > # cat /proc/interrupts >CPU0 CPU1 > 0: 13575 0 IO-APIC-edge timer > 1: 2 0 IO-APIC-edge i8042 > 4: 11 0 IO-APIC-edge serial > 8: 1 0 IO-APIC-edge rtc > 9: 0 0 IO-APIC-fasteoi acpi > 12: 4 0 IO-APIC-edge i8042 > 14: 22286 0 IO-APIC-edge ide0 > 17: 7073 2097 IO-APIC-fasteoi uhci_hcd:usb5, eth0 > 18: 2525 0 IO-APIC-fasteoi bttv0, bttv7 > 19: 2829 0 IO-APIC-fasteoi bttv1, bttv4 > 20: 2526 0 IO-APIC-fasteoi bttv2, bttv5 > 21: 2226 0 IO-APIC-fasteoi bttv3, bttv6 > 22: 2 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb4 > 23: 86 0 IO-APIC-fasteoi uhci_hcd:usb2 > 24: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 > NMI: 0 0 > LOC: 13484 13502 > ERR: 0 > MIS: 0 > You can see that IRQ18 is shared between bttv0 and bttv7, IRQ19 between > bttv1 and bttv4 and so on. > > Sometimes it crashes. It seems a matter of conflict in IRQ. > With only one video board everything is ok, but with two, they shared irq > and something goes wrong... > How can I tell to the kernel to not to share the IRQ for these boards ? > I think (I don't know if I'm right) that this could be the problem. Usually the IRQ routing is hard-wired on the motherboard, so there's no way to avoid the devices sharing IRQs. Unless the driver is badly buggy this should not cause problems anyway. What kind of video bit rate are you capturing? 8 video capture chips is a pretty heavy load on the PCI bus, maybe something just gets overwhelmed? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Ban module license tag string termination trick
Jon Masters wrote: > need a technological mechanism here to enforce the obvious. To me, it > just seems totally obvious (any legal comment?) that early C string > termination is undermining the intent of the MODULE_LICENSE tag. > I completely agree with that. It's like I sign a contract and the other party later makes claims and says: Well, you sure you read the whole contract? 'Coz in the part that was written with special ink, only visible under special light, it clearly states that ... Can't you put this somewhere into the documentation: it's our kernel, play by our rules, and our rules are, the license is what is visible in 'printf(license)'? tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] filesystem: Disk Errors at boot-time caused by probe of partitions
On Thu, 2007-02-01 at 14:26 -0800, Andrew Morton wrote:
> The recursion is a concern. Is there any way in which a cunningly-crafted
> device can cause sufficiently deep recursion to crash the kernel?
I did wonder about this, but couldn't think of an *elegant* way of
mirroring the extended_partition logic that would cope with any changes
to its implementation in msdos.c in the future, without someone paying
attention and knowing to manually change it in check_sane_values().
I could manually reflect the current policy, which appears to allow MBR
+extended+extended as the current limit?
> Also, from reading the replies I think we'd like to see some more
> explanation of why this is necessary: are you really really sure that those
> disks were incorrectly handling illegal sector numbers?
Yes. Without this patch during boot the kernel log is full of Disk
Errors - thousands of them - which even when I increased the kernel log
size to 1MB sometimes couldn't cope.
I've thought of recording the noise it makes because for anyone familiar with
drives
it makes you want to reach for the power-off switch immediately - its not
healthy, and
as I reported, does lead to physical issues too.
The errors report the physical and logical sectors, which made it easy
to understand early-on what was happening (seek requests originating in
file-system logic),
but it took much longer to identify the *why*.
short extract ---
DC202XX: Primary channel reset.
ide2: reset: success
hde: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest
Error }
hde: task_in_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
end_request: I/O error, dev hde, sector 238276076
printk: 8 messages suppressed.
Buffer I/O error on device hde2, logical block 47279294
hde: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest
Error }
hde: task_in_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hde: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest
Error }
---
The log-buffer overflow in itself is a big block on identifying the
actions that occur before the errors start, because if you don't have
the time and skills to build a new kernel with increased log size and
debugging there is no clue as to the reason.
I had to stick with it because the array contains partitions and data
from a Windows 2003 Server installation that had to be maintained -
couldn't just 'reformat'.
You can see the original bug report in the Ubuntu bug-tracker where I've
posted the findings and experience during the ongoing hunt for the cause
of the errors, where it shows *small* extracts of the errors being seen.
https://launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/77734
See particularly the additional comment I made dated
2007-01-25 18:35:54 UTC where I narrowed down the errors to only
affecting 8 unique sector addresses, repeated thousands of times.
Comparing those 8 unique sector addresses with the known partition
layout and file-systems on the disks helped me determine roughly what
was going on, which is when I switched my attention to the detection of
the partitions themselves.
> Knowing the IBM and Maxtor model numbers might be useful.
The Model number is Maxtor 6Y060L0.
I'm afraid I don't have the IBM model numbers because that system was
only used briefly to boot from a Flash-RAM card because it had a
matching FastTrak controller and RAID 1+0 array already defined.
> I assume you were using a driver in drivers/ide/? Perhaps this is really
> an IDE-layer bug.
It is the 'generic' code within drivers/ide/ that issues requests to the drives.
In the early stages I did consider hacking the ide-disk code to just
stop it attempting to request 'illegal' sectors, but that would have
been ugly, could have caused unforeseen consequences, and didn't deal
with the true issue, which is simply a lack of bounds-checking.
If this was a memory buffer bounds-checking would be a priority, but the
partition structure code neglected to do any, which is the root cause of
the issue.
When I started hunting this bug I dropped calls to dump_stack() in the
functions generating the errors, but they turned out to be the interrupt
task handlers (as you'll see in the Ubuntu bug report) which only led to
the work_queue.
The thrashing of the heads comes on some time after (in kernel terms)
the partition is scanned so I was focusing on the file-system, etc., and
thinking the issue was in one of the init scripts.
It took me a long while to track it back to the results of the partition
scan, but as soon as I implemented this patch the problem stopped and
the drives initialise properly.
TJ.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.16.16 Lost CD-ROM Drive
Brian D. McGrew wrote: What am I missing to get the 2.6.16.16 kernel to see a SATA CD-ROM drive in normal, non-legacy move? Try booting 2.6.16 with the following options: libata.atapi_enabled=1 ide0=noprobe ide1=noprobe - Still no go. /dev/sda* is created for the hard drive but no CD-ROM and the same ATAPI error in dmesg. If libata is built as a module, putting libata.atapi_enabled=1 on the kernel command line won't work. In that case, try putting options libata atapi_enabled=1 in /etc/modprobe.conf. Of course if libata is being loaded from the initrd that may not work, in which case the easiest solution is likely to just build it into the kernel so that the kernel command line method will work. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Ban module license tag string termination trick
Trent Waddington wrote: On 2/2/07, Jon Masters <[EMAIL PROTECTED]> wrote: Ok. I totally dig the *idea* here - I mean, this issue has been ongoing for a long time now. But I'd like to see a few comments as to whether we need a technological mechanism here to enforce the obvious. To me, it just seems totally obvious (any legal comment?) that early C string termination is undermining the intent of the MODULE_LICENSE tag. I'm not a lawyer, but I can tell you exactly what a lawyer would say: "well, ya know, it's hard to say when it comes to these issues" that's the answer to *any* copyright question. :) to me it even screams "bypassing or a digital copyright enforcement system". that sounds really close to "D.M.C.A. violation" :) thank goodness I'm not a laywer... Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: smp and irq conflict
Lapo TIN wrote: Dear all, I have a problem with IRQs. My pc has a CPU PentiumD945 (dual core) and a 2.6.19smp kernel. I have two video acquisition board (four bt8t8 each) in the only two pci slots of my motherboard. Thus I have a total of 8 bttv modules that are working together, and the /proc/interrupts is as follows: # cat /proc/interrupts CPU0 CPU1 0: 13575 0 IO-APIC-edge timer 1: 2 0 IO-APIC-edge i8042 4: 11 0 IO-APIC-edge serial 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12: 4 0 IO-APIC-edge i8042 14: 22286 0 IO-APIC-edge ide0 17: 7073 2097 IO-APIC-fasteoi uhci_hcd:usb5, eth0 18: 2525 0 IO-APIC-fasteoi bttv0, bttv7 19: 2829 0 IO-APIC-fasteoi bttv1, bttv4 20: 2526 0 IO-APIC-fasteoi bttv2, bttv5 21: 2226 0 IO-APIC-fasteoi bttv3, bttv6 22: 2 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb4 23: 86 0 IO-APIC-fasteoi uhci_hcd:usb2 24: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 NMI: 0 0 LOC: 13484 13502 ERR: 0 MIS: 0 You can see that IRQ18 is shared between bttv0 and bttv7, IRQ19 between bttv1 and bttv4 and so on. Sometimes it crashes. It seems a matter of conflict in IRQ. With only one video board everything is ok, but with two, they shared irq and something goes wrong... How can I tell to the kernel to not to share the IRQ for these boards ? I think (I don't know if I'm right) that this could be the problem. Usually the IRQ routing is hard-wired on the motherboard, so there's no way to avoid the devices sharing IRQs. Unless the driver is badly buggy this should not cause problems anyway. What kind of video bit rate are you capturing? 8 video capture chips is a pretty heavy load on the PCI bus, maybe something just gets overwhelmed? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386 and x86-64 bitops function prototypes differ
Andrew, On Thu, Feb 01, 2007 at 02:55:25PM -0800, Andrew Morton wrote: > On Thu, 1 Feb 2007 01:15:55 -0800 > Stephane Eranian <[EMAIL PROTECTED]> wrote: > > > Hello, > > > > On Fri, Jan 26, 2007 at 09:49:54AM -0800, H. Peter Anvin wrote: > > > > > > > >I ran into compiler warnings with the perfmon code when I tried > > > >using test() and __set_bit() on i386. > > > > > > > >For some reason, the i386 bitops functions use unsigned long * for > > > >the address whereas x86-64/ia64 use void *. > > > > > > > >I do not quite understand why such difference? > > > >Is this just for historical reasons? > > > > > > > >Thanks. > > > > > > > > > > Arguably void * is the right thing for a littleendian architecture. For > > > bigendian architectures it unfortunately matters what the chunk size is, > > > regardless of if the chunks are numbered in bigendian (reverse) or > > > littleendian (forward) order. > > > > > > > I agree with you, but i386 is definitively little endian, so here is a patch > > against 2.6.20-rc6-mm3 to make x86-64 and i386 have the same prototypes for > > bit manipulation routines. > > > > changelog: > > - change all bit manipulation inline routine to use void * as their > > address argument instead of unsigned long *. Match x86-64 > > > > signed-off-by: stephane eranian <[EMAIL PROTECTED]> > > > > --- linux-2.6.20-rc6-mm3.orig/include/asm-i386/bitops.h 2007-01-31 > > 09:24:21.0 -0800 > > +++ linux-2.6.20-rc6-mm3.base/include/asm-i386/bitops.h 2007-01-31 > > 09:31:46.0 -0800 > > @@ -33,7 +33,7 @@ > > * Note that @nr may be almost arbitrarily large; this function is not > > * restricted to acting on a single-word quantity. > > */ > > -static inline void set_bit(int nr, volatile unsigned long * addr) > > +static inline void set_bit(int nr, volatile void * addr) > > These bitops are only valid on long*'s. Or a least, they require a > long-aligned address, and using long* is how we communicate and enforce > that. > Yes, I realize this now. > Numerous architectures implement these functions using ulong*. If we make > this change, we risk someone doing set_bit() on, say, a char *. That > change would compile and run happily on x86 and would then fail on, say, > arm or h8/300. > > So I'd say that x86_64 is wrong, and should be changed to take ulong*. We need to fix x86-64 and also ia64 it seems. I'll see if I can do that. Thanks. -- -Stephane - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
