Re: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
Pavel Machek wrote: On Tue 12-12-06 23:45:27, Olivier Galibert wrote: On Tue, Dec 12, 2006 at 11:44:18AM -0700, Andrew Robinson wrote: When I said hibernate, I did mention it was to disk, not to ram. Suspend to disk is not trustable on Linux, and does not look like it will be any time soon. Suspend to ram has a better chance of becoming Stop spreading fud. Take powersave + suspend from suse10.2, and see if you can break it. sata_nv seems to have problem, that's it. and it triggered problem in reiserfs. Use ext3 if you care about your data, and yes your drivers need to support suspend/resume. Pavel My Compaq laptop, a Presario 2200, has video lockups using suspend to disk and a dead system everytime I use it. I don't think its fud. I also conceed its not Linux's fault most of the time. These vendors put Windows specific hardware support into these systems. My laptop has a dozen strange keys that work only on Windows and if you push one of them in Linux, the system looses state with the keyboard and croaks ( have to reboot to recover). If I close the lid of my latop or do any other suspend to disk state, the video display is croaked. 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: Mach-O binary format support and Darwin syscall personality [Was: uts banner changes]
Hi! > So I guess all I have to do is: > (A) Write a bunch of new syscall handlers taking > arguments of the same types as the Darwin syscall > handlers, > (B) Figure out how to switch tables depending on the > "syscall personality" of "current" > (C) Figure out how to set the "syscall personality" > of "current" from my Mach-O binary format module. > > (A) seems fairly straightforward, if unusually tedious > and error- prone, but I'm totally in the dark for (B) > and (C). Any help would be much appreciated. try strace osx_binary. If syscall interface is similar enough, perhaps it is possible to do it with ptrace() :-). Pavel -- Thanks for all the (sleeping) penguins. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
On Tue 12-12-06 23:45:27, Olivier Galibert wrote: > On Tue, Dec 12, 2006 at 11:44:18AM -0700, Andrew Robinson wrote: > > When I said hibernate, I did mention it was to disk, not to ram. > > Suspend to disk is not trustable on Linux, and does not look like it > will be any time soon. Suspend to ram has a better chance of becoming Stop spreading fud. Take powersave + suspend from suse10.2, and see if you can break it. sata_nv seems to have problem, that's it. and it triggered problem in reiserfs. Use ext3 if you care about your data, and yes your drivers need to support suspend/resume. Pavel -- Thanks for all the (sleeping) penguins. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] fix to usbfs_snoop logging of user defined control urbs
Hi Greg KH, According to a Linux Journal article, you were the original author of the usbfs_snoop patch, so I'm sending this patch to you. When sending CONTROL URB's using the usual CONTROL ioctl, logging works fine, but when sending them via SUBMITURB, like VMWare does, the control fields are not logged. This patch fixes that. I didn't see any major changes to devio.c recently, so this patch should apply cleanly to even the latest kernel. I can resubmit if it doesn't. Take care, - Chris diff -ru linux-2.6.18.1/drivers/usb/core/devio.c linux-2.6.18.1-cdf/drivers/usb/core/devio.c --- linux-2.6.18.1/drivers/usb/core/devio.c 2006-10-13 23:34:03.0 -0400 +++ linux-2.6.18.1-cdf/drivers/usb/core/devio.c 2006-12-15 17:00:48.0 -0500 @@ -950,7 +950,11 @@ kfree(dr); return -EFAULT; } - snoop(>dev->dev, "control urb\n"); + snoop(>dev->dev, "control urb: bRequest=%02x " + "bRrequestType=%02x wValue=%04x " + "wIndex=%04x wLength=%04x\n", + dr->bRequest, dr->bRequestType, dr->wValue, + dr->wIndex, dr->wLength); break; case USBDEVFS_URB_TYPE_BULK: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Doubled stack dumps during locking testsuite
Hi Ingo,
I built a parisc kernel with CONFIG_DEBUG_LOCKING_API_SELFTESTS enabled
recently, and got some interesting results:
double unlock: ok | ok |failed|WARNING at
/home/willy/merge-2.6/kernel/mutex-debug.c:83 debug_mutex_unlock()
Backtrace:
[<40144b38>] printk+0x40/0x50
[<4028d5f4>] init_class_Z+0xa4/0xc0
[<40144b38>] printk+0x40/0x50
[<40171fbc>] register_cpu_notifier+0x5c/0x78
[<40340212>] lpfc_sli_issue_mbox_wait+0x138/0x1c8
[<40204d01>] sg_grt_trans+0x150/0x168
[<40285700>] kobject_uevent+0x8/0x20
[<40304d65>] scsi_error_handler+0x9f4/0xa48
[<40207450>] dump_write+0x40/0x58
[<4044c67c>] packet_getsockopt+0x144/0x150
[<4044b05c>] packet_ioctl+0x1a4/0x1b0
[<404466d4>] unix_ioctl+0x154/0x168
[<4042d5dc>] ipv4_sysctl_forward_strategy+0x12c/0x138
[<4042d558>] ipv4_sysctl_forward_strategy+0xa8/0x138
[<4042c1d4>] ip_mc_msfget+0x16c/0x1d0
[<404230a8>] ipv4_doint_and_flush_strategy+0x110/0x138
WARNING at /home/willy/merge-2.6/kernel/mutex-debug.c:86 debug_mutex_unlock()
Backtrace:
[<40144b38>] printk+0x40/0x50
[<4028d5f4>] init_class_Z+0xa4/0xc0
[<40144b38>] printk+0x40/0x50
[<40171fbc>] register_cpu_notifier+0x5c/0x78
[<40340212>] lpfc_sli_issue_mbox_wait+0x138/0x1c8
[<40204d01>] sg_grt_trans+0x150/0x168
[<40285700>] kobject_uevent+0x8/0x20
[<40304d65>] scsi_error_handler+0x9f4/0xa48
[<40207450>] dump_write+0x40/0x58
[<4044c67c>] packet_getsockopt+0x144/0x150
[<4044b05c>] packet_ioctl+0x1a4/0x1b0
[<404466d4>] unix_ioctl+0x154/0x168
[<4042d5dc>] ipv4_sysctl_forward_strategy+0x12c/0x138
[<4042d558>] ipv4_sysctl_forward_strategy+0xa8/0x138
[<4042c1d4>] ip_mc_msfget+0x16c/0x1d0
[<404230a8>] ipv4_doint_and_flush_strategy+0x110/0x138
failed|failed|failed|
Now, lines 83 to 86 of mutex-debug.c are:
DEBUG_LOCKS_WARN_ON(lock->owner != current_thread_info());
DEBUG_LOCKS_WARN_ON(lock->magic != lock);
DEBUG_LOCKS_WARN_ON(!lock->wait_list.prev && !lock->wait_list.next);
DEBUG_LOCKS_WARN_ON(lock->owner != current_thread_info());
Do we really need to test the same thing twice and produce the same
stack dump?
Moreover, do we want to get stack dumps while running the locking
testsuite in the first place? From various comments, it looks
like it's supposed to be turned off, but it looks like the sense of
debug_locks_silent is inverted in the definition of DEBUG_LOCKS_WARN_ON:
if (unlikely(c)) { \
if (debug_locks_silent || debug_locks_off())\
WARN_ON(1); \
Surely that should be:
if (!debug_locks_silent && debug_locks_off())
WARN_ON(1);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Fri, Dec 15, 2006 at 06:55:17PM -0800, Linus Torvalds wrote: > > > On Sat, 16 Dec 2006, karderio wrote: > > > > As it stands, I believe the licence of the Linux kernel does impose > > certain restrictions and come with certain obligations > > Absolutely. And they boil down to something very simple: > > "Derived works have to be under the same license" > > where the rest is just really fluff. > > But the point is, "derived work" is not what _you_ or _I_ define. It's > what copyright law defines. > > And trying to push that definition too far is a total disaster. If you > push the definition of derived work to "anything that touches our work", > you're going to end up in a very dark and unhappy place. One where the > RIAA is your best buddy. > > And the proposed "we make some technical measure whereby we draw our _own_ > lines" is exactly that total disaster. > > We don't draw our own lines. We accept that the lines are drawn for us by > copyright law, and we actually _hope_ that the lines aren't too sharp and > too clearcut. Because sharp edges on copyright is the worst possible > situation we could ever be in. > > The reason fair use is so important is exactly that it blunts/dulls the > sharp knife that overly strong copyright protection could be. All this is about "fair use", and "fair use" comes from compatibility between the author's intent and the user's intent. For this exact reason, I have added a "LICENSE" file [1] in my software (haproxy) stating that I explicitly permit linking with binary code if the user has no other choice (eg: protocols specs obtained under NDA), provided that "derived work" does not steal any GPL code (include files are under LGPL). On the other hand, all "common protocols" are developped under GPL so that normal users are the winners, and everyone is strongly encouraged to use the GPL for their new code to benefit from everyone else's eyes on the code. This clarifies my intent and let developers decide whether *they* are doing legal things or not. Don't you think it would be a good idea to add such a precision in the sources ? It could put an end to all those repeated lessons you have to teach to a lot of people about fair use. Or perhaps you like to put your teacher hat once a month ? :-) Regards, Willy [1] http://haproxy.1wt.eu/download/1.3/src/LICENSE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri, Dec 15, 2006 at 04:48:44PM -0500 > The "Re: Linux 2.6.20-rc1" sub-thread that had Jens and Alistair John > Strachan replying seemed to implicate some core block layer badness. > The original problem (not mounting my raid6 partition) is observable in 2.6.20-rc1-mm1, but not in 2.6.20-rc1; ie. 2.6.20-rc1 is good for me. Linux version 2.6.20-rc1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #3 SMP Fri Dec 15 21:19:54 CET 2006 md: Autodetecting RAID arrays. md: autorun ... md: considering sdh1 ... md: adding sdh1 ... md: adding sdg1 ... md: adding sdf1 ... md: adding sde1 ... md: adding sdd1 ... md: adding sdc1 ... md: adding sdb1 ... md: adding sda1 ... md: hdc9 has different UUID to sdh1 md: hdc8 has different UUID to sdh1 md: hdc7 has different UUID to sdh1 md: hdc6 has different UUID to sdh1 md: hdc5 has different UUID to sdh1 md: hda9 has different UUID to sdh1 md: hda8 has different UUID to sdh1 md: hda7 has different UUID to sdh1 md: hda6 has different UUID to sdh1 md: hda5 has different UUID to sdh1 md: created md0 md: bind md: bind md: bind md: bind md: bind md: bind md: bind md: bind md: running: raid5: device sdh1 operational as raid disk 1 raid5: device sdg1 operational as raid disk 0 raid5: device sdf1 operational as raid disk 5 raid5: device sde1 operational as raid disk 6 raid5: device sdd1 operational as raid disk 7 raid5: device sdc1 operational as raid disk 3 raid5: device sdb1 operational as raid disk 2 raid5: device sda1 operational as raid disk 4 raid5: allocated 8462kB for md0 raid5: raid level 6 set md0 active with 8 out of 8 devices, algorithm 2 RAID5 conf printout: --- rd:8 wd:8 disk 0, o:1, dev:sdg1 disk 1, o:1, dev:sdh1 disk 2, o:1, dev:sdb1 disk 3, o:1, dev:sdc1 disk 4, o:1, dev:sda1 disk 5, o:1, dev:sdf1 disk 6, o:1, dev:sde1 disk 7, o:1, dev:sdd1 md0: bitmap initialized from disk: read 15/15 pages, set 1 bits, status: 0 created bitmap (233 pages) for device md0 md: considering hdc9 ... md: adding hdc9 ... md: hdc8 has different UUID to hdc9 md: hdc7 has different UUID to hdc9 md: hdc6 has different UUID to hdc9 md: hdc5 has different UUID to hdc9 md: adding hda9 ... md: hda8 has different UUID to hdc9 md: hda7 has different UUID to hdc9 md: hda6 has different UUID to hdc9 md: hda5 has different UUID to hdc9 md: created md4 md: bind md: bind md: running: raid1: raid set md4 active with 2 out of 2 mirrors md4: bitmap initialized from disk: read 10/10 pages, set 45 bits, status: 0 EXT3 FS on md0, internal journal EXT3-fs: mounted filesystem with ordered data mode. Jurriaan -- And I thought that the Borg were bad... Debian (Unstable) GNU/Linux 2.6.20-rc1 2x4023 bogomips load 5.55 the Jack Vance Integral Edition: http://www.integralarchive.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: 2.6.18.5 usb/sysfs bug.
In-Reply-To: <[EMAIL PROTECTED]>
On Fri, 15 Dec 2006 16:37:15 -0500, Dave Jones wrote:
> > Can you enable CONFIG_USB_DEBUG and send the log info that happens right
> > before this oops?
>
> Gah, and here it is, actually attached this time.
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 000b
> EIP is at sysfs_hash_and_remove+0x18/0xfd
That's strange. Remove_files called sysfs_hash_and_remove()
with dir==0xfff3 (-13 decimal.)
static void remove_files(struct dentry * dir,
const struct attribute_group * grp)
{
struct attribute *const* attr;
for (attr = grp->attrs; *attr; attr++)
sysfs_hash_and_remove(dir,(*attr)->name); <
}
> Process pcscd (pid: 2678, ti=f6d28000 task=f7dbe1f0 task.ti=f6d28000)
> Stack: c0634109 fff3 f7063414 c069cf0c fff3 fff3 f7063414
> c04a7f69
>c069cf00 f70632b0 c04a7fb8 f7063208 f70473a0 f7063208 c055572f
> f70632b0
>c05513ff f7063208 f7000640 0001 f703f788 c055142e f6d28ed4
> c058800c
> Call Trace:
> [] remove_files+0x15/0x1e
> [] sysfs_remove_group+0x46/0x5c
> [] device_pm_remove+0x2b/0x62
> [] device_del+0x11a/0x141
> [] device_unregister+0x8/0x10
> [] usb_remove_ep_files+0x5b/0x7b
> [] usb_remove_sysfs_intf_files+0x1d/0x54
> [] usb_set_interface+0x135/0x1bf
> [] usb_unbind_interface+0x4a/0x6a
> [] __device_release_driver+0x60/0x78
> [] device_release_driver+0x2b/0x3a
> [] usb_driver_release_interface+0x3b/0x63
> [] releaseintf+0x4b/0x5b
> [] usbdev_release+0x67/0x9e
> [] __fput+0xba/0x188
> [] filp_close+0x52/0x59
> [] syscall_call+0x7/0xb
What is pcscd?
Earlier in bootup you got this:
hub 1-0:1.0: state 7 ports 2 chg evt 0004
uhci_hcd :00:1d.0: port 2 portsc 008a,00
hub 1-0:1.0: port 2, status 0100, change 0003, 12 Mb/s
usb 1-2: USB disconnect, address 2
usb 1-2: usb_disable_device nuking all URBs
uhci_hcd :00:1d.0: shutdown urb f7ed7540 pipe 40408280 ep1in-intr
usb 1-2: unregistering interface 1-2:1.0
usbdev1.2_ep81: ep_device_release called for usbdev1.2_ep81
usb 1-2:1.0: uevent
usb 1-2: unregistering device
usbdev1.2_ep00: ep_device_release called for usbdev1.2_ep00
usb_remove_ep_files() is in the call trace, so this may be related?
--
MBTI: IXTP
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Change in multiple NFS mount behavior in 2.6.19?
On Fri, 15 Dec 2006 23:46:28 -0500 Mike Accetta wrote: > After upgrading an NFS client from 2.6.18 to 2.6.19 (and also with > 2.6.19.1) we see a change in behavior of multiple NFS mounts against the > same server (running 2.4.20 in this case). With 2.6.18 we could mount > different pieces of the same remote file system with distinct read-only > and read-write attributes at corresponding places on the client. With > 2.6.19 if the first mount is read-only, subsequent mounts seem to > inherit the read-only status even though not explicitly mounted read-only. > > If I did the "git bisect" properly, the behavior changed with commit > 54ceac4515986030c2502960be620198dd8fe25b and the description of this > commit seems like it could indeed have caused this behavior, but perhaps > not intentionally. I believe the client is making NFS V2 calls. Also, I > am still able to issue a "mount -o remount,rw" on the client to regain > read-write capability. Was this a regression or is this now the > expected behavior for multiple NFS client mounts in 2.6.19? > -- That would correspond to this bugzilla item, which explains that multiple mount semantics for one filesystem are all shared. http://bugzilla.kernel.org/show_bug.cgi?id=7655 --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Change in multiple NFS mount behavior in 2.6.19?
After upgrading an NFS client from 2.6.18 to 2.6.19 (and also with 2.6.19.1) we see a change in behavior of multiple NFS mounts against the same server (running 2.4.20 in this case). With 2.6.18 we could mount different pieces of the same remote file system with distinct read-only and read-write attributes at corresponding places on the client. With 2.6.19 if the first mount is read-only, subsequent mounts seem to inherit the read-only status even though not explicitly mounted read-only. If I did the "git bisect" properly, the behavior changed with commit 54ceac4515986030c2502960be620198dd8fe25b and the description of this commit seems like it could indeed have caused this behavior, but perhaps not intentionally. I believe the client is making NFS V2 calls. Also, I am still able to issue a "mount -o remount,rw" on the client to regain read-write capability. Was this a regression or is this now the expected behavior for multiple NFS client mounts in 2.6.19? -- Mike Accetta ECI Telecom Ltd. Data Networking Division (previously Laurel Networks) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
On 12/16/06, jdow <[EMAIL PROTECTED]> wrote: From: "Alexey Dobriyan" <[EMAIL PROTECTED]> > On Fri, Dec 15, 2006 at 09:20:58PM +, James Porter wrote: >> I think some kernel developers take to much responsibility, is there a >> bug in a >> binary driver? Send it upstream and explain to the user that it's a >> closed >> source driver and is up to said company to fix it. >> >> For what it's worth, I don't see any problem with binary drivers from >> hardware >> manufacturers. > > Binary drivers from hardware manufacturers are crap. Learn it by heart. So are the Linux drivers in some cases. My ATI Radeon Mobility video in my laptop is an example. Open drivers aren't magic.. if the vendor doesn't give us the information how specific chips are screwed, there isn't anything we can do about it, ATI don't support the open drivers for anything but RN50s from Dell and their support is quite brutal even on those (every patch is a dirty hack...), the thing is with the open drivers we can say hey ATI that is a dirty hack, with the closed ones they just stick it in and ship it.. Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] please pull infiniband.git
Linus, please pull from
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
This tree is also available from kernel.org mirrors at:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
A couple of fixes for semi-nasty bugs on 32-bit architectures, plus
one small mthca driver update:
Leonid Arsh (1):
IB/mthca: Add HCA profile module parameters
Roland Dreier (3):
IB: Fix ib_dma_alloc_coherent() wrapper
IB/srp: Fix FMR mapping for 32-bit kernels and addresses above 4G
IB/mthca: Use DEFINE_MUTEX() instead of mutex_init()
drivers/infiniband/hw/mthca/mthca_main.c | 113 +
drivers/infiniband/ulp/srp/ib_srp.c |2 +-
drivers/infiniband/ulp/srp/ib_srp.h |2 +-
include/rdma/ib_verbs.h |9 ++-
4 files changed, 107 insertions(+), 19 deletions(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_main.c
b/drivers/infiniband/hw/mthca/mthca_main.c
index 0491ec7..44bc6cc 100644
--- a/drivers/infiniband/hw/mthca/mthca_main.c
+++ b/drivers/infiniband/hw/mthca/mthca_main.c
@@ -80,24 +80,61 @@ static int tune_pci = 0;
module_param(tune_pci, int, 0444);
MODULE_PARM_DESC(tune_pci, "increase PCI burst from the default set by BIOS if
nonzero");
-struct mutex mthca_device_mutex;
+DEFINE_MUTEX(mthca_device_mutex);
+
+#define MTHCA_DEFAULT_NUM_QP(1 << 16)
+#define MTHCA_DEFAULT_RDB_PER_QP(1 << 2)
+#define MTHCA_DEFAULT_NUM_CQ(1 << 16)
+#define MTHCA_DEFAULT_NUM_MCG (1 << 13)
+#define MTHCA_DEFAULT_NUM_MPT (1 << 17)
+#define MTHCA_DEFAULT_NUM_MTT (1 << 20)
+#define MTHCA_DEFAULT_NUM_UDAV (1 << 15)
+#define MTHCA_DEFAULT_NUM_RESERVED_MTTS (1 << 18)
+#define MTHCA_DEFAULT_NUM_UARC_SIZE (1 << 18)
+
+static struct mthca_profile hca_profile = {
+ .num_qp = MTHCA_DEFAULT_NUM_QP,
+ .rdb_per_qp = MTHCA_DEFAULT_RDB_PER_QP,
+ .num_cq = MTHCA_DEFAULT_NUM_CQ,
+ .num_mcg= MTHCA_DEFAULT_NUM_MCG,
+ .num_mpt= MTHCA_DEFAULT_NUM_MPT,
+ .num_mtt= MTHCA_DEFAULT_NUM_MTT,
+ .num_udav = MTHCA_DEFAULT_NUM_UDAV, /* Tavor only */
+ .fmr_reserved_mtts = MTHCA_DEFAULT_NUM_RESERVED_MTTS, /* Tavor only */
+ .uarc_size = MTHCA_DEFAULT_NUM_UARC_SIZE, /* Arbel only */
+};
+
+module_param_named(num_qp, hca_profile.num_qp, int, 0444);
+MODULE_PARM_DESC(num_qp, "maximum number of QPs per HCA");
+
+module_param_named(rdb_per_qp, hca_profile.rdb_per_qp, int, 0444);
+MODULE_PARM_DESC(rdb_per_qp, "number of RDB buffers per QP");
+
+module_param_named(num_cq, hca_profile.num_cq, int, 0444);
+MODULE_PARM_DESC(num_cq, "maximum number of CQs per HCA");
+
+module_param_named(num_mcg, hca_profile.num_mcg, int, 0444);
+MODULE_PARM_DESC(num_mcg, "maximum number of multicast groups per HCA");
+
+module_param_named(num_mpt, hca_profile.num_mpt, int, 0444);
+MODULE_PARM_DESC(num_mpt,
+ "maximum number of memory protection table entries per HCA");
+
+module_param_named(num_mtt, hca_profile.num_mtt, int, 0444);
+MODULE_PARM_DESC(num_mtt,
+"maximum number of memory translation table segments per HCA");
+
+module_param_named(num_udav, hca_profile.num_udav, int, 0444);
+MODULE_PARM_DESC(num_udav, "maximum number of UD address vectors per HCA");
+
+module_param_named(fmr_reserved_mtts, hca_profile.fmr_reserved_mtts, int,
0444);
+MODULE_PARM_DESC(fmr_reserved_mtts,
+"number of memory translation table segments reserved for
FMR");
static const char mthca_version[] __devinitdata =
DRV_NAME ": Mellanox InfiniBand HCA driver v"
DRV_VERSION " (" DRV_RELDATE ")\n";
-static struct mthca_profile default_profile = {
- .num_qp= 1 << 16,
- .rdb_per_qp= 4,
- .num_cq= 1 << 16,
- .num_mcg = 1 << 13,
- .num_mpt = 1 << 17,
- .num_mtt = 1 << 20,
- .num_udav = 1 << 15, /* Tavor only */
- .fmr_reserved_mtts = 1 << 18, /* Tavor only */
- .uarc_size = 1 << 18, /* Arbel only */
-};
-
static int mthca_tune_pci(struct mthca_dev *mdev)
{
int cap;
@@ -303,7 +340,7 @@ static int mthca_init_tavor(struct mthca_dev *mdev)
goto err_disable;
}
- profile = default_profile;
+ profile = hca_profile;
profile.num_uar = dev_lim.uar_size / PAGE_SIZE;
profile.uarc_size = 0;
if (mdev->mthca_flags & MTHCA_FLAG_SRQ)
@@ -621,7 +658,7 @@ static int mthca_init_arbel(struct mthca_dev *mdev)
goto err_stop_fw;
}
- profile = default_profile;
+ profile = hca_profile;
profile.num_uar = dev_lim.uar_size / PAGE_SIZE;
profile.num_udav = 0;
if (mdev->mthca_flags & MTHCA_FLAG_SRQ)
@@ -1278,11 +1315,55 @@ static struct
Inspiron 6000 power problem saga - other people's experiences?
Regarding: http://bugzilla.kernel.org/show_bug.cgi?id=7393 No closer to a solution yet. I'm worried about this problem because the laptop is getting hotter than it's designed for and it is likely shortening its life. To aid in tracking it down, I could use reports of this problem happening, or not happening, with other inspiron 6000. If anyone out there has this laptop (or, hell, any in the 6000 series), could you please send: - actual laptop model - BIOS version - kernel version, (or distro/package version if you're using a packaged kernel) - output of "lspci -vv" - output of "cat /proc/acpi/battery/BAT0/state", when it's been idle for about 10 seconds (ie no CD in drive, using less than 1% CPU according to top(1) or similar, but display is on, hard disk not important), and with charger disconnected Any help is greatly appreciated. Mick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
From: "Alexey Dobriyan" <[EMAIL PROTECTED]>
On Fri, Dec 15, 2006 at 09:20:58PM +, James Porter wrote:
I think some kernel developers take to much responsibility, is there a
bug in a
binary driver? Send it upstream and explain to the user that it's a
closed
source driver and is up to said company to fix it.
For what it's worth, I don't see any problem with binary drivers from
hardware
manufacturers.
Binary drivers from hardware manufacturers are crap. Learn it by heart.
So are the Linux drivers in some cases. My ATI Radeon Mobility video
in my laptop is an example.
If you are going to mount a sanctimonious high horse it is a wise idea
to mount a horse instead of a donkey.
{^_^}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
From: "Alan" <[EMAIL PROTECTED]>
blather and idiotic hogwash. "Information" doesn't want to be free, nor
is
it somethign you should fight for or necessarily even encourage.
As a pedant that is the one item I have to pick you up on Linus.
Information wants to be free, the natural efficient economic state of
information is generally free in both senses.
Alan, you might as well declare a rock wants to be free. Information
does not have a brain that could in any way want to be free. It is all
people who want something for nothing who want information to be free.
{^_^}JOanne
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.5 usb/sysfs bug.
On Fri, Dec 15, 2006 at 05:47:50PM -0800, Pete Zaitcev wrote:
> On Fri, 15 Dec 2006 16:37:15 -0500, Dave Jones <[EMAIL PROTECTED]> wrote:
>
> > Linux version 2.6.18-1.2864.fc6 ([EMAIL PROTECTED]) (gcc version 4.1.1
> > 20061011 (Red Hat 4.1.1-30)) #1 SMP Fri Dec 15 13:14:58 EST 2006
> > Kernel command line: ro root=/dev/VolGroup00/LogVol00 profile=1 vga=791
>
> > audit(1166218060.464:4): avc: denied { search } for pid=2678
> > comm="pcscd" name="usbdev2.4_ep03" dev=sysfs ino=1384
> > scontext=system_u:system_r:pcscd_t:s0
> > tcontext=system_u:object_r:sysfs_t:s0 tclass=dir
> > BUG: unable to handle kernel NULL pointer dereference at virtual address
> > 000b
>
> But if you boot with selinux=0, everything works, right? Printk time.
Good spotting, yes it does. And come to think of it, this only
recently started happening after some updates got applied, so it's
likely that policy got stricter somehow. Still shouldn't cause
an oops though obviously.
Dave
--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Sat, 16 Dec 2006, karderio wrote: > > As it stands, I believe the licence of the Linux kernel does impose > certain restrictions and come with certain obligations Absolutely. And they boil down to something very simple: "Derived works have to be under the same license" where the rest is just really fluff. But the point is, "derived work" is not what _you_ or _I_ define. It's what copyright law defines. And trying to push that definition too far is a total disaster. If you push the definition of derived work to "anything that touches our work", you're going to end up in a very dark and unhappy place. One where the RIAA is your best buddy. And the proposed "we make some technical measure whereby we draw our _own_ lines" is exactly that total disaster. We don't draw our own lines. We accept that the lines are drawn for us by copyright law, and we actually _hope_ that the lines aren't too sharp and too clearcut. Because sharp edges on copyright is the worst possible situation we could ever be in. The reason fair use is so important is exactly that it blunts/dulls the sharp knife that overly strong copyright protection could be. It would be a total disaster if you couldn't quote other peoples work, and if you couldn't make parodies on them, and if you couldn't legally use the knowledge you gained for them. In other words, copyright MUST NOT be seen as some "we own this, and you have no rights AT ALL unless you play along with our rules". Copyright absolutely _has_ to allow others to have some rights to play according to their rules even without our permission, and even if we don't always agree with what they do. And that is why it would be WRONG to think that we have the absolute right to say "that is illegal". It's simply not our place to make that judgement. When you start thinking that you have absolute control over the content or programs you produce, and that the rest of the worlds opinions doesn't matter, you're just _wrong_. And no, "BECAUSE I'M GOOD" is _not_ an excuse. It's never an excuse to do something like that just because you believe you are "in the right". It doesn't matter _how_ much you believe in freedom, or anything else - everybody _always_ thinks that they are in the right. The RIAA I'm sure is in a moral lather because they are protecting their own stronghold of morality against the infidels and barbarians at the gate. So don't go talking about how we should twist peoples arms and force them to be open source of free software. Instead, BE HAPPY that people can take advantage of "loopholes" in copyright protections and can legally do things that you as the copyright owner might not like. Because those "loopholes" are in the end what protects YOU. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Merge Blackfin-uClinux tree with latest Linus GIT tree including "LOG2.H" patch failed
Dear David and Forks: I am a developer of Blackfin uClinux (blackfin.uclinux.org). After git clone the latest Linus GIT tree and quilt the blackfin-uclinux patch list, I met some problems related with your log2.h patches when I try to compile the kernel. The compile log is listed as below: == $ make scripts/kconfig/conf -s arch/blackfin/Kconfig CHK include/linux/version.h CHK include/linux/utsrelease.h CC arch/blackfin/kernel/asm-offsets.s In file included from include/asm-generic/page.h:7, from include/asm/page.h:84, from include/asm/user.h:10, from include/asm/bfin-global.h:38, from include/asm/blackfin.h:12, from include/asm/system.h:240, from include/asm/bitops.h:10, from include/linux/bitops.h:9, from include/linux/thread_info.h:20, from include/linux/preempt.h:9, from include/linux/spinlock.h:49, from include/linux/capability.h:45, from include/linux/sched.h:46, from arch/blackfin/kernel/asm-offsets.c:33: include/linux/log2.h: In function '__ilog2_u32': include/linux/log2.h:34: warning: implicit declaration of function 'fls' include/linux/log2.h: In function '__ilog2_u64': include/linux/log2.h:42: warning: implicit declaration of function 'fls64' include/linux/log2.h: In function '__roundup_pow_of_two': include/linux/log2.h:52: warning: implicit declaration of function 'fls_long' In file included from include/asm/bitops.h:210, from include/linux/bitops.h:9, from include/linux/thread_info.h:20, from include/linux/preempt.h:9, from include/linux/spinlock.h:49, from include/linux/capability.h:45, from include/linux/sched.h:46, from arch/blackfin/kernel/asm-offsets.c:33: include/asm-generic/bitops/fls.h: At top level: include/asm-generic/bitops/fls.h:13: error: static declaration of 'fls' follows non-static declaration include/linux/log2.h:34: error: previous implicit declaration of 'fls' was here In file included from include/asm/bitops.h:211, from include/linux/bitops.h:9, from include/linux/thread_info.h:20, from include/linux/preempt.h:9, from include/linux/spinlock.h:49, from include/linux/capability.h:45, from include/linux/sched.h:46, from arch/blackfin/kernel/asm-offsets.c:33: include/asm-generic/bitops/fls64.h:7: error: static declaration of 'fls64' follows non-static declaration include/linux/log2.h:42: error: previous implicit declaration of 'fls64' was here In file included from include/linux/thread_info.h:20, from include/linux/preempt.h:9, from include/linux/spinlock.h:49, from include/linux/capability.h:45, from include/linux/sched.h:46, from arch/blackfin/kernel/asm-offsets.c:33: include/linux/bitops.h:57: error: conflicting types for 'fls_long' include/linux/log2.h:52: error: previous implicit declaration of 'fls_long' was here make[1]: *** [arch/blackfin/kernel/asm-offsets.s] Error 1 make: *** [prepare0] Error 2 = Could you please point me some hint with this? Thanks a lot Regards -Bryan Wu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] include linux/types.h in a bunch of header files for usage with install_headers
On Fri, Dec 15, 2006 at 09:08:50PM -0500, Mike Frysinger wrote: > On 12/12/06, Adrian Bunk <[EMAIL PROTECTED]> wrote: > >On Wed, Dec 06, 2006 at 06:03:50PM -0500, Mike Frysinger wrote: > >> there are a plethora of headers that cannot be included straight due > >> to the usage of __ types (like __u32) without first including > >> linux/types.h ... so the question is, should all of these headers be > >> fixed to properly pull in linux/types.h first or are users expected to > >> "just know" the correct order of headers ? in my mind, pretty much > >> every header is fair game for straight "#include " usage and > >> requiring a list of headers to be pulled in properly is ignoring the > >> problem ... > > > >Yes, they should all be fixed to #include . > > thanks, mondo patch attached :) Looks good, but after your patch the following headers can be moved from unifdef-y to header-y: include/linux/atm.h include/linux/atmarp.h > -mike 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Re :o) On Fri, 2006-12-15 at 16:24 -0800, Linus Torvalds wrote: > > On Sat, 16 Dec 2006, karderio wrote: > > > > If the "free software community" has the clout to twist vendor's arms to > > get them release driver source, then I'm all for it. > > I don't care what you're for, or what your imaginary "free software > community" is for. > > We're "open source" and we're not a religion. In the spirit of mutual understanding, I will not say that I do not care "what you are for", despite your at least very unfriendly reply. You are a person, I care about you, no matter how hard that can be. To be as blatantly frank with you as you are with me, I will say I personally do not care much for open source. I do not see the point of having source code if it's owner imposes the same arbitrary restrictions on my use of it as they can on binary, I want more guarantees than that. > We don't "twist peoples arms". I didn't suggest that you twist peoples arms, I was talking about my imaginary "free software community" ;) > We show people what we think is a better way, and we let them > participate. We don't force it, we don't twist it, and it's ok not to > believe in the GPL or our ideals. That seems great, this is also one of the things I aspire to. I was simply suggesting that perhaps a minor compromise to this principle may be in order, which is of course debatable. > In fact, "our ideals" aren't even one unified thing to begin with. I'm sure they're not, I don't really see how that would work to be honest. > We also don't try to pervert copyright into a "you have to _use_ things > in a certain way". We don't think "fair use" is a bad thing. We encourage > it, and that means that we have to abide by it ourselves. It means, most > particularly, that even people we disagree with have that right of "fair > use". As it stands, I believe the licence of the Linux kernel does impose certain restrictions and come with certain obligations. In what is the suggestion for kernel modules fundamentally different from what you already require of your users ? > That, btw, is what "freedom" and "rights" are all about. It's obly > meaningful when you grant those rights to people you don't agree with. Precisely. A community grants users the right to an open source kernel, why should certain vendors take away from this freedom by providing binary only drivers because they don't agree with that community ? > Also, since you haven't apparently gotten the memo yet, let me point it > out to you: the end results don't justify the means, and never did. So > arm-twisting doesn't become good just because you think the end result > might be worth it. It's still bad. That of course was neither suggested nor implied by what I said, at least not intentionally. > And btw, that "information freedom" thing you talked about is just so much > blather and idiotic hogwash. "Information" doesn't want to be free, nor is > it somethign you should fight for or necessarily even encourage. > > It doesn't hold a candle to _peoples_ freedom, the foremost of which is to > just disagree with you. Once you allow people to talk and do what they > want, that "information freedom" will follow. I have no problem with people disagreeing with me, I would even go to as far as encouraging it in a discussion. If I may however, I think it is no more effort to disagree respectfully, rather than being sarcastic, insulting and using words that could be interpreted as downright aggressive. Of course "freedom of information" could never hold a candle to peoples freedom, and it would be ridiculous to suggest so. There is a big difference between "reasonable measures" and "fighting", I don't see where you got that from. I think that the basic problem for which we are seeking a solution is that binary drivers do not permit people to "do what they want", which by your own definition, shows that they take away from "_peoples_ freedom". > It's not a religion, and it's not about suppressing other people and other > viewpoints. I certainly hope I didn't seem to suggest anything like that, you appear to be ranting at me because of your disagreements with some third party. Is "software as a religion" some sort of "joke religion" like Invisible Pink Unicorn or Flying Spaghetti Monsterism ? Love, Karderio. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] include linux/types.h in a bunch of header files for usage with install_headers
On 12/12/06, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Wed, Dec 06, 2006 at 06:03:50PM -0500, Mike Frysinger wrote: > there are a plethora of headers that cannot be included straight due > to the usage of __ types (like __u32) without first including > linux/types.h ... so the question is, should all of these headers be > fixed to properly pull in linux/types.h first or are users expected to > "just know" the correct order of headers ? in my mind, pretty much > every header is fair game for straight "#include " usage and > requiring a list of headers to be pulled in properly is ignoring the > problem ... Yes, they should all be fixed to #include . thanks, mondo patch attached :) -mike linux-include-types-header.patch Description: Binary data
Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))
On Sat, Dec 16, 2006 at 01:54:39AM +0100, Francois Romieu wrote: > > No, that wouldn't make sense, that's like making a workaround depend on > > arch == i386. > > > > I'm thinking that we should somehow enable this option on the n2100 > > built-in r8169 ports by default only. Since the n2100 also has a mini-PCI > > slot, and it is in theory possible to put an r8169 on a mini-PCI card, > > the workaround probably shouldn't apply to those, so testing for > > CONFIG_MACH_N2100 also isn't the right thing to do. > > Ok, I thought it was a useability thing. It is. > Let aside a few configurations, the sensible default value for this > option is not clear. I have no objection against a patch but it seems > a bit academic as long as nobody complains (you can call me lazy too). I'm thinking that the entire option is just wrong. It sucks for distributors to have to make the choice between having it always on and having it always off. It sucks for end users compiling their own kernels, because their ethernet won't work out of the box, and they will have no idea what's wrong and what to do. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
Alexey Dobriyan wrote: On Fri, Dec 15, 2006 at 09:20:58PM +, James Porter wrote: For what it's worth, I don't see any problem with binary drivers from hardware manufacturers. Binary drivers from hardware manufacturers are crap. Learn it by heart. That's your personal opinion! A lot other people (including me) have had excellent experience with binary drivers! Just because nvidia makes a closed source driver doesn't mean that we can't also create an open source driver(limited functionality, reverse engineered, etc.,etc.). We can. The day you show me that the open-source driver is faster and more stable then the binary driver, I'll switch. But until then I'll stay with my binary driver. I haven't had any serious problems with it, in fact, I'm very happy, so why should I want to switch? I don't see Linux in such a political way like some of you do, for me Linux is just like any other OS. There are good drivers and bad drivers. And I don't care if they are open source or binary, I don't judge them based on that, but based on how well they work and how good the support is. But users of binary drivers should be blocked from sending bug reports to kernel developers. Most end-users will never get directly in touch with the kernel developers. They'll first go to their distribution. Most Ubuntu users don't even know what a kernel is (not that I use Ubuntu, but it's a distribution that is widespread among the less experienced end-users and people who switch to Linux from the windows world). 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Sat, 16 Dec 2006, Alan wrote: > > blather and idiotic hogwash. "Information" doesn't want to be free, nor is > > it somethign you should fight for or necessarily even encourage. > > As a pedant that is the one item I have to pick you up on Linus. > Information wants to be free, the natural efficient economic state of > information is generally free in both senses. I would say that that is a different thing. It "takes effort" to actually hide information, so in that sense, it's actually more expensive to try to keep it "non-free". But that has nothing to do with the FSF kind of "freedom", the same way "no price" has nothing to do with that freedom. So "information wants to be free" is more about "free as in beer", I'd argue. Trying to suppress information (or spread mis-information) takes real effort. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.18.5 usb/sysfs bug.
On Fri, 15 Dec 2006 16:37:15 -0500, Dave Jones <[EMAIL PROTECTED]> wrote:
> Linux version 2.6.18-1.2864.fc6 ([EMAIL PROTECTED]) (gcc version 4.1.1
> 20061011 (Red Hat 4.1.1-30)) #1 SMP Fri Dec 15 13:14:58 EST 2006
> Kernel command line: ro root=/dev/VolGroup00/LogVol00 profile=1 vga=791
> audit(1166218060.464:4): avc: denied { search } for pid=2678 comm="pcscd"
> name="usbdev2.4_ep03" dev=sysfs ino=1384
> scontext=system_u:system_r:pcscd_t:s0 tcontext=system_u:object_r:sysfs_t:s0
> tclass=dir
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 000b
But if you boot with selinux=0, everything works, right? Printk time.
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] Char: isicom, fix locking in isr
isicom, fix locking in isr
2 spin_unlocks are omitted in the interrupt handler. Put them there to fix
up deadlocking on UP.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit f2d37e8d3de070f8cda48a454f7b991d29b310be
tree 23027dcdc3215fbb488577edb9610322956edb0b
parent 5df5a993999b94d728cedfa669eba2b0b58e16d7
author Jiri Slaby <[EMAIL PROTECTED]> Wed, 13 Dec 2006 23:10:48 +0100
committer Jiri Slaby <[EMAIL PROTECTED]> Fri, 15 Dec 2006 20:29:34 +0059
drivers/char/isicom.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/char/isicom.c b/drivers/char/isicom.c
index 0362740..836e967 100644
--- a/drivers/char/isicom.c
+++ b/drivers/char/isicom.c
@@ -563,6 +563,7 @@ static irqreturn_t isicom_interrupt(int irq, void *dev_id)
port = card->ports + channel;
if (!(port->flags & ASYNC_INITIALIZED)) {
outw(0x, base+0x04); /* enable interrupts */
+ spin_unlock(>card_lock);
return IRQ_HANDLED;
}
@@ -677,6 +678,7 @@ static irqreturn_t isicom_interrupt(int irq, void *dev_id)
tty_flip_buffer_push(tty);
}
outw(0x, base+0x04); /* enable interrupts */
+ spin_unlock(>card_lock);
return IRQ_HANDLED;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] Char: isicom, augment card_reset
isicom, augment card_reset
- add 0xee to signatures
- change long delays to sleeps
- make one sleep shorter not to wait 3s
- portcount == 16 is also correct
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 405c17b09b010b41f6ec2388a11777e4048c7976
tree 4954b33027ee87193bfe91109d6fbc8b12c4e71a
parent e7087b32ad4b5ee1240fa7f9ba46a9b4566fe424
author Jiri Slaby <[EMAIL PROTECTED]> Fri, 15 Dec 2006 22:20:14 +0059
committer Jiri Slaby <[EMAIL PROTECTED]> Fri, 15 Dec 2006 22:20:14 +0059
drivers/char/isicom.c | 39 ++-
1 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/char/isicom.c b/drivers/char/isicom.c
index 5d2c345..7968160 100644
--- a/drivers/char/isicom.c
+++ b/drivers/char/isicom.c
@@ -1501,7 +1501,7 @@ static int __devinit reset_card(struct pci_dev *pdev,
{
struct isi_board *board = pci_get_drvdata(pdev);
unsigned long base = board->base;
- unsigned int portcount = 0;
+ unsigned int sig, portcount = 0;
int retval = 0;
dev_dbg(>dev, "ISILoad:Resetting Card%d at 0x%lx\n", card + 1,
@@ -1509,27 +1509,35 @@ static int __devinit reset_card(struct pci_dev *pdev,
inw(base + 0x8);
- mdelay(10);
+ msleep(10);
outw(0, base + 0x8); /* Reset */
- msleep(3000);
+ msleep(1000);
- *signature = inw(base + 0x4) & 0xff;
+ sig = inw(base + 0x4) & 0xff;
+
+ if (sig != 0xa5 && sig != 0xbb && sig != 0xcc && sig != 0xdd &&
+ sig != 0xee) {
+ dev_warn(>dev, "ISILoad:Card%u reset failure (Possible "
+ "bad I/O Port Address 0x%lx).\n", card + 1, base);
+ dev_dbg(>dev, "Sig=0x%x\n", sig);
+ retval = -EIO;
+ goto end;
+ }
+
+ msleep(10);
portcount = inw(base + 0x2);
- if (!(inw(base + 0xe) & 0x1) || ((portcount != 0) &&
- (portcount != 4) && (portcount != 8))) {
- dev_dbg(>dev, "base+0x2=0x%lx, base+0xe=0x%lx\n",
- inw(base + 0x2), inw(base + 0xe));
- dev_err(>dev, "ISILoad:PCI Card%d reset failure "
- "(Possible bad I/O Port Address 0x%lx).\n",
- card + 1, base);
+ if (!inw(base + 0xe) & 0x1 || (portcount != 0 && portcount != 4 &&
+ portcount != 8 && portcount != 16)) {
+ dev_err(>dev, "ISILoad:PCI Card%d reset failure.",
+ card + 1);
retval = -EIO;
goto end;
}
- switch (*signature) {
+ switch (sig) {
case 0xa5:
case 0xbb:
case 0xdd:
@@ -1537,16 +1545,13 @@ static int __devinit reset_card(struct pci_dev *pdev,
board->shift_count = 12;
break;
case 0xcc:
+ case 0xee:
board->port_count = 16;
board->shift_count = 11;
break;
- default:
- dev_warn(>dev, "ISILoad:Card%d reset failure (Possible "
- "bad I/O Port Address 0x%lx).\n", card + 1, base);
- dev_dbg(>dev, "Sig=0x%lx\n", signature);
- retval = -EIO;
}
dev_info(>dev, "-Done\n");
+ *signature = sig;
end:
return retval;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] Char: isicom, check card state in isr
isicom, check card state in isr Check if the card really interrupted us by reading its IO space and eventualy return IRQ_NONE. Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> --- commit 601667e4ee38183358ea8f7980537bb8c09d8728 tree ccb1c085309ad35178f8d741e7c074308ae277ee parent 405c17b09b010b41f6ec2388a11777e4048c7976 author Jiri Slaby <[EMAIL PROTECTED]> Fri, 15 Dec 2006 23:29:57 +0059 committer Jiri Slaby <[EMAIL PROTECTED]> Fri, 15 Dec 2006 23:29:57 +0059 drivers/char/isicom.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/char/isicom.c b/drivers/char/isicom.c index 7968160..f4faa76 100644 --- a/drivers/char/isicom.c +++ b/drivers/char/isicom.c @@ -539,6 +539,11 @@ static irqreturn_t isicom_interrupt(int irq, void *dev_id) return IRQ_NONE; base = card->base; + + /* did the card interrupt us? */ + if (!(inw(base + 0x0e) & 0x02)) + return IRQ_NONE; + spin_lock(>card_lock); /* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] Char: isicom, fix probe race
isicom, fix probe race
Fix two race conditions in the probe function with mutex.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit e7087b32ad4b5ee1240fa7f9ba46a9b4566fe424
tree 28bc5ad2a47c03e1b7a09fce22afbe7000955e97
parent f2d37e8d3de070f8cda48a454f7b991d29b310be
author Jiri Slaby <[EMAIL PROTECTED]> Fri, 15 Dec 2006 21:08:11 +0059
committer Jiri Slaby <[EMAIL PROTECTED]> Fri, 15 Dec 2006 21:08:11 +0059
drivers/char/isicom.c | 26 --
1 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/char/isicom.c b/drivers/char/isicom.c
index 836e967..5d2c345 100644
--- a/drivers/char/isicom.c
+++ b/drivers/char/isicom.c
@@ -1732,22 +1732,25 @@ end:
/*
* Insmod can set static symbols so keep these static
*/
-static int card;
+static unsigned int card_count;
static int __devinit isicom_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
+ static DEFINE_MUTEX(probe_lock);
unsigned int ioaddr, signature, index;
int retval = -EPERM;
- u8 pciirq;
struct isi_board *board = NULL;
- if (card >= BOARD_COUNT)
+ mutex_lock(_lock);
+ if (card_count >= BOARD_COUNT) {
+ mutex_unlock(_lock);
goto err;
+ }
+ card_count++;
ioaddr = pci_resource_start(pdev, 3);
/* i.e at offset 0x1c in the PCI configuration register space. */
- pciirq = pdev->irq;
dev_info(>dev, "ISI PCI Card(Device ID 0x%x)\n", ent->device);
/* allot the first empty slot in the array */
@@ -1759,8 +1762,9 @@ static int __devinit isicom_probe(struct pci_dev *pdev,
board->index = index;
board->base = ioaddr;
- board->irq = pciirq;
- card++;
+ board->irq = pdev->irq;
+
+ mutex_unlock(_lock);
pci_set_drvdata(pdev, board);
@@ -1770,7 +1774,7 @@ static int __devinit isicom_probe(struct pci_dev *pdev,
"will be disabled.\n", board->base, board->base + 15,
index + 1);
retval = -EBUSY;
- goto err;
+ goto err_dec;
}
retval = request_irq(board->irq, isicom_interrupt,
@@ -1799,8 +1803,10 @@ errunri:
free_irq(board->irq, board);
errunrr:
pci_release_region(pdev, 3);
-err:
+err_dec:
+ card_count--;
board->base = 0;
+err:
return retval;
}
@@ -1814,6 +1820,8 @@ static void __devexit isicom_remove(struct pci_dev *pdev)
free_irq(board->irq, board);
pci_release_region(pdev, 3);
+ card_count--;
+ board->base = 0;
}
static int __init isicom_init(void)
@@ -1821,8 +1829,6 @@ static int __init isicom_init(void)
int retval, idx, channel;
struct isi_port *port;
- card = 0;
-
for(idx = 0; idx < BOARD_COUNT; idx++) {
port = _ports[idx * 16];
isi_card[idx].ports = port;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] Char: isicom, support higher rates
isicom, support higher rates
Add support for higher baud rates (coming from original isi driver).
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 8b380d8b1c3ff7d09d68d467d2f135774cab4086
tree d1e9332d7dc76c5f1d80f936bca71312d0bcb07b
parent 601667e4ee38183358ea8f7980537bb8c09d8728
author Jiri Slaby <[EMAIL PROTECTED]> Sat, 16 Dec 2006 02:05:20 +0059
committer Jiri Slaby <[EMAIL PROTECTED]> Sat, 16 Dec 2006 02:05:20 +0059
drivers/char/isicom.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/char/isicom.c b/drivers/char/isicom.c
index f4faa76..60df87c 100644
--- a/drivers/char/isicom.c
+++ b/drivers/char/isicom.c
@@ -183,7 +183,7 @@ static DEFINE_TIMER(tx, isicom_tx, 0, 0);
/* baud index mappings from linux defns to isi */
static signed char linuxb_to_isib[] = {
- -1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 15, 16, 17, 18, 19
+ -1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 13, 15, 16, 17, 18, 19, 20, 21
};
struct isi_board {
@@ -709,7 +709,8 @@ static void isicom_config_port(struct isi_port *port)
* respectively.
*/
- if (baud < 1 || baud > 2)
+ /* 1,2,3,4 => 57.6, 115.2, 230, 460 kbps resp. */
+ if (baud < 1 || baud > 4)
port->tty->termios->c_cflag &= ~CBAUDEX;
else
baud += 15;
@@ -725,6 +726,10 @@ static void isicom_config_port(struct isi_port *port)
baud++; /* 57.6 Kbps */
if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_VHI)
baud +=2; /* 115 Kbps */
+ if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_SHI)
+ baud += 3; /* 230 kbps*/
+ if ((port->flags & ASYNC_SPD_MASK) == ASYNC_SPD_WARP)
+ baud += 4; /* 460 kbps*/
}
if (linuxb_to_isib[baud] == -1) {
/* hang up */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems
> >The idea behind the cloneset is that most of the blocks (or files) > >do not change in either source or target. This being the case its only > necessary > >to update the changed elements. This means updates are incremental. Once > >the system has figured out what it needs to update its usable and if you > access > >an element that should be updated you will see the correctly updated > version - even > >though backgound resyncing is still in progress. > > I still can't tell what you're describing. With RAID1 as well, only > changed elements ever get updated. I have two identical filesystems, > members of a RAIF set. I change one file. One file in each member > filesystem gets updated, and I again have two identical filesystems. > > How would a cloneset work differently, and how would it be better? Thanks, Bryan. I was about to write almost the same. > > This type of logic is great for backups. > > Can you give an example of using it for backup? I guess, you can mount Versionfs (yet another stackable file system) below RAIF and above one of the lower file systems or use some other versioning file system such as ext3cow. This will allow rolling back to any older file system version at any time. Nikolai. - Nikolai Joukov, Ph.D. Filesystems and Storage Laboratory Stony Brook University - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
> blather and idiotic hogwash. "Information" doesn't want to be free, nor is > it somethign you should fight for or necessarily even encourage. As a pedant that is the one item I have to pick you up on Linus. Information wants to be free, the natural efficient economic state of information is generally free in both senses. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Nasty warnings on arm (+ one compile problem -- INIT_WORK related)
> Plus compile error. It should be some search I should do, but
> which one?
>
> drivers/video/sa1100fb.c:1447:49: macro "INIT_WORK" passed 3
> arguments, but takes just 2
> drivers/video/sa1100fb.c: In function `sa1100fb_init_fbinfo':
> drivers/video/sa1100fb.c:1447: error: `INIT_WORK' undeclared (first
> use in this function)
> drivers/video/sa1100fb.c:1447: error: (Each undeclared identifier is
> reported only once
> drivers/video/sa1100fb.c:1447: error: for each function it appears
> in.)
> drivers/video/sa1100fb.c: At top level:
> drivers/video/sa1100fb.c:1204: warning: `sa1100fb_task' defined but
> not used
> make[2]: *** [drivers/video/sa1100fb.o] Error 1
> make[1]: *** [drivers/video] Error 2
> make: *** [drivers] Error 2
>
> INIT_WORK(>task, sa1100fb_task, fbi);
>
> ...
>
> /*
> * Our LCD controller task (which is called when we blank or unblank)
> * via keventd.
> */
> static void sa1100fb_task(void *dummy)
> {
> struct sa1100fb_info *fbi = dummy;
> u_int state = xchg(>task_state, -1);
>
> set_ctrlr_state(fbi, state);
> }
>
> (Or will I need to play with container_of or something? I guess I did
> not pay attetion to workqueue stuff).
... and that's
static void sa1100fb_task(struct work_struct *ucking_fugly)
{
struct sa1100fb_info *fbi = container_of(ucking_fugly,
struct sa1100fb_info,
task);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Nasty warnings on arm (+ one compile problem -- INIT_WORK related)
On Sat, Dec 16, 2006 at 12:58:18AM +0100, Pavel Machek wrote:
> Hi!
>
> I get nasty warning for each file compiled:
>
> CC drivers/video/sa1100fb.o
> In file included from include/asm/bitops.h:23,
> from include/linux/bitops.h:9,
> from include/linux/thread_info.h:20,
> from include/linux/preempt.h:9,
> from include/linux/spinlock.h:49,
> from include/linux/module.h:9,
> from drivers/video/sa1100fb.c:163:
> include/asm/system.h: In function `adjust_cr':
> include/asm/system.h:185: warning: implicit declaration of function
> `local_irq_save'
> include/asm/system.h:192: warning: implicit declaration of function
> `local_irq_restore'
> include/asm/system.h:179: warning: unused variable `cr'
That's dealt with by the following:
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/include/asm-arm/system.h b/include/asm-arm/system.h
index e160aeb..bf44782 100644
--- a/include/asm-arm/system.h
+++ b/include/asm-arm/system.h
@@ -173,10 +173,12 @@ static inline void set_copro_access(unsi
extern unsigned long cr_no_alignment; /* defined in entry-armv.S */
extern unsigned long cr_alignment; /* defined in entry-armv.S */
+#include
+
#ifndef CONFIG_SMP
static inline void adjust_cr(unsigned long mask, unsigned long set)
{
- unsigned long flags, cr;
+ unsigned long flags;
mask &= ~CR_A;
@@ -248,8 +250,6 @@ static inline void sched_cacheflush(void
{
}
-#include
-
#ifdef CONFIG_SMP
#define smp_mb() mb()
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems
> > We have designed a new stackable file system that we called RAIF: > > Redundant Array of Independent Filesystems. > > > > Similar to Unionfs, RAIF is a fan-out file system and can be mounted over > > many different disk-based, memory, network, and distributed file systems. > > RAIF can use the stable and maintained code of the other file systems and > > thus stay simple itself. Similar to standard RAID, RAIF can replicate the > > data or store it with parity on any subset of the lower file systems. RAIF > > has three main advantages over traditional driver-level RAID systems: > > this sounds very interesting. did you see the paper on chunkfs? > http://www.usenix.org/events/hotdep06/tech/prelim_papers/henson/henson_html/ I saw Val at OSDI right before this HotDep talk and sure, I have seen the paper :-) > this sounds as if it may be something that you would be able to make a > functional equivalent to chunkfs with your raid0 mode. I also have this feeling. RAIF0 is similar to chunkfs and allows more flexibility. Not only RAIF can stripe the data on many small local file systems (possibly located on multiple drives) but also can stripe the data on remote file systems. In addition, it can keep the parity, use per-file-type storage policies etc. However, such a configuration would mean lots and lots of lower file systems ( = branches = chunks). I am afraid that in this case RAIF's performance would be not so great due to VFS API restrictions for operations like lookup. Nikolai. - Nikolai Joukov, Ph.D. Filesystems and Storage Laboratory Stony Brook University - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))
Lennert Buytenhek <[EMAIL PROTECTED]> : [...] > No, that wouldn't make sense, that's like making a workaround depend on > arch == i386. > > I'm thinking that we should somehow enable this option on the n2100 > built-in r8169 ports by default only. Since the n2100 also has a mini-PCI > slot, and it is in theory possible to put an r8169 on a mini-PCI card, > the workaround probably shouldn't apply to those, so testing for > CONFIG_MACH_N2100 also isn't the right thing to do. Ok, I thought it was a useability thing. Let aside a few configurations, the sensible default value for this option is not clear. I have no objection against a patch but it seems a bit academic as long as nobody complains (you can call me lazy too). -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][RFC] consolidate line discipline number definitions
The line discipline code numbers N_* are currently defined
separately for each architecture in include/asm-${arch}/termios.h
which is in turn included by include/linux/termios.h via the
symlink include/asm. I don't see any reason why these definitions
need to be architecture specific. They are identical for all
architectures, with a single exception: include/asm-cris/termios.h
doesn't define N_HCI, but instead defines N_BT with the same value
(15). This however appears to be a mistake rather than deliberate,
as N_BT isn't used anyhere in the 2.6.19 source tree.
Therefore I propose to consolidate these definitions by moving
them into the architecture independent part as by the patch below.
This would significantly reduce the effort for adding new line
disciplines and the danger of unnecessary divergence between
architectures as well as errors like the one cited above.
A few source files include directly instead of
and would therefore miss the moved definitions.
These are:
arch/mips/pmc-sierra/yosemite/atmel_read_eeprom.h
arch/parisc/hpux/ioctl.c
arch/sparc64/solaris/ioctl.c
arch/sparc64/solaris/socksys.c
arch/sparc64/solaris/timod.c
drivers/char/n_hdlc.c
drivers/serial/crisv10.h
Of these, only drivers/char/n_hdlc.c actually references a line
discipline number and is therefore also patched below to include
instead. For the others, I would like opinions
on whether to change them to too.
I would also like comments from someone versed in UML on whether
include/asm-um/termios.h, which includes "asm/arch/termios.h",
will need modification.
Thanks
Tilman
From: Tilman Schmidt <[EMAIL PROTECTED]>
Consolidate line discipline number definitions from
architecture-specific termios.h files into architecture
independent termios.h file.
Signed-off-by: Tilman Schmidt <[EMAIL PROTECTED]>
---
drivers/char/n_hdlc.c |2 +-
include/asm-alpha/termios.h | 18 --
include/asm-arm/termios.h | 18 --
include/asm-arm26/termios.h | 18 --
include/asm-avr32/termios.h | 18 --
include/asm-cris/termios.h| 18 --
include/asm-frv/termios.h | 18 --
include/asm-h8300/termios.h | 18 --
include/asm-i386/termios.h| 18 --
include/asm-ia64/termios.h| 18 --
include/asm-m32r/termios.h| 18 --
include/asm-m68k/termios.h| 18 --
include/asm-mips/termios.h| 18 --
include/asm-parisc/termios.h | 18 --
include/asm-powerpc/termios.h | 18 --
include/asm-s390/termios.h| 18 --
include/asm-sh/termios.h | 18 --
include/asm-sh64/termios.h| 18 --
include/asm-sparc/termios.h | 18 --
include/asm-sparc64/termios.h | 18 --
include/asm-v850/termios.h| 18 --
include/asm-x86_64/termios.h | 18 --
include/asm-xtensa/termios.h | 19 ---
include/linux/termios.h | 19 +++
24 files changed, 20 insertions(+), 398 deletions(-)
diff -pur linux-2.6.19-orig/drivers/char/n_hdlc.c
linux-2.6.19/drivers/char/n_hdlc.c
--- linux-2.6.19-orig/drivers/char/n_hdlc.c 2006-11-29 22:57:37.0
+0100
+++ linux-2.6.19/drivers/char/n_hdlc.c 2006-12-15 19:12:39.0 +0100
@@ -103,9 +103,9 @@
#include /* used in new tty drivers */
#include
#include
+#include
#include
-#include
#include
/*
diff -pur linux-2.6.19-orig/include/asm-alpha/termios.h
linux-2.6.19/include/asm-alpha/termios.h
--- linux-2.6.19-orig/include/asm-alpha/termios.h 2006-11-29
22:57:37.0 +0100
+++ linux-2.6.19/include/asm-alpha/termios.h2006-12-15 18:55:12.0
+0100
@@ -66,24 +66,6 @@ struct termio {
#define _VEOL2 6
#define _VSWTC 7
-/* line disciplines */
-#define N_TTY 0
-#define N_SLIP 1
-#define N_MOUSE2
-#define N_PPP 3
-#define N_STRIP4
-#define N_AX25 5
-#define N_X25 6 /* X.25 async */
-#define N_6PACK7
-#define N_MASC 8 /* Reserved for Mobitex module <[EMAIL
PROTECTED]> */
-#define N_R39649 /* Reserved for Simatic R3964 module */
-#define N_PROFIBUS_FDL 10 /* Reserved for Profibus <[EMAIL PROTECTED]> */
-#define N_IRDA 11 /* Linux IrDa - http://irda.sourceforge.net/ */
-#define N_SMSBLOCK 12 /* SMS block mode - for talking to GSM data
cards about SMS messages */
-#define N_HDLC 13 /* synchronous HDLC */
-#define N_SYNC_PPP 14
-#define N_HCI 15 /* Bluetooth HCI UART */
-
#ifdef __KERNEL__
/* eof=^D eol=\0 eol2=\0 erase=del
werase=^W kill=^U reprint=^R sxtc=\0
diff -pur
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Sat, 16 Dec 2006, karderio wrote: > > If the "free software community" has the clout to twist vendor's arms to > get them release driver source, then I'm all for it. I don't care what you're for, or what your imaginary "free software community" is for. We're "open source", and we're not a religion. We don't "twist peoples arms". We show people what we think is a better way, and we let them participate. We don't force it, we don't twist it, and it's ok not to believe in the GPL or our ideals. In fact, "our ideals" aren't even one unified thing to begin with. We also don't try to pervert copyright into a "you have to _use_ things in a certain way". We don't think "fair use" is a bad thing. We encourage it, and that means that we have to abide by it ourselves. It means, most particularly, that even people we disagree with have that right of "fair use". That, btw, is what "freedom" and "rights" are all about. It's obly meaningful when you grant those rights to people you don't agree with. Also, since you haven't apparently gotten the memo yet, let me point it out to you: the end results don't justify the means, and never did. So arm-twisting doesn't become good just because you think the end result might be worth it. It's still bad. And btw, that "information freedom" thing you talked about is just so much blather and idiotic hogwash. "Information" doesn't want to be free, nor is it somethign you should fight for or necessarily even encourage. It doesn't hold a candle to _peoples_ freedom, the foremost of which is to just disagree with you. Once you allow people to talk and do what they want, that "information freedom" will follow. It's not a religion, and it's not about suppressing other people and other viewpoints. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems
On Wed, 13 Dec 2006, Nikolai Joukov wrote: We have designed a new stackable file system that we called RAIF: Redundant Array of Independent Filesystems. Similar to Unionfs, RAIF is a fan-out file system and can be mounted over many different disk-based, memory, network, and distributed file systems. RAIF can use the stable and maintained code of the other file systems and thus stay simple itself. Similar to standard RAID, RAIF can replicate the data or store it with parity on any subset of the lower file systems. RAIF has three main advantages over traditional driver-level RAID systems: this sounds very interesting. did you see the paper on chunkfs? http://www.usenix.org/events/hotdep06/tech/prelim_papers/henson/henson_html/ this sounds as if it may be something that you would be able to make a functional equivalent to chunkfs with your raid0 mode. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING (1) at .../arch/i386/mm/highmem.c:49 [Was: 2.6.20-rc1-mm1]
On Sat, 16 Dec 2006 00:25:43 +0059 Jiri Slaby <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/ > > Ok, after fixing sata_promise, I got this 7 times: > [ 30.957539] WARNING (1) at /home/l/latest/xxx/arch/i386/mm/highmem.c:49 > kmap_atomic() > [ 30.957642] [] show_trace_log_lvl+0x1a/0x30 > [ 30.957748] [] show_trace+0x12/0x14 > [ 30.957846] [] dump_stack+0x16/0x18 > [ 30.957944] [] kmap_atomic+0x1f8/0x20d > [ 30.958041] [] ntfs_end_buffer_async_read+0x191/0x2ed > [ 30.958142] [] end_bio_bh_io_sync+0x26/0x3f > [ 30.958241] [] bio_endio+0x37/0x62 > [ 30.958338] [] __end_that_request_first+0x224/0x445 > [ 30.958441] [] end_that_request_chunk+0x8/0xa > [ 30.958541] [] scsi_end_request+0x1f/0xc6 > [ 30.958640] [] scsi_io_completion+0x1a1/0x336 > [ 30.958738] [] sd_rw_intr+0x23/0x1ab > [ 30.958835] [] scsi_finish_command+0x42/0x47 > [ 30.958935] [] scsi_softirq_done+0x64/0xca > [ 30.959032] [] blk_done_softirq+0x54/0x62 > [ 30.959132] [] __do_softirq+0x75/0xde > [ 30.959229] [] do_softirq+0x3b/0x3d > [ 30.959326] [] irq_exit+0x3b/0x3e > [ 30.959423] [] do_IRQ+0x45/0x7f > [ 30.959540] [] common_interrupt+0x23/0x28 > [ 30.959713] [] cpu_idle+0x7c/0xba > [ 30.959809] [] rest_init+0x23/0x37 > [ 30.959951] [] start_kernel+0x337/0x3e8 bah, that's a false positive. I'll teach kmap_atomic-debugging.patch about KM_BIO_SRC_IRQ and KM_BIO_DST_IRQ, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: realtime-preempt and arm
[EMAIL PROTECTED]:~$ uname -r 2.6.19.1-rt15_00 And I'm totally thrilled since this is the first -rt kernel that I've tried and been able to boot since .16-rt29. Yay! [EMAIL PROTECTED]:~$ zcat /proc/config.gz | egrep "HZ.*=y" CONFIG_HZ_1000=y 100 revs; min: 5008 max: 5034 avg: 5015 100 revs; min: 5008 max: 5023 avg: 5010 100 revs; min: 5008 max: 5015 avg: 5009 100 revs; min: 5008 max: 5018 avg: 5009 100 revs; min: 5008 max: 5017 avg: 5009 100 revs; min: 5008 max: 5015 avg: 5009 100 revs; min: 5008 max: 5016 avg: 5009 100 revs; min: 5008 max: 5017 avg: 5009 100 revs; min: 5008 max: 5014 avg: 5009 100 revs; min: 5008 max: 5016 avg: 5009 100 revs; min: 5008 max: 5015 avg: 5009 100 revs; min: 5008 max: 5017 avg: 5009 100 revs; min: 5008 max: 5016 avg: 5009 100 revs; min: 5008 max: 5023 avg: 5010 100 revs; min: 5008 max: 5015 avg: 5009 100 revs; min: 5008 max: 5016 avg: 5009 100 revs; min: 5008 max: 5015 avg: 5009 100 revs; min: 5008 max: 5016 avg: 5009 100 revs; min: 5008 max: 5015 avg: 5009 100 revs; min: 5008 max: 5017 avg: 5009 100 revs; min: 5008 max: 5016 avg: 5009 100 revs; min: 5008 max: 5016 avg: 5009 100 revs; min: 5008 max: 5017 avg: 5009 100 revs; min: 5008 max: 5018 avg: 5009 100 revs; min: 5008 max: 5019 avg: 5009 100 revs; min: 5008 max: 5013 avg: 5009 quad Opteron running x86_64 Fedora Core 5. -- Robert Crocombe [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc1-mm1: unused sysrq_timer_list_show()
On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote: >... > Changes since 2.6.19-mm1: >... > +debugging-feature-proc-timer_list.patch > > Refreshed, refactored dynticks/hrtimer queue. >... I'd assume sysrq_timer_list_show() wasn't intended to be unused? 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: OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]
On Fri, 15 Dec 2006 11:24:12 -0800, Andrew Morton wrote:
>On Fri, 15 Dec 2006 15:45:55 +0059
>Jiri Slaby <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton wrote:
>> > Temporarily at
>> >
>> >http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
>> >
>> > Will appear later at
>> >
>> >
>> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
>>
>> The kernel panics at boot in pdc_port_start+0x82 with deref of 0x14:
>> http://www.fi.muni.cz/~xslaby/sklad/pdc_oops.png
>>
>> ATA port is not connected, only 2 SATA disks on my
>> # lspci -vvxs 02:01.0
>> 02:01.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300
>> TX2plus) (rev 02)
>> Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B-
>> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
>> SERR- > Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 4 bytes
>> Interrupt: pin A routed to IRQ 19
>> Region 0: I/O ports at 8000 [size=128]
>> Region 2: I/O ports at 8400 [size=256]
>> Region 3: Memory at fb025000 (32-bit, non-prefetchable) [size=4K]
>> Region 4: Memory at fb00 (32-bit, non-prefetchable) [size=128K]
>> [virtual] Expansion ROM at 5000 [disabled] [size=32K]
>> Capabilities: [60] Power Management version 2
>> Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>> 00: 5a 10 73 3d 07 00 30 02 02 00 80 01 01 48 00 00
>> 10: 01 80 00 00 00 00 00 00 01 84 00 00 00 50 02 fb
>> 20: 00 00 00 fb 00 00 00 00 00 00 00 00 5a 10 73 3d
>> 30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 04 12
>>
>
>Presumably
>
>void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;
>
>gave us a null pointer.
Yes, it does look like pdc_port_start() is invoked with scr_addr
being zero for the port.
The -mm patch kit includes the Promise 2037x PATA support patch,
via libata-all. That patch is incomplete and actually breaks 2057x
chips: it leaves the SATA flag set for all ports on 2057x, which
makes sata_scr_valid() erroneously return true for the PATA port,
and that breaks many things including pdc_port_start().
Applying the trivial patch below on top of 2.6.20-rc1-mm1 should
fix the oops and even make the PATA port work on the 2057x.
With this patch -mm1's sata_promise.c will match what I've been
using recently to access both SATA and PATA devices on 2057x.
/Mikael
diff -rupN linux-2.6.20-rc1-mm1/drivers/ata/sata_promise.c
linux-2.6.20-rc1-mm1.sata_promise-2057x-pata-fix/drivers/ata/sata_promise.c
--- linux-2.6.20-rc1-mm1/drivers/ata/sata_promise.c 2006-12-15
23:33:17.0 +0100
+++ linux-2.6.20-rc1-mm1.sata_promise-2057x-pata-fix/drivers/ata/sata_promise.c
2006-12-15 23:58:09.0 +0100
@@ -213,7 +213,7 @@ static const struct ata_port_info pdc_po
/* board_2057x */
{
.sht= _ata_sht,
- .flags = PDC_COMMON_FLAGS | ATA_FLAG_SATA,
+ .flags = PDC_COMMON_FLAGS /* | ATA_FLAG_SATA */,
.pio_mask = 0x1f, /* pio0-4 */
.mwdma_mask = 0x07, /* mwdma0-2 */
.udma_mask = 0x7f, /* udma0-6 ; FIXME */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nasty warnings on arm (+ one compile problem -- INIT_WORK related)
Hi!
I get nasty warning for each file compiled:
CC drivers/video/sa1100fb.o
In file included from include/asm/bitops.h:23,
from include/linux/bitops.h:9,
from include/linux/thread_info.h:20,
from include/linux/preempt.h:9,
from include/linux/spinlock.h:49,
from include/linux/module.h:9,
from drivers/video/sa1100fb.c:163:
include/asm/system.h: In function `adjust_cr':
include/asm/system.h:185: warning: implicit declaration of function
`local_irq_save'
include/asm/system.h:192: warning: implicit declaration of function
`local_irq_restore'
include/asm/system.h:179: warning: unused variable `cr'
Plus compile error. It should be some search I should do, but
which one?
drivers/video/sa1100fb.c:1447:49: macro "INIT_WORK" passed 3
arguments, but takes just 2
drivers/video/sa1100fb.c: In function `sa1100fb_init_fbinfo':
drivers/video/sa1100fb.c:1447: error: `INIT_WORK' undeclared (first
use in this function)
drivers/video/sa1100fb.c:1447: error: (Each undeclared identifier is
reported only once
drivers/video/sa1100fb.c:1447: error: for each function it appears
in.)
drivers/video/sa1100fb.c: At top level:
drivers/video/sa1100fb.c:1204: warning: `sa1100fb_task' defined but
not used
make[2]: *** [drivers/video/sa1100fb.o] Error 1
make[1]: *** [drivers/video] Error 2
make: *** [drivers] Error 2
INIT_WORK(>task, sa1100fb_task, fbi);
...
/*
* Our LCD controller task (which is called when we blank or unblank)
* via keventd.
*/
static void sa1100fb_task(void *dummy)
{
struct sa1100fb_info *fbi = dummy;
u_int state = xchg(>task_state, -1);
set_ctrlr_state(fbi, state);
}
(Or will I need to play with container_of or something? I guess I did
not pay attetion to workqueue stuff).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems
On Friday 15 December 2006 15:11, Nikolai Joukov wrote: > > On Wednesday 13 December 2006 12:47, Nikolai Joukov wrote: > > > We have designed a new stackable file system that we called RAIF: > > > Redundant Array of Independent Filesystems > > > > Do you have a function similar to an an EMC cloneset? Basicily a cloneset > > tracks what has changed in both the source and target luns (drives). When > > one > > updates the cloneset the target is made identical to the source. Its a > > great > > way to do backups. Its an important feature to be able to write to the > > target drives. > > I would love to see this working at a filesystem level. > > Well, if you mount RAIF over your file system and a for-backups file > system, RAIF can replicate the files on both of them automatically. I > guess that's what you need. Yes and no. The idea behind the cloneset is that most of the blocks (or files) do not change in either source or target. This being the case its only necessary to update the changed elements. This means updates are incremental. Once the system has figured out what it needs to update its usable and if you access an element that should be updated you will see the correctly updated version - even though backgound resyncing is still in progress. This type of logic is great for backups. Thanks Ed Tomlinson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Hi :o) Linus Torvalds wrote : > The silly thing is, the people who tend to push most for this are the > exact SAME people who say that the RIAA etc should not be able to tell > people what to do with the music copyrights that they own, and that the > DMCA is bad because it puts technical limits over the rights expressly > granted by copyright law. > > Doesn't anybody else see that as being hypocritical? > > So it's ok when we do it, but bad when other people do it? Somehow I'm not > surprised, but I still think it's sad how you guys are showing a marked > two-facedness about this. The comparison of what is being suggested for kernel modules to the actions of the RIAA doesn't seem very fitting. If anything is being pushed, and anybody is being told what to do, it seems to be pushing for "openness" and telling corporations to provide important information about their products. The RIAA seems to be doing the opposite, enforcing total control over what they release. Apparently, the GPL itself is a compromise, in order to assure freedom of information in a non-ideal world. The GPL combats copyright law with copyright law, it's paradoxical but not hypocritical, and what is being suggested here for kernel modules seems analog. To call people who are struggling for freedom with comparatively few resources "two faced" or "hypocritical" when they must compromise on their principles doesn't seem all that fair. If the "free software community" has the clout to twist vendor's arms to get them release driver source, then I'm all for it. I'm generally not at all combative, and would generally argue for leaving people free to do as they wish. In this case I think the issue, the freedom of information, is rather an important one, and within reason measures should be taken to defend it. Love, Karderio. "He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]
Mikael Pettersson wrote: > Applying the trivial patch below on top of 2.6.20-rc1-mm1 should Yup, Jeff fwd me this yet and it works. thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-git19: lockdep messages on console
On 12/15/06, Jarek Poplawski <[EMAIL PROTECTED]> wrote: On 12-12-2006 20:49, Alessandro Suardi wrote: > Very shortly after boot on my K7-800 running up-to-date FC6 > and 2.6.19-git19; didn't happen in 2.6.19-vanilla: ... > [ 134.915521] INFO: trying to register non-static key. > [ 134.915890] the code is fine but needs lockdep annotation. > [ 134.916249] turning off the locking correctness validator. It looks like repaired in 2.6.20-rc1 by this: [patch] lockdep: fix seqlock_init() Thanks Jarek, I don't seem to get it in -git20 already. Ciao, --alessandro "...when I get it, I _get_ it" (Lara Eidemiller) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
minix 3 released under BSD-like license
http://www.minix3.org/ maybe this development will spur an open device driver standard, or adoption of wrappers for the unified BSD driver standard into other frameworks -- He thought he could organize freedom how naive and controlling of him - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Friday, 15 December 2006 23:24, Jeff Garzik wrote: > Rafael J. Wysocki wrote: > > On Friday, 15 December 2006 22:39, Andrew Morton wrote: > >> On Fri, 15 Dec 2006 13:05:52 -0800 > >> Andrew Morton <[EMAIL PROTECTED]> wrote: > >> > >>> Jeff, I shall send all the sata patches which I have at you one single > >>> time > >>> and I shall then drop the lot. So please don't flub them. > >>> > >>> I'll then do a rc1-mm2 without them. > >> hm, this is looking like a lot of work for not much gain. Rafael, are > >> you able to do a quick chop and tell us whether these: > >> > >> pci-move-pci_vdevice-from-libata-to-core.patch > >> pata_cs5530-suspend-resume-support-tweak.patch > >> ata-fix-platform_device_register_simple-error-check.patch > >> initializer-entry-defined-twice-in-pata_rz1000.patch > >> pata_via-suspend-resume-support-fix.patch > >> sata_nv-add-suspend-resume-support.patch > >> libata-simulate-report-luns-for-atapi-devices.patch > >> user-of-the-jiffies-rounding-patch-ata-subsystem.patch > >> libata-fix-oops-with-sparsemem.patch > >> sata_nv-fix-kfree-ordering-in-remove.patch > >> libata-dont-initialize-sg-in-ata_exec_internal-if-dma_none-take-2.patch > >> pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch > >> > >> are innocent? > > > > Yes, they are. > > We all really appreciate your patience :) This is good feedback. > > To narrow down some more, does applying 2.6.20-rc1 + the attached patch > work? (ignoring -mm tree altogether) Yes, it does. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
WARNING (1) at .../arch/i386/mm/highmem.c:49 [Was: 2.6.20-rc1-mm1]
Andrew Morton wrote: > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/ Ok, after fixing sata_promise, I got this 7 times: [ 30.957539] WARNING (1) at /home/l/latest/xxx/arch/i386/mm/highmem.c:49 kmap_atomic() [ 30.957642] [] show_trace_log_lvl+0x1a/0x30 [ 30.957748] [] show_trace+0x12/0x14 [ 30.957846] [] dump_stack+0x16/0x18 [ 30.957944] [] kmap_atomic+0x1f8/0x20d [ 30.958041] [] ntfs_end_buffer_async_read+0x191/0x2ed [ 30.958142] [] end_bio_bh_io_sync+0x26/0x3f [ 30.958241] [] bio_endio+0x37/0x62 [ 30.958338] [] __end_that_request_first+0x224/0x445 [ 30.958441] [] end_that_request_chunk+0x8/0xa [ 30.958541] [] scsi_end_request+0x1f/0xc6 [ 30.958640] [] scsi_io_completion+0x1a1/0x336 [ 30.958738] [] sd_rw_intr+0x23/0x1ab [ 30.958835] [] scsi_finish_command+0x42/0x47 [ 30.958935] [] scsi_softirq_done+0x64/0xca [ 30.959032] [] blk_done_softirq+0x54/0x62 [ 30.959132] [] __do_softirq+0x75/0xde [ 30.959229] [] do_softirq+0x3b/0x3d [ 30.959326] [] irq_exit+0x3b/0x3e [ 30.959423] [] do_IRQ+0x45/0x7f [ 30.959540] [] common_interrupt+0x23/0x28 [ 30.959713] [] cpu_idle+0x7c/0xba [ 30.959809] [] rest_init+0x23/0x37 [ 30.959951] [] start_kernel+0x337/0x3e8 [ 30.960090] [<>] 0x0 regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lots of code could be simplified by using ARRAY_SIZE()
On Fri, 15 Dec 2006, Robert P. J. Day wrote: > On Fri, 15 Dec 2006, Jan Engelhardt wrote: > > Even sizeof a / sizeof *a > > > > may happen. > > yes, sadly, there are a number of those as well. back to the drawing > board. It might be interesting to grep for anything that divides two sizeofs and eyeball the result for possible mistakes. This would provide some real benefit beyond the cosmetical changes. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Task watchers v2
On Fri, 2006-12-15 at 09:34 +0100, Christoph Hellwig wrote: > On Thu, Dec 14, 2006 at 04:07:55PM -0800, Matt Helsley wrote: > > Associate function calls with significant events in a task's lifetime much > > like > > we handle kernel and module init/exit functions. This creates a table for > > each > > of the following events in the task_watchers_table ELF section: > > > > WATCH_TASK_INIT at the beginning of a fork/clone system call when the > > new task struct first becomes available. > > > > WATCH_TASK_CLONE just before returning successfully from a fork/clone. > > > > WATCH_TASK_EXEC just before successfully returning from the exec > > system call. > > > > WATCH_TASK_UID every time a task's real or effective user id changes. > > > > WATCH_TASK_GID every time a task's real or effective group id changes. > > > > WATCH_TASK_EXIT at the beginning of do_exit when a task is exiting > > for any reason. > > > > WATCH_TASK_FREE is called before critical task structures like > > the mm_struct become inaccessible and the task is subsequently freed. > > > > The next patch will add a debugfs interface for measuring fork and exit > > rates > > which can be used to calculate the overhead of the task watcher > > infrastructure. > > What's the point of the ELF hackery? This code would be a lot simpler > and more understandable if you simply had task_watcher_ops and a > register / unregister function for it. A bit more verbose response: I posted a notifier chain implementation back in June that bears some resemblance to your suggestion -- a structure needed to be registered at runtime. There was a single global list of them to iterate over for each event. This patch and the following patches are significantly shorter than their counterparts in that series. They avoid iterating over elements with empty ops. The way function pointers and function bodies are grouped together by this series should improve locality. The fact that there's no locking required also makes it simpler to analyze and use. The patches to allow modules to register task watchers does make things more complex though -- that does require a list and a lock. However, the lock does not need to be taken in the fork/exec/etc paths if we pin the module. In contrast your suggested approach is simpler because it doesn't treat modules any differently. However overall I think the balance still favors these patches. Cheers, -Matt Helsley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [panic] aacraid on 2.4.33.4 w/ PERC 3/Di
Hello Mark, On Thu, Dec 14, 2006 at 03:20:24PM -0500, Mark Drago wrote: > Hello, > > I have been seeing some kernel panics on a Dell PowerEdge 2650 with a > PERC 3/Di raid controller doing RAID 1. I have now seen the panics > occur on multiple PE2650s. The panic seems to occur during periods of > high disk activity. I am able to reliably reproduce the crashes by > running Bonnie in a loop. > > I originally saw the panics with a 2.4.32 kernel which had a few patches > in it, none directly related to scsi or aacraid. The patches were a few > from netfilter's patch-o-matic-ng, jgarzik's libata for 2.4.32, ebtables > and an updated Tigon3 driver from Broadcom. In order to verify that > none of these patches were causing any problems I checked that the panic > still happened with a stock 2.4.33.4 kernel. > > I have included below the oops output converted by ksymoops for the > panic that occurred on the stock 2.4.33.4 kernel. I have seen the > problem when running both an SMP and non-SMP kernel. Also included > below are relevant sections from my .config, lspci and /proc/scsi/scsi. > I have also included 3 other oopses that were seen with the patched > 2.4.32 kernel at the very bottom of this email. If there is any other > information I can provide to aid debugging please let me know. > > All of the kernels were compiled with gcc-3.3.6. I have not yet seen > the panic occur on 2.6 kernels. I am however currently running the > Bonnie test on 2.6.18.2. > > Any information regarding this panic, how best to avoid it, or what to > do to further debug the problem is greatly appreciated. I'm a bit embarrassed with your bug. sched.c:564 is "Schedule in interrupt". I've followed the interupt path from aac_queue_command() to aac_queue_get() and aac_get_entry(), but I still fail to see where this damn code would be able to directly or indirectly schedule :-/ Most probably I have missed something. Unfortunately, I've just checked 2.6 driver, and it's quite different, so it's not possible right now to guess what change fixed the problem upstream. I'd like people at Dell to tell us if they already encountered this bug and why not, if there's a known workaround/bug pending. > Thank you, > Mark Drago Regards, Willy > > Script used to cause panic (just run and wait for a bit): > ^ > #!/bin/bash > filesize=2000 > while /bin/true; do > Bonnie -d /tmp -s $filesize &> /dev/null > done > > Oops output from panic on stock 2.4.33.4: > ^ > ksymoops 2.4.9 on i686 2.4.32-20060810. Options used > -V (specified) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.33-20061213-smp (specified) > -m /boot/System.map-2.4.33.4-20061213-smp (specified) > > kernel BUG a sched.c:564! > CPU:0 > EIP:0010:[] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010282 > eax: 0018 ebx: f7b901ec ecx: c042e000 edx: 0001 > esi: c042e000 edi: ebp: c042fd50 esp: c042fd2c > ds: 0018 es: 0018 ss: 0018 > Process swapper (pid: 0, stackpage=c044f000) > Stack: c03590be c042e000 0002 c042e000 c042fd58 c024d909 f7b901ec > c042e000 > f7b901f4 c042fd58 c01074bb 0001 c042e000 f7b901f8 f7b901f8 > f7bf40c0 > 0001 f7b901e0 f7bf447c c0107648 f7b901ec fff5 > c024e37a > Call Trace:[] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] > Code: 0f 0b 34 02 b6 90 35 c0 58 e9 45 fb ff ff 0f 0b 2d 02 b6 90 > > > >>EIP; c01155c2<= > > >>ecx; c042e000 > >>esi; c042e000 > >>ebp; c042fd50 > >>esp; c042fd2c > > Trace; c024d909 > Trace; c01074bb <__down+6b/bc> > Trace; c0107648 <__down_failed+8/c> > Trace; c024e37a <.text.lock.commsup+38/6e> > Trace; c024ab4c > Trace; c024b68e > Trace; c024a6a8 > Trace; c0240973 > Trace; c0240f6c > Trace; c0247017 > Trace; c02466cd > Trace; c0246914 <__scsi_end_request+180/1f8> > Trace; c0246ba8 > Trace; c02b92f4 > Trace; c0241209 > Trace; c02410b6 > Trace; c011d05e > Trace; c011cf40 > Trace; c011cd17 > Trace; c010a172 > Trace; c0106ca8 > Trace; c010c70c > Trace; c0106ca8 > Trace; c0160cd4 > Trace; c0106d42 > Trace; c0105000 <_stext+0/0> > > Code; c01155c2 > <_EIP>: > Code; c01155c2<= >0: 0f 0b ud2a <= > Code; c01155c4 >2: 34 02 xor$0x2,%al > Code; c01155c6 >4: b6 90 mov$0x90,%dh > Code; c01155c8 >6: 35 c0 58 e9 45xor$0x45e958c0,%eax > Code; c01155cd >b: fbsti > Code; c01155ce >c: ff(bad) > Code; c01155cf >d: ff 0f decl (%edi) > Code; c01155d1 >f: 0b 2d 02 b6 90 00 or 0x90b602,%ebp > > <0>Kernel panic: Aiee,
Re: [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment
On Wed, 13 Dec 2006, Nick Piggin wrote:
> Linus Torvalds wrote:
> >
> > On Tue, 12 Dec 2006, Russell King wrote:
> > >
> > > Why can't we just use atomic_t for this?
> >
> >
> > Well, others have answered that ("wrong sizes"), but I'm wavering on using
> > atomic_long_t. I have to admit that I'd rather not add a new accessor
> > function, when it _should_ be easier to use the current ones.
>
> I agree.
Ok, nobody ever did anything about this, so here's my try.
This uses "atomic_long_t" for the workstruct "data" field, which shares
the per-cpu pointer and the workstruct flag bits in one field.
This ONLY works if "atomic_set()" is actually atomic wrt the atomic bit
operations too, which is generally true on any architecture that does
atomics natively (or on UP when done by disabling interrupts), but may not
be true on architectures where atomic operations are faked with spinlocks,
and the two different kinds of atomic ops use different spinlocks.
Right now sparc32 is one such architecture, possibly the only one. It
would need to be fixed. Davem?
NOTE! This patch also depends on an unrealted fix that I already pushed
out, which fixes "delayed_work_pending()" which was totally broken before
(macro expansion would replace "work" whether it was used as a variable
_or_ as a struct member name). If that hasn't mirrored out yet, you should
just fix the "delayed_work_pending()" macro to look like
#define delayed_work_pending(w) \
work_pending(&(w)->work)
(ie use the "work_pending()" macro to do the heavy lifting, and do NOT use
the name "work" for the macro argument).
This is untested, other than to see that it compiles. It all looks very
obvious, but then, all my code always does, yet somehow bugs still creep
in occasionally. I personally suspect it's some really subtle SMTP bug
that corrupts my patches, but I've never caught it outright.
Anyway. It's bug-free-by-definition, since it's written by yours truly,
but people should probably test it and comment on it, in the unlikely
event that the evil gnomes lurking in the intarnet tubes corrupt it.
Comments?
Linus
---
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 5b13dcf..2a7b38d 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -8,16 +8,21 @@
#include
#include
#include
+#include
struct workqueue_struct;
struct work_struct;
typedef void (*work_func_t)(struct work_struct *work);
+/*
+ * The first word is the work queue pointer and the flags rolled into
+ * one
+ */
+#define work_data_bits(work) ((unsigned long *)(&(work)->data))
+
struct work_struct {
- /* the first word is the work queue pointer and the flags rolled into
-* one */
- unsigned long management;
+ atomic_long_t data;
#define WORK_STRUCT_PENDING 0 /* T if work item pending execution */
#define WORK_STRUCT_NOAUTOREL 1/* F if work item automatically
released on exec */
#define WORK_STRUCT_FLAG_MASK (3UL)
@@ -26,6 +31,9 @@ struct work_struct {
work_func_t func;
};
+#define WORK_DATA_INIT(autorelease) \
+ ATOMIC_LONG_INIT((autorelease) << WORK_STRUCT_NOAUTOREL)
+
struct delayed_work {
struct work_struct work;
struct timer_list timer;
@@ -36,13 +44,13 @@ struct execute_work {
};
#define __WORK_INITIALIZER(n, f) { \
- .management = 0,\
+ .data = WORK_DATA_INIT(0), \
.entry = { &(n).entry, &(n).entry }, \
.func = (f),\
}
#define __WORK_INITIALIZER_NAR(n, f) { \
- .management = (1 << WORK_STRUCT_NOAUTOREL), \
+ .data = WORK_DATA_INIT(1), \
.entry = { &(n).entry, &(n).entry }, \
.func = (f),\
}
@@ -82,17 +90,21 @@ struct execute_work {
/*
* initialize all of a work item in one go
+ *
+ * NOTE! No point in using "atomic_long_set()": useing a direct
+ * assignment of the work data initializer allows the compiler
+ * to generate better code.
*/
#define INIT_WORK(_work, _func)\
do {\
- (_work)->management = 0;\
+ (_work)->data = (atomic_long_t) WORK_DATA_INIT(0); \
INIT_LIST_HEAD(&(_work)->entry);\
PREPARE_WORK((_work), (_func)); \
} while (0)
#define INIT_WORK_NAR(_work, _func)\
do {\
- (_work)->management = (1 << WORK_STRUCT_NOAUTOREL); \
+
Re: OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]
Andrew Morton wrote:
> On Fri, 15 Dec 2006 15:45:55 +0059
> Jiri Slaby <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton wrote:
>>> Temporarily at
>>>
>>> http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
>>>
>>> Will appear later at
>>>
>>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
>> The kernel panics at boot in pdc_port_start+0x82 with deref of 0x14:
>> http://www.fi.muni.cz/~xslaby/sklad/pdc_oops.png
>>
>> ATA port is not connected, only 2 SATA disks on my
>> # lspci -vvxs 02:01.0
>> 02:01.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300
>> TX2plus) (rev 02)
>> Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B-
>> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
>> SERR- > Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 4 bytes
>> Interrupt: pin A routed to IRQ 19
>> Region 0: I/O ports at 8000 [size=128]
>> Region 2: I/O ports at 8400 [size=256]
>> Region 3: Memory at fb025000 (32-bit, non-prefetchable) [size=4K]
>> Region 4: Memory at fb00 (32-bit, non-prefetchable) [size=128K]
>> [virtual] Expansion ROM at 5000 [disabled] [size=32K]
>> Capabilities: [60] Power Management version 2
>> Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>> 00: 5a 10 73 3d 07 00 30 02 02 00 80 01 01 48 00 00
>> 10: 01 80 00 00 00 00 00 00 01 84 00 00 00 50 02 fb
>> 20: 00 00 00 fb 00 00 00 00 00 00 00 00 5a 10 73 3d
>> 30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 04 12
>>
>
> Presumably
>
> void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;
>
> gave us a null pointer.
>
> Something like this:
>
> diff -puN drivers/ata/sata_promise.c~a drivers/ata/sata_promise.c
> --- a/drivers/ata/sata_promise.c~a
> +++ a/drivers/ata/sata_promise.c
> @@ -294,6 +294,10 @@ static int pdc_port_start(struct ata_por
> void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;
> unsigned int tmp;
>
> + if (!mmio) {
> + rc = -EDOM;
> + goto out_kfree;
> + }
> tmp = readl(mmio + 0x014);
> tmp = (tmp & ~3) | 1; /* set bits 1:0 = 0:1 */
> writel(tmp, mmio + 0x014);
> _
>
> should perhaps let you wobble to a state where you can get us the full
> dmesg output, please.
>
> Actually, that should already be possible simply using netconsole.
I set it up and here it comes:
[6.779351] ACPI: PCI Interrupt :02:01.0[A] -> GSI 21 (level, low) ->
IRQ 19
[6.779483] sata_promise PATA port found
[6.779584] ata3: SATA max UDMA/133 cmd 0xF8816200 ctl 0xF8816238 bmdma 0x0
irq 19
[6.779708] ata4: SATA max UDMA/133 cmd 0xF8816280 ctl 0xF88162B8 bmdma 0x0
irq 19
[6.779831] BUG: unable to handle kernel NULL pointer dereference at virtual
address 0014
[6.779958] printing eip:
[6.780020] c02753b9
[6.780080] *pde =
[6.780142] Oops: [#1]
[6.780202] SMP
[6.780328] last sysfs file:
[6.780389] Modules linked in:
[6.780488] CPU:1
[6.780488] EIP:0060:[]Not tainted VLI
[6.780490] EFLAGS: 00010202 (2.6.20-rc1-mm1 #203)
[6.780680] EIP is at pdc_port_start+0x82/0xb0
[6.780742] eax: 0001 ebx: f7e3d9a0 ecx: edx:
[6.780808] esi: f7dcc2e8 edi: ebp: c193fe3c esp: c193fe24
[6.780873] ds: 007b es: 007b fs: 00d8 gs: ss: 0068
[6.780938] Process swapper (pid: 1, ti=c193e000 task=c1923a90
task.ti=c193e000)
[6.781004] Stack: 00d0 c1a59a80 c1adcc48 f7ea4000 f88162b8 f7dcc2e8
c193fe90 c026c724
[6.781398]0078 0004 0053 c043d998 f8816280 f88162b8
0013
[6.781789]f7ea4000 f7d91b00 f8816280 c1adcc48 0013 c1adcc00
0002 c01de64f
[6.782180] Call Trace:
[6.782298] [] show_trace_log_lvl+0x1a/0x30
[6.782396] [] show_stack_log_lvl+0xa5/0xca
[6.782494] [] show_registers+0x1d3/0x2b8
[6.782591] [] die+0x121/0x243
[6.782690] [] do_page_fault+0x2b8/0x5e8
[6.782788] [] error_code+0x7c/0x84
[6.782885] [] ata_device_add+0x1b1/0x516
[6.782983] [] pdc_ata_init_one+0x2a7/0x3e9
[6.783081] [] pci_device_probe+0x44/0x5f
[6.783180] [] driver_probe_device+0x75/0x12c
[6.783279] [] __driver_attach+0x8c/0x8e
[6.783376] [] bus_for_each_dev+0x44/0x62
[6.783476] [] driver_attach+0x19/0x1b
[6.783574] [] bus_add_driver+0x6a/0x188
[6.783671] [] driver_register+0x54/0x84
[6.783768] [] __pci_register_driver+0x45/0x73
[6.783865] [] pdc_ata_init+0xf/0x1b
[6.783967] [] init+0x10d/0x310
[6.784063] [] kernel_thread_helper+0x7/0x18
[
generic_file_buffered_write and O_SYNC
So I'm trying to get an understanding of the interactions between the
various aio_read/aio_write paths, and I ran across this gem at the end
of generic_file_buffered_write:
/*
* For now, when the user asks for O_SYNC, we'll actually give O_DSYNC
*/
if (likely(status >= 0)) {
if (unlikely((file->f_flags & O_SYNC) || IS_SYNC(inode))) {
if (!a_ops->writepage || !is_sync_kiocb(iocb))
status = generic_osync_inode(inode, mapping,
OSYNC_METADATA|OSYNC_DATA);
}
}
/*
* If we get here for O_DIRECT writes then we must have fallen through
* to buffered writes (block instantiation inside i_size). So we sync
* the file data here, to try to honour O_DIRECT expectations.
*/
if (unlikely(file->f_flags & O_DIRECT) && written)
status = filemap_write_and_wait(mapping);
So if there's a writepage function AND we're doing async i/o, then
skip the writeout for O_SYNC files. But always do writeout for dio,
synchronously. Why do we check for the existence of ->writepage, but
not ->writepages? Why do we ever skip writeback at all?
in addition to being poorly documented, this code looks to me like it
has a high likelyhood of being incorrect. can anyone clarify?
thanks
NATE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Friday, 15 December 2006 23:19, Jeff Garzik wrote: > Alan wrote: > > On Fri, 15 Dec 2006 13:39:27 -0800 > > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > >> On Fri, 15 Dec 2006 13:05:52 -0800 > >> Andrew Morton <[EMAIL PROTECTED]> wrote: > >> > >>> Jeff, I shall send all the sata patches which I have at you one single > >>> time > >>> and I shall then drop the lot. So please don't flub them. > >>> > >>> I'll then do a rc1-mm2 without them. > >> hm, this is looking like a lot of work for not much gain. Rafael, are > >> you able to do a quick chop and tell us whether these: > > > > The md one and the long history of reports about parallel I/O causing > > problems sounds a lot more like the kmap stuff you were worried about > > Andrew. I'd be very intereste dto know if it happens on x86_32 built with > > a standard memory split and no highmem > > 2.6.20-rc1 works, and 2.6.20-rc1 does not have the kmap_atomic() fix. > > Upstream does kmap_atomic(KM_USER0) and -mm does kmap_atomic(KM_IRQ0) On x86_64 that shouldn't be a problem, I think, and my machine is an x86_64 one. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
Rafael J. Wysocki wrote:
On Friday, 15 December 2006 22:39, Andrew Morton wrote:
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
Jeff, I shall send all the sata patches which I have at you one single time
and I shall then drop the lot. So please don't flub them.
I'll then do a rc1-mm2 without them.
hm, this is looking like a lot of work for not much gain. Rafael, are
you able to do a quick chop and tell us whether these:
pci-move-pci_vdevice-from-libata-to-core.patch
pata_cs5530-suspend-resume-support-tweak.patch
ata-fix-platform_device_register_simple-error-check.patch
initializer-entry-defined-twice-in-pata_rz1000.patch
pata_via-suspend-resume-support-fix.patch
sata_nv-add-suspend-resume-support.patch
libata-simulate-report-luns-for-atapi-devices.patch
user-of-the-jiffies-rounding-patch-ata-subsystem.patch
libata-fix-oops-with-sparsemem.patch
sata_nv-fix-kfree-ordering-in-remove.patch
libata-dont-initialize-sg-in-ata_exec_internal-if-dma_none-take-2.patch
pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch
are innocent?
Yes, they are.
We all really appreciate your patience :) This is good feedback.
To narrow down some more, does applying 2.6.20-rc1 + the attached patch
work? (ignoring -mm tree altogether)
The attached patch should /basically/ be the contents of Andrew's
git-netdev-all patch.
Jeff
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 984ab28..fb1de86 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -292,7 +292,7 @@ config PATA_ISAPNP
If unsure, say N.
config PATA_IT821X
- tristate "IT821x PATA support (Experimental)"
+ tristate "IT8211/2 PATA support (Experimental)"
depends on PCI && EXPERIMENTAL
help
This option enables support for the ITE 8211 and 8212
@@ -301,6 +301,15 @@ config PATA_IT821X
If unsure, say N.
+config PATA_IT8213
+ tristate "IT8213 PATA support (Experimental)"
+ depends on PCI && EXPERIMENTAL
+ help
+ This option enables support for the ITE 821 PATA
+ controllers via the new ATA layer.
+
+ If unsure, say N.
+
config PATA_JMICRON
tristate "JMicron PATA support"
depends on PCI
@@ -337,6 +346,15 @@ config PATA_MARVELL
If unsure, say N.
+config PATA_MPC52xx
+ tristate "Freescale MPC52xx SoC internal IDE"
+ depends on PPC_MPC52xx
+ help
+ This option enables support for integrated IDE controller
+ of the Freescale MPC52xx SoC.
+
+ If unsure, say N.
+
config PATA_MPIIX
tristate "Intel PATA MPIIX support"
depends on PCI
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index bc3d81a..a0df15d 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -33,11 +33,13 @@ obj-$(CONFIG_PATA_HPT3X2N) += pata_hpt3x2n.o
obj-$(CONFIG_PATA_HPT3X3) += pata_hpt3x3.o
obj-$(CONFIG_PATA_ISAPNP) += pata_isapnp.o
obj-$(CONFIG_PATA_IT821X) += pata_it821x.o
+obj-$(CONFIG_PATA_IT8213) += pata_it8213.o
obj-$(CONFIG_PATA_JMICRON) += pata_jmicron.o
obj-$(CONFIG_PATA_NETCELL) += pata_netcell.o
obj-$(CONFIG_PATA_NS87410) += pata_ns87410.o
obj-$(CONFIG_PATA_OPTI)+= pata_opti.o
obj-$(CONFIG_PATA_OPTIDMA) += pata_optidma.o
+obj-$(CONFIG_PATA_MPC52xx) += pata_mpc52xx.o
obj-$(CONFIG_PATA_MARVELL) += pata_marvell.o
obj-$(CONFIG_PATA_MPIIX) += pata_mpiix.o
obj-$(CONFIG_PATA_OLDPIIX) += pata_oldpiix.o
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index f36da48..dbae6d9 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -645,8 +645,6 @@ static int ahci_reset_controller(void __iomem *mmio, struct
pci_dev *pdev)
u32 cap_save, impl_save, tmp;
cap_save = readl(mmio + HOST_CAP);
- cap_save &= ( (1<<28) | (1<<17) );
- cap_save |= (1 << 27);
impl_save = readl(mmio + HOST_PORTS_IMPL);
/* global controller reset */
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index c7de0bb..7959e4c 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -226,14 +226,26 @@ static const struct pci_device_id piix_pci_tbl[] = {
{ 0x8086, 0x27c0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich6_sata_ahci },
/* 2801GBM/GHM (ICH7M, identical to ICH6M) */
{ 0x8086, 0x27c4, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich6m_sata_ahci },
- /* Enterprise Southbridge 2 (where's the datasheet?) */
+ /* Enterprise Southbridge 2 (631xESB/632xESB) */
{ 0x8086, 0x2680, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich6_sata_ahci },
- /* SATA Controller 1 IDE (ICH8, no datasheet yet) */
+ /* SATA Controller 1 IDE (ICH8) */
{ 0x8086, 0x2820, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
- /* SATA Controller 2 IDE (ICH8, ditto) */
+ /* SATA Controller 2 IDE (ICH8) */
{ 0x8086, 0x2825, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Friday, 15 December 2006 22:39, Andrew Morton wrote: > On Fri, 15 Dec 2006 13:05:52 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > Jeff, I shall send all the sata patches which I have at you one single time > > and I shall then drop the lot. So please don't flub them. > > > > I'll then do a rc1-mm2 without them. > > hm, this is looking like a lot of work for not much gain. Rafael, are > you able to do a quick chop and tell us whether these: > > pci-move-pci_vdevice-from-libata-to-core.patch > pata_cs5530-suspend-resume-support-tweak.patch > ata-fix-platform_device_register_simple-error-check.patch > initializer-entry-defined-twice-in-pata_rz1000.patch > pata_via-suspend-resume-support-fix.patch > sata_nv-add-suspend-resume-support.patch > libata-simulate-report-luns-for-atapi-devices.patch > user-of-the-jiffies-rounding-patch-ata-subsystem.patch > libata-fix-oops-with-sparsemem.patch > sata_nv-fix-kfree-ordering-in-remove.patch > libata-dont-initialize-sg-in-ata_exec_internal-if-dma_none-take-2.patch > pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch > > are innocent? Yes, they are. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
Alan wrote: On Fri, 15 Dec 2006 13:39:27 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: On Fri, 15 Dec 2006 13:05:52 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: Jeff, I shall send all the sata patches which I have at you one single time and I shall then drop the lot. So please don't flub them. I'll then do a rc1-mm2 without them. hm, this is looking like a lot of work for not much gain. Rafael, are you able to do a quick chop and tell us whether these: The md one and the long history of reports about parallel I/O causing problems sounds a lot more like the kmap stuff you were worried about Andrew. I'd be very intereste dto know if it happens on x86_32 built with a standard memory split and no highmem 2.6.20-rc1 works, and 2.6.20-rc1 does not have the kmap_atomic() fix. Upstream does kmap_atomic(KM_USER0) and -mm does kmap_atomic(KM_IRQ0) 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: Task watchers v2
On Fri, 2006-12-15 at 09:34 +0100, Christoph Hellwig wrote: > On Thu, Dec 14, 2006 at 04:07:55PM -0800, Matt Helsley wrote: > > Associate function calls with significant events in a task's lifetime much > > like > > we handle kernel and module init/exit functions. This creates a table for > > each > > of the following events in the task_watchers_table ELF section: > > > > WATCH_TASK_INIT at the beginning of a fork/clone system call when the > > new task struct first becomes available. > > > > WATCH_TASK_CLONE just before returning successfully from a fork/clone. > > > > WATCH_TASK_EXEC just before successfully returning from the exec > > system call. > > > > WATCH_TASK_UID every time a task's real or effective user id changes. > > > > WATCH_TASK_GID every time a task's real or effective group id changes. > > > > WATCH_TASK_EXIT at the beginning of do_exit when a task is exiting > > for any reason. > > > > WATCH_TASK_FREE is called before critical task structures like > > the mm_struct become inaccessible and the task is subsequently freed. > > > > The next patch will add a debugfs interface for measuring fork and exit > > rates > > which can be used to calculate the overhead of the task watcher > > infrastructure. > > What's the point of the ELF hackery? This code would be a lot simpler > and more understandable if you simply had task_watcher_ops and a > register / unregister function for it. Andrew asked me to avoid locking and added complexity in the code that uses one or more task watchers. The ELF hackery helps me avoid locking in the fork/exit/etc paths that call the "registered" function. Cheers, -Matt Helsley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 mmap hangs unrelated apps
On 2006/12/15 at 15:44:14 Trond Myklebust <[EMAIL PROTECTED]> wrote > On Fri, 2006-12-15 at 15:06 -0600, Michal Sabala wrote: > > Could this be related to the fact that the nfs mmaped file is unlinked > > before it is ummaped? The .nfsXXX file disappears from the NFS > > server as soon as test-mmap.c exits. > > That shouldn't normally matter. The file won't be deleted until after > the last user has stopped referencing it. However it is true that the > trace you sent indicated that XFree86 was hanging in iput(). > > > What nfs_debug information would be useful in tracking this > > problem? Is there any other information I can provide you? > > Could you just out of interest try 2.6.20-rc1? Trond, I'll try 2.6.20-rc1 on Monday and post results to the list. Thanks, Michal -- Michal "Saahbs" Sabala - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/v2] CodingStyle updates
On Dec 15 2006 21:27, Jörn Engel wrote: >On Fri, 15 December 2006 22:01:10 +0100, Jan Engelhardt wrote: >> On Dec 15 2006 15:56, Dmitry Torokhov wrote: >> > >> > outside the loop? If not then it is better to keep style consistent >> > and not use condensed form in loops either. >> >> Don't you all even think about leaving the whitespace away in the wrong >> place, otherwise the kernel is likely to become an entry for IOCCC. > >Please, this is not religion. No god has spoken "though shalt not...". > >In 99% of all cases, what Randy wrote is the best choice. But the Of course it is - hey, I even "contributed" to it. Well, looks like I should be adding in more smilies when making remarks like the above. >ultimate goal is not to follow his heavenly rules with fundamental >zealotry, the ultimate goal is to make the code readable. If you >happen to stumble on the 1% case where the code can be more readable by >not following the rules, and you are absolutely sure about that, then >don't. That simple. ;) I take it that people will automatically DTRT for obscure cases like shown before. Well, and if they don't, hopefully some reviewer catches things like 3*i + l<<2. It's all right, I did not mean to step on toes. -`J' --
Re: Binary Drivers
On Fri, Dec 15, 2006 at 09:20:58PM +, James Porter wrote: > I think some kernel developers take to much responsibility, is there a bug in > a > binary driver? Send it upstream and explain to the user that it's a closed > source driver and is up to said company to fix it. > > For what it's worth, I don't see any problem with binary drivers from hardware > manufacturers. Binary drivers from hardware manufacturers are crap. Learn it by heart. > Just because nvidia makes a closed source driver doesn't mean that we can't > also > create an open source driver(limited functionality, reverse engineered, > etc.,etc.). We can. > I firmly believe that the choice should be up to the user and/or > distro. I'm not a kernel dev, I don't know c... but you can't. > but I understand the concepts and > I should have the right to do what I want with this GPL code. You don't have a right to do what you want with GNU GPL'ed code. Read the fucking license, already. > Restricting me only frustrates me. Nobody is restricting you. > Should the default be open source, definitely; should binary > drivers be blocked from running on a linux kernel...certainly not. But users of binary drivers should be blocked from sending bug reports to kernel developers. > I personally like nvidia's products, they have spent a lot of money in R > One > example is SLI, if their spec was open what would stop ATI from stealing their > work(patents?, gotta love those). I lost a nice quote about 10-20% of the community stopping making excuses for vendors. Sad, sad, nice quote definitely. > Personally I think nvidia has excellent > support for linux, I have actually convinced people to use linux(desktop and > server) just by showing them beryl with the nvidia beta drivers. beryl on server? > Lastly I think it's ridiculous to create,diplay, and distribute "Free" as in > freedom and "Free" as in cost software only to later consider limiting my > freedom... Nobody is limiting you. > want to know why a lot of large companies don't support > linux...exactly threads like this. You asked them? > Why make the effort to use "Free" software > only to have the rug pulled out from under you. This is what makes the BSDs so > attractive. So use BSD. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Binary Drivers
On Dec 15 2006 21:59, Alan wrote: > >> I personally like nvidia's products, they have spent a lot of money in R >> One >> example is SLI, if their spec was open what would stop ATI from stealing >> their > >3DFx invented SLI many years ago. The SLI programming information for the >3DFx cards is public. Nvidia are a bit late to the party except on the PR >front. ...and there are enough people to take the PR. (Meaning they don't check if "SLI" existed before and hence reveal foul PR.) -`J' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Friday, 15 December 2006 23:06, Alan wrote: > On Fri, 15 Dec 2006 13:39:27 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Fri, 15 Dec 2006 13:05:52 -0800 > > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > Jeff, I shall send all the sata patches which I have at you one single > > > time > > > and I shall then drop the lot. So please don't flub them. > > > > > > I'll then do a rc1-mm2 without them. > > > > hm, this is looking like a lot of work for not much gain. Rafael, are > > you able to do a quick chop and tell us whether these: > > The md one and the long history of reports about parallel I/O causing > problems sounds a lot more like the kmap stuff you were worried about > Andrew. I'd be very intereste dto know if it happens on x86_32 built with > a standard memory split and no highmem But my box is a x86_64, so ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Fri, 15 Dec 2006 13:39:27 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Fri, 15 Dec 2006 13:05:52 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > Jeff, I shall send all the sata patches which I have at you one single time > > and I shall then drop the lot. So please don't flub them. > > > > I'll then do a rc1-mm2 without them. > > hm, this is looking like a lot of work for not much gain. Rafael, are > you able to do a quick chop and tell us whether these: The md one and the long history of reports about parallel I/O causing problems sounds a lot more like the kmap stuff you were worried about Andrew. I'd be very intereste dto know if it happens on x86_32 built with a standard memory split and no highmem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Friday, 15 December 2006 22:49, Jeff Garzik wrote: > Rafael J. Wysocki wrote: > > The other box is mine and it works just fine with 2.6.20-rc1. > > > >> I think something bad happened in sata land just recently. > > > > Yup. Please see, for example: > > > > http://marc.theaimsgroup.com/?l=linux-kernel=116621656432500=2 > > > > It looks like the breakage is in sata, in the patches that went in after > > 2.6.19-rc6-mm2 (that one worked for me like charm). > > > So 2.6.20-rc1 works for you? Yes. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
The "Re: Linux 2.6.20-rc1" sub-thread that had Jens and Alistair John Strachan replying seemed to implicate some core block layer badness. 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: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
Rafael J. Wysocki wrote: The other box is mine and it works just fine with 2.6.20-rc1. I think something bad happened in sata land just recently. Yup. Please see, for example: http://marc.theaimsgroup.com/?l=linux-kernel=116621656432500=2 It looks like the breakage is in sata, in the patches that went in after 2.6.19-rc6-mm2 (that one worked for me like charm). So 2.6.20-rc1 works for you? 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: Binary Drivers
> I personally like nvidia's products, they have spent a lot of money in R > One > example is SLI, if their spec was open what would stop ATI from stealing their 3DFx invented SLI many years ago. The SLI programming information for the 3DFx cards is public. Nvidia are a bit late to the party except on the PR front. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Friday, 15 December 2006 22:39, Andrew Morton wrote: > On Fri, 15 Dec 2006 13:05:52 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > Jeff, I shall send all the sata patches which I have at you one single time > > and I shall then drop the lot. So please don't flub them. > > > > I'll then do a rc1-mm2 without them. > > hm, this is looking like a lot of work for not much gain. Rafael, are > you able to do a quick chop and tell us whether these: > > pci-move-pci_vdevice-from-libata-to-core.patch > pata_cs5530-suspend-resume-support-tweak.patch > ata-fix-platform_device_register_simple-error-check.patch > initializer-entry-defined-twice-in-pata_rz1000.patch > pata_via-suspend-resume-support-fix.patch > sata_nv-add-suspend-resume-support.patch > libata-simulate-report-luns-for-atapi-devices.patch > user-of-the-jiffies-rounding-patch-ata-subsystem.patch > libata-fix-oops-with-sparsemem.patch > sata_nv-fix-kfree-ordering-in-remove.patch > libata-dont-initialize-sg-in-ata_exec_internal-if-dma_none-take-2.patch > pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch > > are innocent? Will do in a while and report back. Stay tuned. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 mmap hangs unrelated apps
On Fri, 2006-12-15 at 15:06 -0600, Michal Sabala wrote: > On 2006/12/15 at 13:44:44 Trond Myklebust <[EMAIL PROTECTED]> wrote > > On Fri, 2006-12-15 at 11:50 -0600, Michal Sabala wrote: > > > On 2006/12/15 at 10:24:15 Trond Myklebust <[EMAIL PROTECTED]> wrote > > > > On Thu, 2006-12-14 at 20:30 -0600, Michal Sabala wrote: > > > > > > > > > > `cat /proc/*PID*/wchan` for all hanging processes contains page_sync. > > > > > > > > Have you tried an 'echo t >/proc/sysrq-trigger' on a client with one of > > > > these hanging processes? If so, what does the output look like? > > > > > > Hello Trond, > > > > > > Below is the sysrq trace output for XFree86 which entered the > > > uninterruptible sleep state on the P4 machine with nfs /home. Please > > > note that XFree86 does not have any files open in /home - as reported by > > > `lsof`. Below, I also listed the output of vmstat. > > > > > > It is hanging because it is trying to free up memory by reclaiming pages > > that are held by your mmaped file on NFS. Do you know why NFS is > > hanging? > > Trond, > > I do not have any indication that it is the server not responding. Other > applications which have NFS files open are continuing to work while in > this case XFree86 blocks. > > Also, please note that test-mmap.c has successfully finished execution > and it is no longer running while XFree86 is still hanging. > > Could this be related to the fact that the nfs mmaped file is unlinked > before it is ummaped? The .nfsXXX file disappears from the NFS > server as soon as test-mmap.c exits. That shouldn't normally matter. The file won't be deleted until after the last user has stopped referencing it. However it is true that the trace you sent indicated that XFree86 was hanging in iput(). > What nfs_debug information would be useful in tracking this > problem? Is there any other information I can provide you? Could you just out of interest try 2.6.20-rc1? Cheers Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 mmap hangs unrelated apps
On 2006/12/15 at 15:12:06 Arjan van de Ven <[EMAIL PROTECTED]> wrote > > > > > I do not have any indication that it is the server not responding. Other > > applications which have NFS files open are continuing to work while in > > this case XFree86 blocks. > > just a strange question, but which video driver do you use in X? maybe > that one is blocking say the pci bus or something... Arjan, The P3 box with nfs root uses the "ati" X11 driver with: :01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64) The P4 box with nfs /home uses the "i810" X11 driver with: :00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics Device (rev 02) Thanks, Michal -- Michal "Saahbs" Sabala - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 mmap hangs unrelated apps
On Fri, 15 Dec 2006 15:35:00 -0600 Michal Sabala <[EMAIL PROTECTED]> wrote: > On 2006/12/15 at 14:42:08 Andrew Morton <[EMAIL PROTECTED]> wrote > > On Fri, 15 Dec 2006 11:50:30 -0600 > > Michal Sabala <[EMAIL PROTECTED]> wrote: > > > > > On 2006/12/15 at 10:24:15 Trond Myklebust <[EMAIL PROTECTED]> wrote > > > > On Thu, 2006-12-14 at 20:30 -0600, Michal Sabala wrote: > > > > > > > > > > `cat /proc/*PID*/wchan` for all hanging processes contains page_sync. > > > > > > > > Have you tried an 'echo t >/proc/sysrq-trigger' on a client with one of > > > > these hanging processes? If so, what does the output look like? > > > > > > Hello Trond, > > > > > > Below is the sysrq trace output for XFree86 which entered the > > > uninterruptible sleep state on the P4 machine with nfs /home. Please > > > note that XFree86 does not have any files open in /home - as reported by > > > `lsof`. Below, I also listed the output of vmstat. > > > > We'd need to see the trace of all D-state processes, please. Xfree86 might > > just be a victim of a deadlock elsewhere. However there is a problem here.. > > Hi Andrew, > > In most cases only a single process enters the D-state, this time it was > XFree, but I've seen gimp, firefox, gconfd and bash. Once or twice I did > see two or three processes ending up in uninterruptible sleep, but I > suspect they entered this state at different test-mmap.c runs (I left > test-mmap.c running in a bash loop and checked the system after a few > hours). OK, useful info, thanks. > Would it be beneficial to keep running test-mmap.c on this machine until > two or more processes end up in D-state? I can leave this machine > running test-mmap.c over the weekend. No, that's OK. The next step should be for a kernel wrangler to get in there with your testcase. It could well be that lock_page-inside-lock_page thing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Fri, 15 Dec 2006 13:05:52 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > Jeff, I shall send all the sata patches which I have at you one single time > and I shall then drop the lot. So please don't flub them. > > I'll then do a rc1-mm2 without them. hm, this is looking like a lot of work for not much gain. Rafael, are you able to do a quick chop and tell us whether these: pci-move-pci_vdevice-from-libata-to-core.patch pata_cs5530-suspend-resume-support-tweak.patch ata-fix-platform_device_register_simple-error-check.patch initializer-entry-defined-twice-in-pata_rz1000.patch pata_via-suspend-resume-support-fix.patch sata_nv-add-suspend-resume-support.patch libata-simulate-report-luns-for-atapi-devices.patch user-of-the-jiffies-rounding-patch-ata-subsystem.patch libata-fix-oops-with-sparsemem.patch sata_nv-fix-kfree-ordering-in-remove.patch libata-dont-initialize-sg-in-ata_exec_internal-if-dma_none-take-2.patch pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch are innocent? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.18.5 usb/sysfs bug.
On Fri, Dec 15, 2006 at 09:53:44AM -0800, Greg Kroah-Hartman wrote: > On Fri, Dec 15, 2006 at 12:50:27PM -0500, Dave Jones wrote: > > Happens during every boot, though bootup continues afterwards. > > Can you enable CONFIG_USB_DEBUG and send the log info that happens right > before this oops? Gah, and here it is, actually attached this time. Dave Linux version 2.6.18-1.2864.fc6 ([EMAIL PROTECTED]) (gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)) #1 SMP Fri Dec 15 13:14:58 EST 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 0010 - 3fe91400 (usable) BIOS-e820: 3fe91400 - 4000 (reserved) BIOS-e820: e000 - f0007000 (reserved) BIOS-e820: f0008000 - f000c000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fed2 - feda (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 126MB HIGHMEM available. 896MB LOWMEM available. Using x86 segment limits to approximate NX protection On node 0 totalpages: 261777 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 32401 pages, LIFO batch:7 DMI 2.4 present. Using APIC driver default ACPI: RSDP (v000 DELL ) @ 0x000fc370 ACPI: RSDT (v001 DELLM07 0x27d60317 ASL 0x0061) @ 0x3fe91a11 ACPI: FADT (v001 DELLM07 0x27d60317 ASL 0x0061) @ 0x3fe92800 ACPI: MADT (v001 DELLM07 0x27d60317 ASL 0x0047) @ 0x3fe93000 ACPI: ASF! (v016 DELLM07 0x27d60317 ASL 0x0061) @ 0x3fe92c00 ACPI: MCFG (v016 DELLM07 0x27d60317 ASL 0x0061) @ 0x3fe92fc0 ACPI: SSDT (v001 PmRefCpuPm 0x3000 INTL 0x20050624) @ 0x3fe91a8c ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 INTL 0x20050624) @ 0x ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:14 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 6:14 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 5000 (gap: 4000:a000) Detected 2161.304 MHz processor. Built 1 zonelists. Total pages: 261777 Kernel command line: ro root=/dev/VolGroup00/LogVol00 profile=1 vga=791 kernel profiling enabled (shift: 1) mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c07b1000 soft=c0791000 PID hash table entries: 4096 (order: 12, 16384 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1026368k/1047108k available (2147k kernel code, 19968k reserved, 870k data, 240k init, 129604k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4325.48 BogoMIPS (lpj=2162744) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfe9fbff 0010 c1a9 CPU: After vendor identify, caps: bfe9fbff 0010 c1a9 monitor/mwait feature present. using mwait in idle threads. CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 2048K CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 CPU: After all inits, caps: bfe9f3ff 0010 0940 c1a9 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code ACPI: Core revision 20060707 CPU0: Intel Genuine Intel(R) CPU T2600 @ 2.16GHz stepping 08 SMP alternatives: switching to SMP code Booting processor 1/1 eip 3000 CPU 1 irqstacks, hard=c07b2000 soft=c0792000 Initializing CPU#1 Calibrating delay using timer specific routine.. 4321.95 BogoMIPS (lpj=2160979) CPU: After generic identify, caps: bfe9fbff 0010
Re: 2.6.18.5 usb/sysfs bug.
On Fri, Dec 15, 2006 at 09:53:44AM -0800, Greg Kroah-Hartman wrote: > On Fri, Dec 15, 2006 at 12:50:27PM -0500, Dave Jones wrote: > > Happens during every boot, though bootup continues afterwards. > > Can you enable CONFIG_USB_DEBUG and send the log info that happens right > before this oops? It doesn't seem much more enlightening to me, but full dmesg below. > > I'll give .20rc1 a shot real soon. > 2.6.19 would be interesting to try too. I'll be worried if it's not > fixed there. Ok, I'll do that first. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 mmap hangs unrelated apps
On 2006/12/15 at 14:42:08 Andrew Morton <[EMAIL PROTECTED]> wrote > On Fri, 15 Dec 2006 11:50:30 -0600 > Michal Sabala <[EMAIL PROTECTED]> wrote: > > > On 2006/12/15 at 10:24:15 Trond Myklebust <[EMAIL PROTECTED]> wrote > > > On Thu, 2006-12-14 at 20:30 -0600, Michal Sabala wrote: > > > > > > > > `cat /proc/*PID*/wchan` for all hanging processes contains page_sync. > > > > > > Have you tried an 'echo t >/proc/sysrq-trigger' on a client with one of > > > these hanging processes? If so, what does the output look like? > > > > Hello Trond, > > > > Below is the sysrq trace output for XFree86 which entered the > > uninterruptible sleep state on the P4 machine with nfs /home. Please > > note that XFree86 does not have any files open in /home - as reported by > > `lsof`. Below, I also listed the output of vmstat. > > We'd need to see the trace of all D-state processes, please. Xfree86 might > just be a victim of a deadlock elsewhere. However there is a problem here.. Hi Andrew, In most cases only a single process enters the D-state, this time it was XFree, but I've seen gimp, firefox, gconfd and bash. Once or twice I did see two or three processes ending up in uninterruptible sleep, but I suspect they entered this state at different test-mmap.c runs (I left test-mmap.c running in a bash loop and checked the system after a few hours). Would it be beneficial to keep running test-mmap.c on this machine until two or more processes end up in D-state? I can leave this machine running test-mmap.c over the weekend. Please advise, Sincerely, Michal -- Michal "Saahbs" Sabala - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/v2] CodingStyle updates
On Fri, 15 December 2006 22:01:10 +0100, Jan Engelhardt wrote: > On Dec 15 2006 15:56, Dmitry Torokhov wrote: > > > > Would you write: > > > > i+=2; > > > > outside the loop? If not then it is better to keep style consistent > > and not use condensed form in loops either. > > Don't you all even think about leaving the whitespace away in the wrong > place, otherwise the kernel is likely to become an entry for IOCCC. Please, this is not religion. No god has spoken "though shalt not...". In 99% of all cases, what Randy wrote is the best choice. But the ultimate goal is not to follow his heavenly rules with fundamental zealotry, the ultimate goal is to make the code readable. If you happen to stumble on the 1% case where the code can be more readable by not following the rules, and you are absolutely sure about that, then don't. That simple. ;) That said, people who are bereft of all common sense have my blessing to follow the rules literally in their own code. Just don't stomp over mine with pitchforks and torches, ok? Jörn -- I can say that I spend most of my time fixing bugs even if I have lots of new features to implement in mind, but I give bugs more priority. -- Andrea Arcangeli, 2000 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Binary Drivers
I think some kernel developers take to much responsibility, is there a bug in a binary driver? Send it upstream and explain to the user that it's a closed source driver and is up to said company to fix it. For what it's worth, I don't see any problem with binary drivers from hardware manufacturers. Just because nvidia makes a closed source driver doesn't mean that we can't also create an open source driver(limited functionality, reverse engineered, etc.,etc.). I firmly believe that the choice should be up to the user and/or distro. I'm not a kernel dev, I don't know c...but I understand the concepts and I should have the right to do what I want with this GPL code. Restricting me only frustrates me. Should the default be open source, definitely; should binary drivers be blocked from running on a linux kernel...certainly not. I personally like nvidia's products, they have spent a lot of money in R One example is SLI, if their spec was open what would stop ATI from stealing their work(patents?, gotta love those). Personally I think nvidia has excellent support for linux, I have actually convinced people to use linux(desktop and server) just by showing them beryl with the nvidia beta drivers. Lastly I think it's ridiculous to create,diplay, and distribute "Free" as in freedom and "Free" as in cost software only to later consider limiting my freedom...want to know why a lot of large companies don't support linux...exactly threads like this. Why make the effort to use "Free" software only to have the rug pulled out from under you. This is what makes the BSDs so attractive. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/v2] CodingStyle updates
Jörn Engel wrote: On Fri, 15 December 2006 21:10:14 +, Jörn Engel wrote: Like so? I manually edited the patch and weakened a few of the space rules, basically the ones in dispute in this thread. Btw, this doesn't apply to my git tree at all (just pulled): Hunk #1 FAILED at 35. Hunk #2 FAILED at 94. Hunk #3 succeeded at 145 with fuzz 1 (offset 39 lines). Hunk #4 succeeded at 242 with fuzz 2 (offset 82 lines). Hunk #5 FAILED at 315. Hunk #6 succeeded at 435 with fuzz 2 (offset 96 lines). Hunk #7 FAILED at 497. Hunk #8 FAILED at 802. 5 out of 8 hunks FAILED -- saving rejects to file Documentation/CodingStyle.rej Is it against -mm or something such? It's already been merged, so you'll need to make new patches against -current (as always). -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] cciss: fix XFER_READ/XFER_WRITE in do_cciss_request
Patch 2 of 2 This patch fixes a stupid bug. Sometime during the 2tb enhancement I ended up replacing the macros XFER_READ and XFER_WRITE with h->cciss_read and h->cciss_write respectively. It seemed to work somehow at least on x86_64 and ia64. I don't know how. But people started complaining about command timeouts on older controllers like the 64xx series and only on ia32. This resolves the issue reproduced in our lab. Please consider this for inclusion. Thanks, mikem Signed-off-by: Mike Miller <[EMAIL PROTECTED]> drivers/block/cciss.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/block/cciss.c~cciss_xfer_fix drivers/block/cciss.c --- linux-2.6-work/drivers/block/cciss.c~cciss_xfer_fix 2006-12-15 08:56:40.0 -0600 +++ linux-2.6-work-mikem/drivers/block/cciss.c 2006-12-15 08:58:20.0 -0600 @@ -2492,7 +2492,7 @@ static void do_cciss_request(request_que c->Request.Type.Type = TYPE_CMD;// It is a command. c->Request.Type.Attribute = ATTR_SIMPLE; c->Request.Type.Direction = - (rq_data_dir(creq) == READ) ? h->cciss_read : h->cciss_write; + (rq_data_dir(creq) == READ) ? XFER_READ : XFER_WRITE; c->Request.Timeout = 0; // Don't time out c->Request.CDB[0] = (rq_data_dir(creq) == READ) ? h->cciss_read : h->cciss_write; _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [S390] Fix reboot hang on LPARs
> +static int pgm_check_occured;
> +
> +static void cio_reset_pgm_check_handler(void)
> +{
> + pgm_check_occured = 1;
> +}
> +
> +static int stsch_reset(struct subchannel_id schid, volatile struct schib
> *addr)
> +{
> + int rc;
> +
> + pgm_check_occured = 0;
> + s390_reset_pgm_handler = cio_reset_pgm_check_handler;
> + rc = stsch(schid, addr);
> + s390_reset_pgm_handler = NULL;
> + if (pgm_check_occured)
> + return -EIO;
> + else
> + return rc;
> +}
This is broken. pgm_check_occured must be volatile, otherwise the -EIO path
in stsch_reset might get optimized away.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
I don't think it's in -rc1, please see below. On Friday, 15 December 2006 21:50, Neil Brown wrote: > On Friday December 15, [EMAIL PROTECTED] wrote: > > From: Neil Brown <[EMAIL PROTECTED]> > > Date: Wed, Dec 06, 2006 at 06:20:57PM +1100 > > > i.e. current -mm is good for 2.6.20 (though I have a few other little > > > things I'll be sending in soon, they aren't related to the raid6 > > > problem). > > > > > 2.6.20-rc1-mm1 doesn't boot on my box, due to the fact that e2fsck gives > > > > Buffer I/O error on device /dev/md0, logical block 0 > > > > But before that > > raid5: device sdh1 operational as raid disk 1 > > raid5: device sdg1 operational as raid disk 0 > > raid5: device sdf1 operational as raid disk 5 > > raid5: device sde1 operational as raid disk 6 > > raid5: device sdd1 operational as raid disk 7 > > raid5: device sdc1 operational as raid disk 3 > > raid5: device sdb1 operational as raid disk 2 > > raid5: device sda1 operational as raid disk 4 > > raid5: allocated 8462kB for md0 > > raid5: raid level 6 set md0 active with 8 out of 8 devices, algorithm 2 > > RAID5 conf printout: > > --- rd:8 wd:8 > > disk 0, o:1, dev:sdg1 > > disk 1, o:1, dev:sdh1 > > disk 2, o:1, dev:sdb1 > > disk 3, o:1, dev:sdc1 > > disk 4, o:1, dev:sda1 > > disk 5, o:1, dev:sdf1 > > disk 6, o:1, dev:sde1 > > disk 7, o:1, dev:sdd1 > > md0: bitmap initialized from disk: read 15/15 pages, set 1 bits, status: 0 > > created bitmap (233 pages) for device md0 > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sde1, disabling device. Operation continuing on 7 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdg1, disabling device. Operation continuing on 6 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdf1, disabling device. Operation continuing on 5 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdc1, disabling device. Operation continuing on 4 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdb1, disabling device. Operation continuing on 3 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdh1, disabling device. Operation continuing on 2 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdd1, disabling device. Operation continuing on 1 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sda1, disabling device. Operation continuing on 0 > > devices > > Oh dear, that array isn't much good any more.! > That is the second report I have had of this with sata drives. This > was raid456, the other was raid1. Two different sata drivers are > involved (sata_nv in this case, sata_uli in the other case). The other box is mine and it works just fine with 2.6.20-rc1. > I think something bad happened in sata land just recently. Yup. Please see, for example: http://marc.theaimsgroup.com/?l=linux-kernel=116621656432500=2 It looks like the breakage is in sata, in the patches that went in after 2.6.19-rc6-mm2 (that one worked for me like charm). Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/v2] CodingStyle updates
On Fri, 15 December 2006 12:26:59 -0800, Randy Dunlap wrote:
>
> then send patches :)
Like so? I manually edited the patch and weakened a few of the space
rules, basically the ones in dispute in this thread.
From: Randy Dunlap <[EMAIL PROTECTED]>
Add some kernel coding style comments, mostly pulled from emails
by Andrew Morton, Jesper Juhl, and Randy Dunlap.
- add paragraph on switch/case indentation (with fixes)
- add paragraph on multiple-assignments
- add more on Braces
- add section on Spaces; add typeof, alignof, & __attribute__ with sizeof;
add more on postfix/prefix increment/decrement operators
- add paragraph on function breaks in source files; add info on
function prototype parameter names
- add paragraph on EXPORT_SYMBOL placement
- add section on /*-comment style, long-comment style, and data
declarations and comments
- correct some chapter number references that were missed when
chapters were renumbered
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Acked-by: Jesper Juhl <[EMAIL PROTECTED]>
Acked-by: Jörn Engel <[EMAIL PROTECTED]>
---
Documentation/CodingStyle | 129 --
1 file changed, 124 insertions(+), 5 deletions(-)
--- linux-2.6.19-git11.orig/Documentation/CodingStyle
+++ linux-2.6.19-git11/Documentation/CodingStyle
@@ -35,12 +35,37 @@ In short, 8-char indents make things eas
benefit of warning you when you're nesting your functions too deep.
Heed that warning.
+The preferred way to ease multiple indentation levels in a switch
+statement is to align the "switch" and its subordinate "case" labels in
+the same column instead of "double-indenting" the "case" labels. E.g.:
+
+ switch (suffix) {
+ case 'G':
+ case 'g':
+ mem <<= 30;
+ break;
+ case 'M':
+ case 'm':
+ mem <<= 20;
+ break;
+ case 'K':
+ case 'k':
+ mem <<= 10;
+ /* fall through */
+ default:
+ break;
+ }
+
+
Don't put multiple statements on a single line unless you have
something to hide:
if (condition) do_this;
do_something_everytime;
+Don't put multiple assignments on a single line either. Kernel
+coding style is super simple. Avoid tricky expressions.
+
Outside of comments, documentation and except in Kconfig, spaces are never
used for indentation, and the above example is deliberately broken.
@@ -69,7 +94,7 @@ void fun(int a, int b, int c)
next_statement;
}
- Chapter 3: Placing Braces
+ Chapter 3: Placing Braces and Spaces
The other issue that always comes up in C styling is the placement of
braces. Unlike the indent size, there are few technical reasons to
@@ -81,6 +106,20 @@ brace last on the line, and put the clos
we do y
}
+This applies to all non-function statement blocks (if, switch, for,
+while, do). E.g.:
+
+ switch (action) {
+ case KOBJ_ADD:
+ return "add";
+ case KOBJ_REMOVE:
+ return "remove";
+ case KOBJ_CHANGE:
+ return "change";
+ default:
+ return NULL;
+ }
+
However, there is one special case, namely functions: they have the
opening brace at the beginning of the next line, thus:
@@ -121,6 +160,52 @@ supply of new-lines on your screen is no
25-line terminal screens here), you have more empty lines to put
comments on.
+ 3.1: Spaces
+
+Linux kernel style for use of spaces depends (mostly) on
+function-versus-keyword usage. Use a space after (most) keywords. The
+notable exceptions are sizeof, typeof, alignof, and __attribute__, which
+look somewhat like functions (and are usually used with parentheses in
+Linux, although they are not required in the language, as in: "sizeof info"
+after "struct fileinfo info;" is declared).
+
+So use a space after these keywords:
+ if, switch, case, for, do, while
+but not with sizeof, typeof, alignof, or __attribute__. E.g.,
+ s = sizeof(struct file);
+
+Do not add spaces around (inside) parenthesized expressions.
+This example is *bad*:
+
+ s = sizeof( struct file );
+
+When declaring pointer data or a function that returns a pointer type,
+the preferred use of '*' is adjacent to the data name or function name
+and not adjacent to the type name. Examples:
+
+ char *linux_banner;
+ unsigned long long memparse(char *ptr, char **retptr);
+ char *match_strdup(substring_t *s);
+
+When placing spaces around operators, try to make the code as readable
+as possible. While readability is a highly personal matter, the
+following rules are a good starting point (and _not_ the ultimate
+wisdom in all cases, mind you ;):
+Tend to use one space around (on each side of) most binary and ternary
+operators, such as any of these:
+ = + - < > * / % | & ^ <= >= == != ? :
+
+avoid spaces after
Re: [PATCH/v2] CodingStyle updates
On Fri, 15 December 2006 21:10:14 +, Jörn Engel wrote: > > Like so? I manually edited the patch and weakened a few of the space > rules, basically the ones in dispute in this thread. Btw, this doesn't apply to my git tree at all (just pulled): Hunk #1 FAILED at 35. Hunk #2 FAILED at 94. Hunk #3 succeeded at 145 with fuzz 1 (offset 39 lines). Hunk #4 succeeded at 242 with fuzz 2 (offset 82 lines). Hunk #5 FAILED at 315. Hunk #6 succeeded at 435 with fuzz 2 (offset 96 lines). Hunk #7 FAILED at 497. Hunk #8 FAILED at 802. 5 out of 8 hunks FAILED -- saving rejects to file Documentation/CodingStyle.rej Is it against -mm or something such? Jörn -- When in doubt, punt. When somebody actually complains, go back and fix it... The 90% solution is a good thing. -- Rob Landley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))
On Fri, Dec 15, 2006 at 10:03:29PM +0100, Lennert Buytenhek wrote: > On Fri, Dec 15, 2006 at 09:15:22PM +0100, Francois Romieu wrote: > > > > Is there a way we can have this done by default on the n2100? I guess > > > that since it's a PCI device, there isn't much hope for that..? > > > > Do you mean an automagically tuned default value based on CONFIG_ARM ? > > No, that wouldn't make sense, that's like making a workaround depend on > arch == i386. > > I'm thinking that we should somehow enable this option on the n2100 > built-in r8169 ports by default only. Since the n2100 also has a mini-PCI > slot, and it is in theory possible to put an r8169 on a mini-PCI card, > the workaround probably shouldn't apply to those, so testing for > CONFIG_MACH_N2100 also isn't the right thing to do. There is dev->broken_parity_status ... although exactly what the sematics of that flag actually are seems to be rather vague - there's code which sets it for the Mellanox Tavor device, but it seems to only be exposed via sysfs - no code in drivers/pci seems to take any action based upon this flag being set. That rather raises the question about the usefulness of that quirk. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Friday, 15 December 2006 22:05, Andrew Morton wrote: > On Sat, 16 Dec 2006 07:50:01 +1100 > Neil Brown <[EMAIL PROTECTED]> wrote: > > > On Friday December 15, [EMAIL PROTECTED] wrote: > > > From: Neil Brown <[EMAIL PROTECTED]> > > > Date: Wed, Dec 06, 2006 at 06:20:57PM +1100 > > > > i.e. current -mm is good for 2.6.20 (though I have a few other little > > > > things I'll be sending in soon, they aren't related to the raid6 > > > > problem). > > > > > > > 2.6.20-rc1-mm1 doesn't boot on my box, due to the fact that e2fsck gives > > > > > > Buffer I/O error on device /dev/md0, logical block 0 > > > > > > > But before that > > > raid5: device sdh1 operational as raid disk 1 > > > raid5: device sdg1 operational as raid disk 0 > > > raid5: device sdf1 operational as raid disk 5 > > > raid5: device sde1 operational as raid disk 6 > > > raid5: device sdd1 operational as raid disk 7 > > > raid5: device sdc1 operational as raid disk 3 > > > raid5: device sdb1 operational as raid disk 2 > > > raid5: device sda1 operational as raid disk 4 > > > raid5: allocated 8462kB for md0 > > > raid5: raid level 6 set md0 active with 8 out of 8 devices, algorithm 2 > > > RAID5 conf printout: > > > --- rd:8 wd:8 > > > disk 0, o:1, dev:sdg1 > > > disk 1, o:1, dev:sdh1 > > > disk 2, o:1, dev:sdb1 > > > disk 3, o:1, dev:sdc1 > > > disk 4, o:1, dev:sda1 > > > disk 5, o:1, dev:sdf1 > > > disk 6, o:1, dev:sde1 > > > disk 7, o:1, dev:sdd1 > > > md0: bitmap initialized from disk: read 15/15 pages, set 1 bits, status: 0 > > > created bitmap (233 pages) for device md0 > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sde1, disabling device. Operation continuing on 7 > > > devices > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sdg1, disabling device. Operation continuing on 6 > > > devices > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sdf1, disabling device. Operation continuing on 5 > > > devices > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sdc1, disabling device. Operation continuing on 4 > > > devices > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sdb1, disabling device. Operation continuing on 3 > > > devices > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sdh1, disabling device. Operation continuing on 2 > > > devices > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sdd1, disabling device. Operation continuing on 1 > > > devices > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sda1, disabling device. Operation continuing on 0 > > > devices > > > > Oh dear, that array isn't much good any more.! > > That is the second report I have had of this with sata drives. This > > was raid456, the other was raid1. Two different sata drivers are > > involved (sata_nv in this case, sata_uli in the other case). > > I think something bad happened in sata land just recently. > > The device driver is returning -EIO for a write without printing any > > messages. > > > > OK, this is bad. The wheels do appear to have fallen off sata in rc1-mm1. I think it's happened in 2.6.19-mm1 already, since that kernel breaks md RAID1 on my box (the sata_uli case above). Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 mmap hangs unrelated apps
> > I do not have any indication that it is the server not responding. Other > applications which have NFS files open are continuing to work while in > this case XFree86 blocks. just a strange question, but which video driver do you use in X? maybe that one is blocking say the pci bus or something... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 mmap hangs unrelated apps
On 2006/12/15 at 13:44:44 Trond Myklebust <[EMAIL PROTECTED]> wrote > On Fri, 2006-12-15 at 11:50 -0600, Michal Sabala wrote: > > On 2006/12/15 at 10:24:15 Trond Myklebust <[EMAIL PROTECTED]> wrote > > > On Thu, 2006-12-14 at 20:30 -0600, Michal Sabala wrote: > > > > > > > > `cat /proc/*PID*/wchan` for all hanging processes contains page_sync. > > > > > > Have you tried an 'echo t >/proc/sysrq-trigger' on a client with one of > > > these hanging processes? If so, what does the output look like? > > > > Hello Trond, > > > > Below is the sysrq trace output for XFree86 which entered the > > uninterruptible sleep state on the P4 machine with nfs /home. Please > > note that XFree86 does not have any files open in /home - as reported by > > `lsof`. Below, I also listed the output of vmstat. > > > It is hanging because it is trying to free up memory by reclaiming pages > that are held by your mmaped file on NFS. Do you know why NFS is > hanging? Trond, I do not have any indication that it is the server not responding. Other applications which have NFS files open are continuing to work while in this case XFree86 blocks. Also, please note that test-mmap.c has successfully finished execution and it is no longer running while XFree86 is still hanging. Could this be related to the fact that the nfs mmaped file is unlinked before it is ummaped? The .nfsXXX file disappears from the NFS server as soon as test-mmap.c exits. What nfs_debug information would be useful in tracking this problem? Is there any other information I can provide you? Thank You, Sincerely, Michal -- Michal "Saahbs" Sabala - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] cciss: set default raid level when reading geometry fails
PATCH 1 of 2
This patch sets a default raid level on a volume that either does not support
reading the geometry or reports an invalid geometry for whatever reason. We
were always setting some values for heads and sectors but never set a raid
level. This caused lots of problems on some buggy firmware. Please consider
this for inclusion.
Thanks,
mikem
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
drivers/block/cciss.c |1 +
1 files changed, 1 insertion(+)
diff -puN drivers/block/cciss.c~cciss_set_default_raidlevel
drivers/block/cciss.c
--- linux-2.6-work/drivers/block/cciss.c~cciss_set_default_raidlevel
2006-12-13 11:04:39.0 -0600
+++ linux-2.6-work-mikem/drivers/block/cciss.c 2006-12-13 11:05:06.0
-0600
@@ -1907,6 +1907,7 @@ static void cciss_geometry_inquiry(int c
"does not support reading geometry\n");
drv->heads = 255;
drv->sectors = 32; // Sectors per track
+ drv->raid_level = RAID_UNKNOWN;
} else {
drv->heads = inq_buff->data_byte[6];
drv->sectors = inq_buff->data_byte[7];
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/v2] CodingStyle updates
On Dec 15 2006 15:56, Dmitry Torokhov wrote: > On 12/15/06, Jörn Engel <[EMAIL PROTECTED]> wrote: >> On Fri, 15 December 2006 09:00:37 -0800, Randy Dunlap wrote: >> > On Fri, 15 Dec 2006 16:07:17 +0100 Pavel Machek wrote: >> > >> > > Not in simple cases. >> > > >> > > 3*i + 2*j should be writen like that. Not like >> > > (3 * i) + (2 * j) >> > >> > I would just write it as: >> > 3 * i + 2 * j >> >> So would I. But I definitely wouldn't write >> for (i = 0; i < 10; i += 2) >> because I prefer the grouping in >> for (i=0; i<10; i+=2) >> > > Would you write: > > i+=2; > > outside the loop? If not then it is better to keep style consistent > and not use condensed form in loops either. Don't you all even think about leaving the whitespace away in the wrong place, otherwise the kernel is likely to become an entry for IOCCC. -`J' --
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Sat, 16 Dec 2006 07:50:01 +1100 Neil Brown <[EMAIL PROTECTED]> wrote: > On Friday December 15, [EMAIL PROTECTED] wrote: > > From: Neil Brown <[EMAIL PROTECTED]> > > Date: Wed, Dec 06, 2006 at 06:20:57PM +1100 > > > i.e. current -mm is good for 2.6.20 (though I have a few other little > > > things I'll be sending in soon, they aren't related to the raid6 > > > problem). > > > > > 2.6.20-rc1-mm1 doesn't boot on my box, due to the fact that e2fsck gives > > > > Buffer I/O error on device /dev/md0, logical block 0 > > > > But before that > > raid5: device sdh1 operational as raid disk 1 > > raid5: device sdg1 operational as raid disk 0 > > raid5: device sdf1 operational as raid disk 5 > > raid5: device sde1 operational as raid disk 6 > > raid5: device sdd1 operational as raid disk 7 > > raid5: device sdc1 operational as raid disk 3 > > raid5: device sdb1 operational as raid disk 2 > > raid5: device sda1 operational as raid disk 4 > > raid5: allocated 8462kB for md0 > > raid5: raid level 6 set md0 active with 8 out of 8 devices, algorithm 2 > > RAID5 conf printout: > > --- rd:8 wd:8 > > disk 0, o:1, dev:sdg1 > > disk 1, o:1, dev:sdh1 > > disk 2, o:1, dev:sdb1 > > disk 3, o:1, dev:sdc1 > > disk 4, o:1, dev:sda1 > > disk 5, o:1, dev:sdf1 > > disk 6, o:1, dev:sde1 > > disk 7, o:1, dev:sdd1 > > md0: bitmap initialized from disk: read 15/15 pages, set 1 bits, status: 0 > > created bitmap (233 pages) for device md0 > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sde1, disabling device. Operation continuing on 7 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdg1, disabling device. Operation continuing on 6 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdf1, disabling device. Operation continuing on 5 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdc1, disabling device. Operation continuing on 4 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdb1, disabling device. Operation continuing on 3 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdh1, disabling device. Operation continuing on 2 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdd1, disabling device. Operation continuing on 1 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sda1, disabling device. Operation continuing on 0 > > devices > > Oh dear, that array isn't much good any more.! > That is the second report I have had of this with sata drives. This > was raid456, the other was raid1. Two different sata drivers are > involved (sata_nv in this case, sata_uli in the other case). > I think something bad happened in sata land just recently. > The device driver is returning -EIO for a write without printing any messages. > OK, this is bad. The wheels do appear to have fallen off sata in rc1-mm1. Jeff, I shall send all the sata patches which I have at you one single time and I shall then drop the lot. So please don't flub them. I'll then do a rc1-mm2 without them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-rc1-mm1
On Fri, 15 Dec 2006 21:39:36 +0100 Damien Wyart <[EMAIL PROTECTED]> wrote: > With this new kernel, I notice two messages I do not have with > 2.6.19-rc6-mm2 : > > Dec 15 20:00:47 brouette kernel: Filesystem "sdb9": Disabling barriers,trial > barrier write failed > Dec 15 20:00:47 brouette kernel: Filesystem "sda5": Disabling barriers,trial > barrier write failed > > Nothing changed in the config between the two, and going back to > 2.6.19-rc6-mm2 do not give the messages. I don't think anything has changed in this area in XFS. I'd expect that something got broken in sata, ata_piix or the block core which caused the "trial barrier write" to start failing. Various cc's hopefully added. > Also, I got panics when unmounting reiser4 filesystems with > 2.6.20-rc1-mm1 but I guess this is related to your waring about reiser4 > being broken in 2.6.19-mm1 (even if it is not listed in notes for > 2.6.20-rc1-mm1)... I attach dmesg and config, but the reiser4 panics did > not get logged and I am not able to reboot on 2.6.20-rc1-mm1 right now. > For the moment, I mainly wanted to report the xfs messages which seems > a bit suspect. The reiser4 failure is unexpected. Could you please see if you can capture a trae, let the people at [EMAIL PROTECTED] know? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))
On Fri, Dec 15, 2006 at 09:15:22PM +0100, Francois Romieu wrote: > > Is there a way we can have this done by default on the n2100? I guess > > that since it's a PCI device, there isn't much hope for that..? > > Do you mean an automagically tuned default value based on CONFIG_ARM ? No, that wouldn't make sense, that's like making a workaround depend on arch == i386. I'm thinking that we should somehow enable this option on the n2100 built-in r8169 ports by default only. Since the n2100 also has a mini-PCI slot, and it is in theory possible to put an r8169 on a mini-PCI card, the workaround probably shouldn't apply to those, so testing for CONFIG_MACH_N2100 also isn't the right thing to do. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHSET] Various sas_ata feature additions and EH fixes
Hi again, As a companion to today's libsas roll-up, this is the queue of patches for the SATL connector between SAS and ATA. For patches not specifically focusing on SAS ATA, please refer to my previous email (or the patches themselves). Each patch has its own preamble description, but I'd like to call attention to a few of the larger shifts. The most significant modifications are a few fixes to make ATAPI devices work again, the beginnings of SATA PHY control (as best as can be approximated), and integration with the new libsas EH strategy. These patches should apply in number order cleanly against 2.6.19 + scsi_misc + aic94xx-sas. At the moment 2.6.20-rc isn't stable enough to boot cleanly on any of our machines, but we've been running insmod/rmmod and pounder tests on a x206m with mixed SAS/SATA/SATAPI devices for several days without problems. One can pick up the patches at the URL below. http://sweaglesw.net/~djwong/docs/sas_ata-patches/ A rough breakdown of the patches follows. These patches were covered in my libsas email, though the numbers shift a bit. 03-libsas-discovery-failure_6.patch 04-libsas-discovery-failure-expander_6.patch 05-aic94xx-abort-task-race_2.patch 06-libsas-enable-phy_2.patch 07-libsas-taskless-cmnd-reset-timer_2.patch 08-libsas-kill-task-collector-after-ports_1.patch 09-aic94xx-set-max-execute-num_1.patch 10-libsas-use-scan-wildcard_1.patch 11-aic94xx-dont-eat-query-task-results_1.patch 12-libsas-remove-initiator-aborted_1.patch 13-libsas-add-dev-reset-to-eh_1.patch 14-libsas-abort-sas-task-deferral_1.patch 15-aic94xx-defer-task-abort_1.patch 16-libsas-smp-portal_1.patch 17-aic94xx-fix-fw-leak_1.patch 18-aic94xx-fix-ddb-scb-init_2.patch 19-aic94xx-lock-ddb-access_2.patch 20-libsas-phy-sysfs-ctrl-not-iwugo_1.patch 33-andmike-lockdep-fix.patch 34-malahal-discovery-race.patch 35-alexisb-aic94xx-abort-task-failed-fallthrough.patch Roughly the same as last time: 21-libsas-ata-kconfig-fix_1.patch 22-libsas-fix-ata-qc-locking_3.patch 23-libsas-fix-qc-issue-err_1.patch 24-libsas-fix-libata-error_3.patch 25-libsas-ata-preserve-sactive_2.patch 31-libsas-satl-registration_3.patch 32-libsas-ata-module_3.patch Add some semblance of PHY control: 26-libsas-ata-enable-phy_1.patch ATAPI fixes: 27-libsas-atapi-sam-good_1.patch 28-libsas-ata-handle-unknown_1.patch This patch enables ATAPI devices for patch testing, though jejb is working on a better fix: 02-libata-atapi-handle-failed-report-luns_2.patch This goes with the new EH strategy code: 29-libsas-ata-assign-task-to-cmd_1.patch 30-libsas-ata-sas-task-abort_1.patch I appreciate any feedback/comments/flames people have about this patch set. Thanks! --D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] smc911x: fix netpoll compilation faliure
On Fri, 15 Dec 2006 16:13:28 +0300
Vitaly Wool <[EMAIL PROTECTED]> wrote:
> Hello folks,
>
> the trivial patch below fixes the compilation failure for smc911x.c when
> NET_POLL_CONTROLLER is set.
>
> drivers/net/smc911x.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Signed-off-by: Vitaly Wool <[EMAIL PROTECTED]>
>
> diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
> index 2c43433..797ab91 100644
> --- a/drivers/net/smc911x.c
> +++ b/drivers/net/smc911x.c
> @@ -1331,7 +1331,7 @@ smc911x_rx_dma_irq(int dma, void *data)
> static void smc911x_poll_controller(struct net_device *dev)
> {
> disable_irq(dev->irq);
> - smc911x_interrupt(dev->irq, dev, NULL);
> + smc911x_interrupt(dev->irq, dev);
> enable_irq(dev->irq);
> }
> #endif
That's a 2.6.19 fix, yes?
It looks like this driver needs a 2.6.20 fix also...
From: Andrew Morton <[EMAIL PROTECTED]>
Teach this driver about the workqueue changes.
Cc: Vitaly Wool <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/smc911x.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff -puN drivers/net/smc911x.c~smc911-workqueue-fixes drivers/net/smc911x.c
--- a/drivers/net/smc911x.c~smc911-workqueue-fixes
+++ a/drivers/net/smc911x.c
@@ -148,6 +148,8 @@ struct smc911x_local {
int tx_throttle;
spinlock_t lock;
+ struct net_device *netdev;
+
#ifdef SMC_USE_DMA
/* DMA needs the physical address of the chip */
u_long physaddr;
@@ -948,10 +950,11 @@ static void smc911x_phy_check_media(stru
* of autonegotiation.) If the RPC ANEG bit is cleared, the selection
* is controlled by the RPC SPEED and RPC DPLX bits.
*/
-static void smc911x_phy_configure(void *data)
+static void smc911x_phy_configure(struct work_struct *work)
{
- struct net_device *dev = data;
- struct smc911x_local *lp = netdev_priv(dev);
+ struct smc911x_local *lp = container_of(work, struct smc911x_local,
+ phy_configure);
+ struct net_device *dev = lp->netdev;
unsigned long ioaddr = dev->base_addr;
int phyaddr = lp->mii.phy_id;
int my_phy_caps; /* My PHY capabilities */
@@ -1495,6 +1498,8 @@ static void smc911x_set_multicast_list(s
static int
smc911x_open(struct net_device *dev)
{
+ struct smc911x_local *lp = netdev_priv(dev);
+
DBG(SMC_DEBUG_FUNC, "%s: --> %s\n", dev->name, __FUNCTION__);
/*
@@ -1511,7 +1516,7 @@ smc911x_open(struct net_device *dev)
smc911x_reset(dev);
/* Configure the PHY, initialize the link state */
- smc911x_phy_configure(dev);
+ smc911x_phy_configure(>phy_configure);
/* Turn on Tx + Rx */
smc911x_enable(dev);
@@ -2060,7 +2065,7 @@ static int __init smc911x_probe(struct n
dev->poll_controller = smc911x_poll_controller;
#endif
- INIT_WORK(>phy_configure, smc911x_phy_configure, dev);
+ INIT_WORK(>phy_configure, smc911x_phy_configure);
lp->mii.phy_id_mask = 0x1f;
lp->mii.reg_num_mask = 0x1f;
lp->mii.force_media = 0;
@@ -2154,6 +2159,7 @@ static int smc911x_drv_probe(struct plat
{
struct net_device *ndev;
struct resource *res;
+ struct smc911x_local *lp;
unsigned int *addr;
int ret;
@@ -2183,6 +2189,8 @@ static int smc911x_drv_probe(struct plat
ndev->dma = (unsigned char)-1;
ndev->irq = platform_get_irq(pdev, 0);
+ lp = netdev_priv(ndev);
+ lp->netdev = ndev;
addr = ioremap(res->start, SMC911X_IO_EXTENT);
if (!addr) {
@@ -2204,7 +2212,6 @@ out:
}
#ifdef SMC_USE_DMA
else {
- struct smc911x_local *lp = netdev_priv(ndev);
lp->physaddr = res->start;
lp->dev = >dev;
}
@@ -2275,7 +2282,7 @@ static int smc911x_drv_resume(struct pla
smc911x_reset(ndev);
smc911x_enable(ndev);
if (lp->phy_type != 0)
- smc911x_phy_configure(ndev);
+ smc911x_phy_configure(>phy_configure);
netif_device_attach(ndev);
}
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/v2] CodingStyle updates
On 12/15/06, Jörn Engel <[EMAIL PROTECTED]> wrote: On Fri, 15 December 2006 09:00:37 -0800, Randy Dunlap wrote: > On Fri, 15 Dec 2006 16:07:17 +0100 Pavel Machek wrote: > > > Not in simple cases. > > > > 3*i + 2*j should be writen like that. Not like > > (3 * i) + (2 * j) > > I would just write it as: > 3 * i + 2 * j So would I. But I definitely wouldn't write for (i = 0; i < 10; i += 2) because I prefer the grouping in for (i=0; i<10; i+=2) Would you write: i+=2; outside the loop? If not then it is better to keep style consistent and not use condensed form in loops either. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
