Re: [PATCH 2.6.13] lockless pagecache 5/7
I wonder if it may not be better to use a seqlock for the tree_lock? A seqlock requires no writes at all if the tree has not been changed. RCU still requires the incrementing of a (local) counter. Using seqlocks would require reworking the readers so that they can retry. Seqlocks provide already a verification that no update took place while the operation was in process. Thus we would be using an established framework that insures that the speculation was successful. The problem is then though to guarantee that the radix trees are always traversable since the seqlock's retry rather than block. This would require sequencing of inserts and pose a big problem for deletes and updates. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.13] x86_64: Fix incorrect FP signals
This is the same patch that went into i386 just before 2.6.13
came out. I still can't build 64-bit user apps, so I tested
with program (see below) in 32-bit mode on 64-bit kernel:
Before:
$ fpsig
handler: nr = 8, si = 0x0804bc90, vuc = 0x0804bd10
handler: altstack is at 0x0804b000, ebp = 0x0804bc7c
handler: si_signo = 8, si_errno = 0, si_code = 0 [unknown]
handler: fpu cwd = 0xb40, fpu swd = 0xbaa0
handler: i387 unmasked precision exception, rounded up
After:
$ fpsig
handler: nr = 8, si = 0x0804bc90, vuc = 0x0804bd10
handler: altstack is at 0x0804b000, ebp = 0x0804bc7c
handler: si_signo = 8, si_errno = 0, si_code = 6 [inexact result]
handler: fpu cwd = 0xb40, fpu swd = 0xbaa0
handler: i387 unmasked precision exception, rounded up
Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]>
arch/x86_64/kernel/traps.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
--- 2.6.13-64.orig/arch/x86_64/kernel/traps.c
+++ 2.6.13-64/arch/x86_64/kernel/traps.c
@@ -786,13 +786,16 @@ asmlinkage void do_coprocessor_error(str
*/
cwd = get_fpu_cwd(task);
swd = get_fpu_swd(task);
- switch (((~cwd) & swd & 0x3f) | (swd & 0x240)) {
+ switch (swd & ~cwd & 0x3f) {
case 0x000:
default:
break;
case 0x001: /* Invalid Op */
- case 0x041: /* Stack Fault */
- case 0x241: /* Stack Fault | Direction */
+ /*
+* swd & 0x240 == 0x040: Stack Underflow
+* swd & 0x240 == 0x240: Stack Overflow
+* User must clear the SF bit (0x40) if set
+*/
info.si_code = FPE_FLTINV;
break;
case 0x002: /* Denormalize */
/* i387 fp signal test */
#define _GNU_SOURCE
#include
#include
#include
#include
#include
/* define this to nozero to hexdump the altstack */
#define DUMP_STACK 0
#define STACKSIZE 4096
__attribute__ ((aligned(STACKSIZE))) unsigned char altstack[STACKSIZE];
stack_t ss = {
.ss_sp = altstack,
.ss_size = sizeof(altstack),
};
unsigned short cw = 0x0b40; /* unmask all exceptions, round up */
struct sigaction sa;
static void handler(int nr, siginfo_t *si, void *vuc)
{
char *decode;
unsigned int ebp;
int code = si->si_code;
struct ucontext *uc = (struct ucontext *)vuc;
struct sigcontext *sc = (struct sigcontext *)>uc_mcontext;
unsigned short cwd = (unsigned short)sc->fpstate->cw;
unsigned short swd = (unsigned short)sc->fpstate->sw;
switch (code) {
case FPE_INTDIV:
decode = "divide by zero";
break;
case FPE_FLTRES:
decode = "inexact result";
break;
case FPE_FLTINV:
decode = "invalid operand";
break;
default:
decode = "unknown";
break;
}
asm volatile ("mov %%ebp, %0" : "=m" (ebp));
printf("handler: nr = %d, si = 0x%08x, vuc = 0x%08x\n",
nr, (unsigned int)si, (unsigned int)vuc);
printf("handler: altstack is at 0x%08x, ebp = 0x%08x\n",
(unsigned int)altstack, ebp);
printf("handler: si_signo = %d, si_errno = %d, si_code = %d [%s]\n",
si->si_signo, si->si_errno, code, decode);
#if DUMP_STACK
#define ROWSIZE 16
{
int empty, i, j;
for (i = 0; i < sizeof(altstack); i += ROWSIZE) {
empty = 1;
for (j = 0; j < ROWSIZE; j++)
if (altstack[i + j])
empty = 0;
if (!empty) {
printf("%04x: ", i);
for (j = 0; j < ROWSIZE; j++)
printf("%02hhx ", altstack[i + j]);
printf("\n");
}
}
}
#endif /* DUMP_STACK */
printf("handler: fpu cwd = 0x%hx, fpu swd = 0x%hx\n", cwd, swd);
if (swd & 0x20 & ~cwd)
printf("handler: i387 unmasked precision exception, rounded
%s\n",
swd & 0x200 ? "up" : "down");
exit(1);
}
int main(int argc, char * const argv[])
{
sa.sa_sigaction = handler;
sa.sa_flags = SA_ONSTACK | SA_SIGINFO;
if (sigaltstack(, 0))
perror("sigaltstack");
if (sigaction(SIGFPE, , NULL))
perror("sigaction");
asm volatile ("fnclex ; fldcw %0" : : "m" (cw));
asm volatile ( /* st(1) = 3.0, st = 1.0 */
"fld1 ; fld1 ; faddp ; fld1 ; faddp ; fld1");
asm volatile (
"mov $0x,%%eax ; mov
Re: [patch 2.6.13] x86: check host bridge when applying vendor quirks
Andi Kleen wrote: On Friday 09 September 2005 04:33, Chuck Ebbert wrote: I was looking at the i386 ACPI early quirk code and x86_64 equivalent and it seems to me it should be checking the host bridge vendor, not the one for various PCI bridges. Nvidia might release some kind of PCI card with an embedded bridge that would break this code, for example. I made this patch but I can't test it: It's wrong. On AMD K8 systems the host bridge is always from AMD because the Northbridge is part of the CPU. Hmmm... no. [EMAIL PROTECTED]:/etc# lspci 00:00.0 Host bridge: ATI Technologies Inc: Unknown device 5950 <...many things...> 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control The Athlon64 machines has an external host bridge. You can look the ATI Host Bridge in the first line of lspci. Piter PUNK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] W1 patches for 2.6.13
On Thu, Sep 08, 2005 at 08:30:36PM -0700, Greg KH ([EMAIL PROTECTED]) wrote: > On Fri, Sep 09, 2005 at 01:30:09AM +0200, Marcel Holtmann wrote: > > Hi Greg, > > > > > Here are some w1 patches that have been in the -mm tree for a while. > > > They add a new driver, and fix up the netlink logic a lot. They also > > > add a crc16 implementation that is needed. > > > > adding the CRC-16 is very cool. I was just about to submit one by my > > own, because it is also needed for the Bluetooth L2CAP retransmission > > and flow control support. > > > > What about the 1-Wire notes inside the CRC-16 code. This suppose to be > > generic code and so this doesn't belong there. > > Yes, those comments don't belong there. Evgeniy, want to fix this? No problem. Patch attached. > thanks, > > greg k-h Remove w1 specific comments from generic crc16 implementation. Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]> diff --git a/include/linux/crc16.h b/include/linux/crc16.h --- a/include/linux/crc16.h +++ b/include/linux/crc16.h @@ -1,22 +1,11 @@ /* * crc16.h - CRC-16 routine * - * Implements the standard CRC-16, as used with 1-wire devices: + * Implements the standard CRC-16: * Width 16 * Poly 0x8005 (x^16 + x^15 + x^2 + 1) * Init 0 * - * For 1-wire devices, the CRC is stored inverted, LSB-first - * - * Example buffer with the CRC attached: - * 31 32 33 34 35 36 37 38 39 C2 44 - * - * The CRC over a buffer with the CRC attached is 0xB001. - * So, if (crc16(0, buf, size) == 0xB001) then the buffer is valid. - * - * Refer to "Application Note 937: Book of iButton Standards" for details. - * http://www.maxim-ic.com/appnotes.cfm/appnote_number/937 - * * Copyright (c) 2005 Ben Gardner <[EMAIL PROTECTED]> * * This source code is licensed under the GNU General Public License, @@ -28,9 +17,6 @@ #include -#define CRC16_INIT 0 -#define CRC16_VALID0xb001 - extern u16 const crc16_table[256]; extern u16 crc16(u16 crc, const u8 *buffer, size_t len); -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Doc: update oops-tracing.txt (Tainted flags)
From: Randy Dunlap <[EMAIL PROTECTED]> Update Documentation/oops-tracing.txt: - add descriptions of 3 more "Tainted" flags; - fix some typos; Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- Documentation/oops-tracing.txt | 25 + 1 files changed, 17 insertions(+), 8 deletions(-) diff -Naurp linux-2613-work/Documentation/oops-tracing.txt~doc_taint_update linux-2613-work/Documentation/oops-tracing.txt --- linux-2613-work/Documentation/oops-tracing.txt~doc_taint_update 2005-08-28 16:41:01.0 -0700 +++ linux-2613-work/Documentation/oops-tracing.txt 2005-09-08 21:43:02.0 -0700 @@ -205,8 +205,8 @@ Phone: 701-234-7556 Tainted kernels: Some oops reports contain the string 'Tainted: ' after the program -counter, this indicates that the kernel has been tainted by some -mechanism. The string is followed by a series of position sensitive +counter. This indicates that the kernel has been tainted by some +mechanism. The string is followed by a series of position-sensitive characters, each representing a particular tainted value. 1: 'G' if all modules loaded have a GPL or compatible license, 'P' if @@ -214,16 +214,25 @@ characters, each representing a particul MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by insmod as GPL compatible are assumed to be proprietary. - 2: 'F' if any module was force loaded by insmod -f, ' ' if all + 2: 'F' if any module was force loaded by "insmod -f", ' ' if all modules were loaded normally. 3: 'S' if the oops occurred on an SMP kernel running on hardware that - hasn't been certified as safe to run multiprocessor. - Currently this occurs only on various Athlons that are not - SMP capable. + hasn't been certified as safe to run multiprocessor. + Currently this occurs only on various Athlons that are not + SMP capable. + + 4: 'R' if a module was force unloaded by "rmmod -f", ' ' if all + modules were unloaded normally. + + 5: 'M' if any processor has reported a Machine Check Exception, + ' ' if no Machine Check Exceptions have occurred. + + 6: 'B' if a page-release function has found a bad page reference or + some unexpected page flags. The primary reason for the 'Tainted: ' string is to tell kernel debuggers if this is a clean kernel or if anything unusual has -occurred. Tainting is permanent, even if an offending module is -unloading the tainted value remains to indicate that the kernel is not +occurred. Tainting is permanent: even if an offending module is +unloaded, the tainted value remains to indicate that the kernel is not trustworthy. --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13] x86: check host bridge when applying vendor quirks
In-Reply-To: <[EMAIL PROTECTED]> On Fri, 9 Sep 2005 at 04:47:09 +0200, Andi Kleen wrote: > On Friday 09 September 2005 04:33, Chuck Ebbert wrote: > > I was looking at the i386 ACPI early quirk code and x86_64 equivalent > > and it seems to me it should be checking the host bridge vendor, not > > the one for various PCI bridges. Nvidia might release some kind of > > PCI card with an embedded bridge that would break this code, for > > example. I made this patch but I can't test it: > > It's wrong. On AMD K8 systems the host bridge is always from > AMD because the Northbridge is part of the CPU. It's at least right on my system: 00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 01) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control __ Chuck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] SUBCPUSETS: a resource control functionality using CPUSETS
On 9/9/05, KUROSAWA Takahiro <[EMAIL PROTECTED]> wrote: > On Thu, 8 Sep 2005 05:02:32 -0700 > Paul Jackson <[EMAIL PROTECTED]> wrote: > > One of my passions is to avoid special cases across API boundaries. > > > > I am proposing that you don't do subcpusets like this. > > > > Consider the following alternative I will call 'cpuset meters'. > > > > For each resource named 'R' (cpu and mem, for instance): > > * Add a boolean flag 'meter_R' to each cpuset. If set, that R is > >metered, for the tasks in that cpuset or any descendent cpuset. > > * If a cpuset is metered, then files named meter_R_guar, meter_R_lim > >and meter_R_cur appear in that cpuset to manage R's usage by tasks > >in that cpuset and descendents. > > * There are no additional rules that restrict the ability to change > >various other cpuset properties such as cpus, mems, cpu_exclusive, > >mem_exclusive, or notify_on_release, when a cpuset is metered. > > * It might be that some (or by design all) resource controllers do > >not allow nesting metered cpusets. I don't know. But one should > >(if one has permission) be able to make child cpusets of a metered > >cpuset, just like one can of any other cpuset. > > * A metered cpuset might well have cpus or mems that are not the > >same as its parent, just like an unmetered cpuset ordinarly does. > > Jackson-san's idea looks good for me because users don't need > to create special cpusets (parents of subcpusets or subcpusets). > From the point of users, maybe they wouldn't like to create > special cpusets. Yes, from the user POV it must be good to keep the hierarchical model. Ckrm and cpusets both provide a tree with descendents, children and parents. This hierarchical model is very nice IMO and provides a powerful API for the user. > As for the resource controller that I've posted, it assumes > that there are groups of tasks that share the same cpumasks/nodemasks, > and that there are no hierarchy in that groups in order to make > things easier. I'll investigate how I can attach the resource > controller to the cpuset meters. Subcpusets, compared to cpusets and ckrm, gives the user a flat model. No hierarchy. Limited functionality compared to the hierachical model. But what I think is important to keep in mind here is that cpusets and subcpusets do very different things. If I understand cpusets correctly, each cpuset may share processors or memory nodes with other cpusets. One task running on a shared processor may starve other cpusets using the same processor. This design works well with cpusets, but for resource controllers that must provide some kind of guarantee, this starvation is unsuitable. And we already have an hierarchical alternative: ckrm. But look at the complexity and the amount of code. I believe that the complexity in ckrm mainly comes from the hierarchical model. Maybe it is possible to have an hierarchical model and keep the framework simple and easy to understand while providing guarantees, I'm not sure. But until that happens, I'm quite happy with a simple, limited flat model. / magnus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] re-export genapic on i386
Christoph Hellwig <[EMAIL PROTECTED]> writes: > On Thu, Sep 08, 2005 at 05:47:34PM +0200, Jan Beulich wrote: > > (Note: Patch also attached because the inline version is certain to get > > line wrapped.) > > > > A change not too long ago made i386's genapic symbol no longer be > > exported, > > and thus certain low-level functions no longer be usable. Since > > close-to- > > the-hardware code may still be modular, this rectifies the situation. > > Again, what code would use it, why and why can't it use a proper accessor. > And a shitty thousands of lines out ot tree debugger ported from Novell's > legacy OS is not the answer, btw. Why not? Most debuggers will always be out of tree for political reasons, and because of that the normal "every hook must have an in tree user" rule cannot be strictly applied to them. It's also not reasonable to ask these people to always carry big patchkits around - after all they just want to debug core kernel code, and it is very ugly to apply a big patchkit just for that. So as long as the hooks for external modular debuggers are reasonable and _GPL I think they should be merged. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new kallsyms approach
"Jan Beulich" <[EMAIL PROTECTED]> writes: > This patch provides al alternative to the pre-exisiting kallsyms code. > That code, from a kernel debugger perspective at least, suffers from > incomplete information, making it impossible to > (a) disambiguate multiple static functions of the same name (in > different > source files), > (b) determine a complete set of attributes for a symbol (namely, the > symbol's size, but also its type, which gets converted to an nm-like > one- > character representation), and > (c) retain full section information I don't think it's a good idea to have two different ways to do kallsyms. Either we should always use your new way in standard KALLSYMS or not do it at all. The major decision factor is how much bloat it adds. Can you post before/after numbers of binary size? If the difference is >5% or so - are there ways to recover the difference? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] abstraction of i386 machine check handlers
"Jan Beulich" <[EMAIL PROTECTED]> writes: > (Note: Patch also attached because the inline version is certain to get > line wrapped.) > > This adjusts the i386 machine check infrastructure so that replacing > the > underlying exception handling code can be done by adjusting just a > single > definition rather than many different files. Quite ugly. How about just adding die notifiers there instead and then hooking them? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] minor ELF definitions addition
Christoph Hellwig <[EMAIL PROTECTED]> writes: > On Thu, Sep 08, 2005 at 04:30:03PM +0200, Jan Beulich wrote: > > (Note: Patch also attached because the inline version is certain to get > > line wrapped.) > > > > A trivial addition to the EFL definitions. > > Why? They're obviously not needed in kernelspace.. linux/elf.h has lots of stuff not needed in kernel space, but it seems useful to make it a faithful full description of ELF. BTW we actually considered using TLS on x86-64 for the PDA. The only reason it hasn't been done yet is that the necessary binutils are not wide spread enough yet. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] W1 patches for 2.6.13
On Fri, Sep 09, 2005 at 01:30:09AM +0200, Marcel Holtmann wrote: > Hi Greg, > > > Here are some w1 patches that have been in the -mm tree for a while. > > They add a new driver, and fix up the netlink logic a lot. They also > > add a crc16 implementation that is needed. > > adding the CRC-16 is very cool. I was just about to submit one by my > own, because it is also needed for the Bluetooth L2CAP retransmission > and flow control support. > > What about the 1-Wire notes inside the CRC-16 code. This suppose to be > generic code and so this doesn't belong there. Yes, those comments don't belong there. Evgeniy, want to fix this? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 2.6.13
On Thu, Sep 08, 2005 at 10:41:37PM -0400, Mark Lord wrote: > Is someone actively working on USB Suspend/Resume support yet? > > I ask because this is becoming more and more important as people > shift more to portable notebook computers with Linux. > > Enabling CONFIG_USB_SUSPEND is currently a surefire way to > guarantee crashing my own notebook on suspend/resume, > whereas it *usually* (but not always) survives when that > config option is left unset. > > Nothing complicated in the configuration -- just a USB mouse, > but that's enough to nuke it. > > Anyone looking at that stuff right now? Yes, people are. Please report this on the linux-usb-devel mailing list, or file a bug at bugzilla.kernel.org thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] Re: [GIT PATCH] USB patches for 2.6.13
Hi Mark, > Is someone actively working on USB Suspend/Resume support yet? I've got some patches that need refreshing and splitting-out that don't seem like 2.6.14 material in the "new world", but maybe a few of them are. There are also a handful of EHCI and OHCI fixes pending for 2.6.14 which aren't in Greg's latest batch, some of which affect USB PM. I understand they'll get into the MM tree soon. > I ask because this is becoming more and more important as people > shift more to portable notebook computers with Linux. > > Enabling CONFIG_USB_SUSPEND is currently a surefire way to > guarantee crashing my own notebook on suspend/resume, > whereas it *usually* (but not always) survives when that > config option is left unset. That's strange. For me it's been closer to the other way around, except that things never crash for me. Something tells me your hardware and/or BIOS is different... Some of the PM and usbcore changes have been tweaking assumptions; which of course makes some of the more sensitive code paths unhappy. > Nothing complicated in the configuration -- just a USB mouse, > but that's enough to nuke it. > > Anyone looking at that stuff right now? I don't know that anyone's looking specifically at the issue that the HID (mouse) driver has; I'm not. If your system behaves OK without that mouse connected, it ought to be easy to fix that one bug. If not, forward details to linux-usb-devel (separate thread). - 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 patch] libata fixes
Please pull from 'upstream' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
to obtain fixes for last-minute problems noticed in current build,
following GregKH's PCI merge.
drivers/scsi/sata_mv.c | 16
drivers/scsi/sata_sis.c | 20 +++-
2 files changed, 11 insertions(+), 25 deletions(-)
commit 8add788574694c5aed04fcb281a5c999e40cd8f6
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Thu Sep 8 23:07:29 2005 -0400
[libata] minor fixes
* sata_mv: remove pci_intx(), now that the same function is in PCI core
* sata_sis: fix variable initialization bug, trim trailing whitespace
diff --git a/drivers/scsi/sata_mv.c b/drivers/scsi/sata_mv.c
--- a/drivers/scsi/sata_mv.c
+++ b/drivers/scsi/sata_mv.c
@@ -699,22 +699,6 @@ static int mv_host_init(struct ata_probe
return rc;
}
-/* move to PCI layer, integrate w/ MSI stuff */
-static void pci_intx(struct pci_dev *pdev, int enable)
-{
- u16 pci_command, new;
-
- pci_read_config_word(pdev, PCI_COMMAND, _command);
-
- if (enable)
- new = pci_command & ~PCI_COMMAND_INTX_DISABLE;
- else
- new = pci_command | PCI_COMMAND_INTX_DISABLE;
-
- if (new != pci_command)
- pci_write_config_word(pdev, PCI_COMMAND, pci_command);
-}
-
static int mv_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
static int printed_version = 0;
diff --git a/drivers/scsi/sata_sis.c b/drivers/scsi/sata_sis.c
--- a/drivers/scsi/sata_sis.c
+++ b/drivers/scsi/sata_sis.c
@@ -55,7 +55,7 @@ enum {
SIS180_SATA1_OFS= 0x10, /* offset from sata0->sata1 phy regs */
SIS182_SATA1_OFS= 0x20, /* offset from sata0->sata1 phy regs */
SIS_PMR = 0x90, /* port mapping register */
- SIS_PMR_COMBINED= 0x30,
+ SIS_PMR_COMBINED= 0x30,
/* random bits */
SIS_FLAG_CFGSCR = (1 << 30), /* host flag: SCRs via PCI cfg */
@@ -147,11 +147,13 @@ static unsigned int get_scr_cfg_addr(uns
{
unsigned int addr = SIS_SCR_BASE + (4 * sc_reg);
- if (port_no)
+ if (port_no) {
if (device == 0x182)
addr += SIS182_SATA1_OFS;
else
addr += SIS180_SATA1_OFS;
+ }
+
return addr;
}
@@ -166,10 +168,10 @@ static u32 sis_scr_cfg_read (struct ata_
return 0x;
pci_read_config_byte(pdev, SIS_PMR, );
-
+
pci_read_config_dword(pdev, cfg_addr, );
- if ((pdev->device == 0x182) || (pmr & SIS_PMR_COMBINED))
+ if ((pdev->device == 0x182) || (pmr & SIS_PMR_COMBINED))
pci_read_config_dword(pdev, cfg_addr+0x10, );
return val|val2;
@@ -185,7 +187,7 @@ static void sis_scr_cfg_write (struct at
return;
pci_read_config_byte(pdev, SIS_PMR, );
-
+
pci_write_config_dword(pdev, cfg_addr, val);
if ((pdev->device == 0x182) || (pmr & SIS_PMR_COMBINED))
@@ -195,7 +197,7 @@ static void sis_scr_cfg_write (struct at
static u32 sis_scr_read (struct ata_port *ap, unsigned int sc_reg)
{
struct pci_dev *pdev = to_pci_dev(ap->host_set->dev);
- u32 val,val2;
+ u32 val, val2 = 0;
u8 pmr;
if (sc_reg > SCR_CONTROL)
@@ -209,9 +211,9 @@ static u32 sis_scr_read (struct ata_port
val = inl(ap->ioaddr.scr_addr + (sc_reg * 4));
if ((pdev->device == 0x182) || (pmr & SIS_PMR_COMBINED))
- val2 = inl(ap->ioaddr.scr_addr + (sc_reg * 4)+0x10);
+ val2 = inl(ap->ioaddr.scr_addr + (sc_reg * 4) + 0x10);
- return val|val2;
+ return val | val2;
}
static void sis_scr_write (struct ata_port *ap, unsigned int sc_reg, u32 val)
@@ -223,7 +225,7 @@ static void sis_scr_write (struct ata_po
return;
pci_read_config_byte(pdev, SIS_PMR, );
-
+
if (ap->flags & SIS_FLAG_CFGSCR)
sis_scr_cfg_write(ap, sc_reg, val);
else {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SPI redux ... driver model support
> Date: Wed, 7 Sep 2005 19:38:43 +0100 (BST) > From: Mark Underwood <[EMAIL PROTECTED]> > ... > > I see several posabiltiys of how SPI devices could be > connected to an adapter. Certainly, and all are addressed cleanly by the kind of configuration scheme I showed. > 1) All SPI devices are hardwired to the adapter. I > think this would be the most common. For custom hardware, not designed for expansion, yes. Zaurus Corgi models, for example, keep three SPI devices busy. But in that category I'd also include custom hardware that happens to be packaged by connecting boards, which is also the territory of #2 or #3 below. "Hard wired" can include connectors that are removable by breaking the warranty. :) > 2) Some SPI devices are hardwired and some are > removable. Development/Evaluation boards -- the reference implementations in most environments, not just Linux -- seem to all but universally choose this option (or, more rarely, #3). There might be some domain-specific chips hardwired (touchscreen or CAN controller, ADC/DAC, etc), but expansion connectors WILL expose SPI. That makes sense; one goal is to support system prototyping, and it's hard to do that if for any reason one of the major hardware connectivity options is hard to get at! > 3) All SPI devices are removable. This is common for the sort of single board computers that get sold to run Linux (or whatever) as part of semicustom hardware: maybe not much more than a few square inches packed with an SOC CPU, FLASH, RAM, and expansion connectors providing access to a few dozen SOC peripherals. (There might be 250 or so SOC pins, with expansion connectors providing access to some big portion of those pins ... including some for SPI.) It'd be nice to be able to support those SBCs with a core Linux port, and then just layer support for addon boards on top of that without needing to touch a line of arch code. And convenient for folk who are adding value through those addons. :) >When you plug a card in you use > spi_device_register to add that device to the system > and when you remove the card you call > spi_device_unregister. You can then do the same for a > different card and at no time have you changed the > declaration of the controller. That implies whoever is registering is actually going and creating the SPI devices ... and doing it AFTER the controller driver is registered. I actually have issues with each of those implications. However, I was also aiming to support the model where the controller drivers are modular, and the "add driver" and "declare hardware" steps can go in any order. That way things can work "just like other busses" when you load the controller drivers ... and the approach is like the familiar "boot firmware gives hardware description tables to the OS" approach used by lots of _other_ hardware that probes poorly. (Except that Linux is likely taking over lots of that "boot firmware" role.) > > I'll post a refresh of my patch that seems to me to be > > a much better match for those goals. The refresh includes > > some tweaks based on what you sent, but it's still just > > one KByte of overhead in the target ROM. :) Grr. I added sysfs attributes and an I/O utility function, and now it's a bit bigger than 1KByte. Especially with debugging enabled, it's nearer 1.5KB. The curse of actually trying to hook up to hardware and its quirks. :( > OK. I will post an updated version of my SPI subsystem > within the next few days with the transfer stuff added > and maybe the interrupt and GPO abstraction as well. OK. > I haven't seen any replies to my SPI patch :( did you > reply to it? No, I was going to sent it when I sent that refresh; it's helped focus my thoughts a bit. :) Several of the comments (like "get rid of algorithm layer!") you'll have heard before in response to the RFC from MontaVista. It seems both approaches are still trying to make SPI seem like I2C, and not taking the opportunity to _fix_ very much of the I2C oddness. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.13-mm2 - drivers/char/speakup/speakup doesn't compile (+warnings from other things)
Le Thursday 08 September 2005 14:30, Andrew Morton a écrit : | - Many tty drivers still won't compile indeed ... here one of them: CC [M] drivers/char/speakup/speakup.o drivers/char/speakup/speakup.c: In function 'speakup_paste_selection': drivers/char/speakup/speakup.c:491: error: 'struct tty_ldisc' has no member named 'receive_room' drivers/char/speakup/speakup.c:491: error: 'struct tty_ldisc' has no member named 'receive_room' make[3]: *** [drivers/char/speakup/speakup.o] Error 1 make[2]: *** [drivers/char/speakup] Error 2 make[1]: *** [drivers/char] Error 2 warnings from compile (gcc 4.0.1) till this error can be found in attachement 'build-log-$kernelver-processed'. the xfs trouble with '"__BIG_ENDIAN" is not defined' is now happening since rc6-mm1. config can be found here: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/kernels/kernel26mm/config?rev=1.34=Extra=text/vnd.viewcvs-markup hope this info is usable to somebody out there, greetings, Damir -- Customer: "I'm sorry. I think I just deleted the Internet!" Tech Support: "That's ok. We have it backed up here on tape somewhere." ==> Builing kernel 2.6.13-mm2 started at Fri Sep 9 04:04:45 CEST 2005 arch/i386/kernel/cpu/transmeta.c: In function 'init_transmeta': arch/i386/kernel/cpu/transmeta.c:11: warning: 'cpu_freq' may be used uninitialized in this function arch/i386/kernel/apm.c: In function 'suspend': arch/i386/kernel/apm.c:1186: warning: 'pm_send_all' is deprecated (declared at include/linux/pm.h:122) arch/i386/kernel/apm.c:1240: warning: 'pm_send_all' is deprecated (declared at include/linux/pm.h:122) arch/i386/kernel/apm.c: In function 'check_events': arch/i386/kernel/apm.c:1361: warning: 'pm_send_all' is deprecated (declared at include/linux/pm.h:122) kernel/resource.c:482: warning: '__check_region' is deprecated (declared at kernel/resource.c:470) kernel/intermodule.c:178: warning: 'inter_module_register' is deprecated (declared at kernel/intermodule.c:38) kernel/intermodule.c:179: warning: 'inter_module_unregister' is deprecated (declared at kernel/intermodule.c:78) kernel/intermodule.c:181: warning: 'inter_module_put' is deprecated (declared at kernel/intermodule.c:159) kernel/power/pm.c:258: warning: 'pm_register' is deprecated (declared at kernel/power/pm.c:62) kernel/power/pm.c:259: warning: 'pm_unregister' is deprecated (declared at kernel/power/pm.c:85) kernel/power/pm.c:260: warning: 'pm_unregister_all' is deprecated (declared at kernel/power/pm.c:114) kernel/power/pm.c:261: warning: 'pm_send_all' is deprecated (declared at kernel/power/pm.c:233) fs/bio.c: In function 'bio_alloc_bioset': fs/bio.c:167: warning: 'idx' may be used uninitialized in this function In file included from fs/cifs/cifsfs.c:38: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/cifssmb.c:36: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/cifs_debug.c:29: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/connect.c:36: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/dir.c:29: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/file.c:32: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/inode.c:28: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/link.c:26: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/misc.c:26: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/netmisc.c:35: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/transport.c:31: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/asn1.c:27: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/xattr.c:26: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/cifsencrypt.c:24: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/fcntl.c:26: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/readdir.c:27: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type In file included from fs/cifs/ioctl.c:27: fs/cifs/cifsglob.h:335: warning: type qualifiers ignored on function return type fs/jfs/jfs_txnmgr.c: In function 'xtLog': fs/jfs/jfs_txnmgr.c:1917: warning: 'pxd.addr2' may be used uninitialized in this function fs/jfs/jfs_txnmgr.c:1917: warning:
Re: [patch 2.6.13] x86_64: Clean up nmi error message
On Friday 09 September 2005 04:33, Chuck Ebbert wrote: > The x86_64 nmi code is missing a newline in one of its messages. > > I added a space before the CPU id for readability and killed the trailing > space on the previous line as well. Thanks merged. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 8250.c: Fix to make 16C950 UARTs work
Stefan Smietanowski wrote:
> Mathias Adam wrote:
> > Currently serial8250_set_termios() refuses to program a baud rate larger
> > than uartclk/16. However the 16C950 supports baud rates up to uartclk/4.
> > This worked already with Linux 2.4 so the biggest part of this patch was
> > simply taken from there and adapted to 2.6.
> > - unsigned int baud, quot;
> > + unsigned int baud, quot, max_baud;
>
> > - baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk/16);
> > + MAX_baud = (up->port.type == PORT_16C950 ? port->uartclk/4 :
> > port->uartclk/16);
>
>
> Did you even compile test this?
Oops, I really really wonder how THIS could have happened as I just attached
my existing patch file (which was and still is correct) without touching
it - at least that's what I thought... Sorry!
Mathias Adam
I hope everything's alright this time:
--- linux-2.6.13-org/drivers/serial/8250.c 2005-08-29 01:41:01.0
+0200
+++ linux-2.6.13/drivers/serial/8250.c 2005-09-09 02:16:49.0 +0200
@@ -1665,7 +1665,7 @@
struct uart_8250_port *up = (struct uart_8250_port *)port;
unsigned char cval, fcr = 0;
unsigned long flags;
- unsigned int baud, quot;
+ unsigned int baud, quot, max_baud;
switch (termios->c_cflag & CSIZE) {
case CS5:
@@ -1697,9 +1697,28 @@
/*
* Ask the core to calculate the divisor for us.
*/
- baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk/16);
+ max_baud = (up->port.type == PORT_16C950 ? port->uartclk/4 :
port->uartclk/16);
+ baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
quot = serial8250_get_divisor(port, baud);
+ /*
+* 16C950 supports additional prescaler ratios between 1:16 and 1:4
+* thus increasing max baud rate to uartclk/4. The following was taken
+* from kernel 2.4 by Mathias Adam <[EMAIL PROTECTED]> to make the
Socket
+* Bluetooth CF Card work under 2.6.13.
+*/
+ if (up->port.type == PORT_16C950) {
+ unsigned int baud_base = port->uartclk/16;
+ if (baud <= port->uartclk/16)
+ serial_icr_write(up, UART_TCR, 0);
+ else if (baud <= port->uartclk/8) {
+ serial_icr_write(up, UART_TCR, 0x8);
+ } else if (baud <= port->uartclk/4) {
+ serial_icr_write(up, UART_TCR, 0x4);
+ } else
+ serial_icr_write(up, UART_TCR, 0);
+ }
+
/*
* Oxford Semi 952 rev B workaround
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13] x86: check host bridge when applying vendor quirks
On Friday 09 September 2005 04:33, Chuck Ebbert wrote: > I was looking at the i386 ACPI early quirk code and x86_64 equivalent > and it seems to me it should be checking the host bridge vendor, not > the one for various PCI bridges. Nvidia might release some kind of > PCI card with an embedded bridge that would break this code, for > example. I made this patch but I can't test it: It's wrong. On AMD K8 systems the host bridge is always from AMD because the Northbridge is part of the CPU. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 2.6.13
Is someone actively working on USB Suspend/Resume support yet? I ask because this is becoming more and more important as people shift more to portable notebook computers with Linux. Enabling CONFIG_USB_SUSPEND is currently a surefire way to guarantee crashing my own notebook on suspend/resume, whereas it *usually* (but not always) survives when that config option is left unset. Nothing complicated in the configuration -- just a USB mouse, but that's enough to nuke it. Anyone looking at that stuff right now? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.13] x86_64: Clean up nmi error message
The x86_64 nmi code is missing a newline in one of its messages.
I added a space before the CPU id for readability and killed the trailing
space on the previous line as well.
Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]>
arch/x86_64/kernel/nmi.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--- 2.6.13-64.orig/arch/x86_64/kernel/nmi.c
+++ 2.6.13-64/arch/x86_64/kernel/nmi.c
@@ -486,8 +486,8 @@ void nmi_watchdog_tick (struct pt_regs *
== NOTIFY_STOP) {
local_set(&__get_cpu_var(alert_counter), 0);
return;
- }
- die_nmi("NMI Watchdog detected LOCKUP on CPU%d", regs);
+ }
+ die_nmi("NMI Watchdog detected LOCKUP on CPU %d\n",
regs);
}
} else {
__get_cpu_var(last_irq_sum) = sum;
__
Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.13] x86: check host bridge when applying vendor quirks
I was looking at the i386 ACPI early quirk code and x86_64 equivalent and it seems to me it should be checking the host bridge vendor, not the one for various PCI bridges. Nvidia might release some kind of PCI card with an embedded bridge that would break this code, for example. I made this patch but I can't test it: Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]> arch/i386/kernel/acpi/earlyquirk.c |2 +- arch/x86_64/kernel/io_apic.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- 2.6.13a.orig/arch/i386/kernel/acpi/earlyquirk.c +++ 2.6.13a/arch/i386/kernel/acpi/earlyquirk.c @@ -36,7 +36,7 @@ void __init check_acpi_pci(void) if (class == 0x) break; - if ((class >> 16) != PCI_CLASS_BRIDGE_PCI) + if ((class >> 16) != PCI_CLASS_BRIDGE_HOST) continue; vendor = read_pci_config(num, slot, func, --- 2.6.13a.orig/arch/x86_64/kernel/io_apic.c +++ 2.6.13a/arch/x86_64/kernel/io_apic.c @@ -242,7 +242,7 @@ void __init check_ioapic(void) if (class == 0x) break; - if ((class >> 16) != PCI_CLASS_BRIDGE_PCI) + if ((class >> 16) != PCI_CLASS_BRIDGE_HOST) continue; vendor = read_pci_config(num, slot, func, __ Chuck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems Building Bluetooth with K6 and CONFIG_REGPARM
On Thu, Sep 08, 2005 at 12:49:17PM -0400, Brian Gerst wrote: > Horms wrote: > >Hi Andy, > > > >that does indeed seem to be a problem. I have narrowed it down to > >a combination of using K6 and CONFIG_REGPARM. Hunting around a bit > >I found this http://my.execpc.com/~geezer/osd/gotchas/, which > >suggests the problem is that the asm in question tries to add a register > >to the clobber list which is not available. This makes sense, > >I guess REGPARM is using edx, so inline assembly can't. > > > >I've CCed the bluetooth maintainers and lkml, hopefully someone there > >will have some input on how to resolve this problem, as inline assembly > >isn't my strong point and the problem seems to manifest in Linus' current > >git tree. > > > >The relevant code is the following call to BUILDIO(b,b,char) towards the > >bottom of include/asm/io.h > > > >BUILDIO is as follows, and I am guessing it is the "Nd"(port) and > >possibley "d"(port) portions that are problematic. > > Sounds like a compiler bug, especially since changing the CPU type fixes > it. What version of GCC? I definately think it is compiler related, I was using Debian's GCC 4.0.1-6. I could try with 3.3 or soemthing like that if you like. The problem was easily reproducable with 4.0.1 and a K6+CONFIG_REGPARM config. -- Horms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] Scheduler hooks to support separate ia64 MCA/INIT stacks
The new ia64 MCA/INIT handlers[1] (think of them as super NMI) run on
separate stacks. 99% of the changes for these new handlers is ia64
only code, however they need a couple of scheduler hooks to support
these extra stacks. The complete patch set will be coming through the
ia64 tree, this RFC covers just the scheduler changes, so they do not
come as a surprise when the ia64 tree is rolled up.
[1] http://marc.theaimsgroup.com/?l=linux-ia64=112537827113545=2
and the following patches.
IA64 MCA/INIT are completely asynchronous events. They can be
delivered even when normal interrupts are disabled. The cpu can be in
user context, in kernel context, in prom called from the kernel, the
cpu can even be in physical addressing mode with no valid stack
pointers when MCA/INIT is delivered.
Because of all the modes in which these events can occur, it is not
safe to use the normal kernel stacks, mainly because we cannot always
tell what state the kernel stacks are in when MCA/INIT is delivered.
The new MCA/INIT handlers define some additional per-cpu stacks. When
MCA/INIT is delivered, the cpu starts using the relevant per-cpu stack,
effectively running as a new process. If the original kernel stack can
be identified and verified then the process that was interrupted is
modified to look like a blocked task.
IA64 backtrace has two distinct starting points, a task can either be
running or it can be blocked. The ia64 unwinder starts with two
different states, depending on the task state. Since MCA/INIT
backtrace is done using one cpu to list all the tasks, there has to be
a way for the backtrace code to determine if a task is running on
another cpu or is blocked. In 2.4 we used to have a flag to say that a
task was running on a cpu. In 2.6, that data is stored in
cpu_curr(cpu), which needs to be exposed to support ia64 MCA/INIT
handlers.
The new MCA/INIT handlers are the equivalent of an asynchronous context
switch. Because MCA/INIT can be delivered at any time, the handlers
cannot trust the state of any spinlock, MCA/INIT can occur when
spin_lock_irq has been issued, i.e. they can occur in the middle of
critical code. Therefore it is not safe to call the normal scheduler
functions which update the runqueues.
This patch adds two small hooks that can be safely called from MCA/INIT
context. If other architectures want to support NMI on separate stacks
then they can also use these functions.
Index: linux/include/linux/sched.h
===
- --- linux.orig/include/linux/sched.h 2005-09-08 16:47:05.668290545 +1000
+++ linux/include/linux/sched.h 2005-09-08 16:47:08.165015793 +1000
@@ -883,6 +883,8 @@ extern int task_curr(const task_t *p);
extern int idle_cpu(int cpu);
extern int sched_setscheduler(struct task_struct *, int, struct sched_param *);
extern task_t *idle_task(int cpu);
+extern task_t *curr_task(int cpu);
+extern void set_curr_task(int cpu, task_t *p);
void yield(void);
Index: linux/kernel/sched.c
===
- --- linux.orig/kernel/sched.c 2005-09-08 16:47:05.669266973 +1000
+++ linux/kernel/sched.c2005-09-09 11:36:53.017356186 +1000
@@ -3471,6 +3471,32 @@ task_t *idle_task(int cpu)
}
/**
+ * curr_task - return the current task for a given cpu.
+ * @cpu: the processor in question.
+ */
+task_t *curr_task(int cpu)
+{
+ return cpu_curr(cpu);
+}
+
+/**
+ * set_curr_task - set the current task for a given cpu.
+ * @cpu: the processor in question.
+ * @p: the task pointer to set.
+ *
+ * Description: This function must only be used when non-maskable interrupts
+ * are serviced on a separate stack. It allows the architecture to switch the
+ * notion of the current task on a cpu in a non-blocking manner. This function
+ * must be called with interrupts disabled, the caller must save the original
+ * value of the current task (see curr_task() above) and restore that value
+ * before reenabling interrupts.
+ */
+void set_curr_task(int cpu, task_t *p)
+{
+ cpu_curr(cpu) = p;
+}
+
+/**
* find_process_by_pid - find a process with a matching PID value.
* @pid: the pid in question.
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] (repost) New System call, unshare (fwd)
Nick Piggin wrote:
Janak Desai wrote:
-tsk->min_flt = tsk->maj_flt = 0;
-tsk->nvcsw = tsk->nivcsw = 0;
+/*
+ * If the process memory is being duplicated as part of the
+ * unshare system call, we are working with the current process
+ * and not a newly allocated task strucutre, and should not
+ * zero out fault info, context switch counts, mm and active_mm
+ * fields.
+ */
+if (copy_share_action == MAY_SHARE) {
+tsk->min_flt = tsk->maj_flt = 0;
+tsk->nvcsw = tsk->nivcsw = 0;
Why don't you just do this in copy_process?
I was trying to avoid changing interface of copy_process since it
is also used by do_fork() and fork_idle().
-tsk->mm = NULL;
-tsk->active_mm = NULL;
+tsk->mm = NULL;
+tsk->active_mm = NULL;
+}
/*
* Are we cloning a kernel thread?
@@ -1002,7 +1023,7 @@ static task_t *copy_process(unsigned lon
goto bad_fork_cleanup_fs;
if ((retval = copy_signal(clone_flags, p)))
goto bad_fork_cleanup_sighand;
-if ((retval = copy_mm(clone_flags, p)))
+if ((retval = copy_mm(clone_flags, p, MAY_SHARE)))
goto bad_fork_cleanup_signal;
if ((retval = copy_keys(clone_flags, p)))
goto bad_fork_cleanup_mm;
@@ -1317,3 +1338,172 @@ void __init proc_caches_init(void)
sizeof(struct mm_struct), 0,
SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);
}
+
+/*
+ * unshare_mm is called from the unshare system call handler function to
+ * make a private copy of the mm_struct structure. It calls copy_mm with
+ * CLONE_VM flag cleard, to ensure that a private copy of mm_struct
is made,
+ * and with mm_copy_share enum set to UNSHARE, to ensure that copy_mm
+ * does not clear fault info, context switch counts, mm and active_mm
+ * fields of the mm_struct.
+ */
+static int unshare_mm(unsigned long unshare_flags, struct task_struct
*tsk)
+{
+int retval = 0;
+struct mm_struct *mm = tsk->mm;
+
+/*
+ * If the virtual memory is being shared, make a private
+ * copy and disassociate the process from the shared virtual
+ * memory.
+ */
+if (atomic_read(>mm_users) > 1) {
+retval = copy_mm((unshare_flags & ~CLONE_VM), tsk, UNSHARE);
+
+/*
+ * If copy_mm was successful, decrement the number of users
+ * on the original, shared, mm_struct.
+ */
+if (!retval)
+atomic_dec(>mm_users);
+}
+return retval;
+}
+
What prevents thread 1 from decrementing mm_users after thread 2 has
found it to be 2?
Yes, Chris pointed out that as well. I will be reviewing and reworking
this logic.
Thanks.
-Janak
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] (repost) New System call, unshare (fwd)
Thanks again for your review. I understand the problems that
you highlighted. I will rework the code and this time create
test programs that test these aspects of unsharing that I had
missed. Basically, the four areas that I have to fix are
- Investigate impact on aio and futex
- Handle possibilities of other threads manipulating use
counts and/or deleting mm/namespace/sighand structures
that were being shared
- Review/handle implications of calling copy_* with a
task that is visible globably.
- Consider impact of previous call to clone() with
sharing of appropriate resources.
Specific responses are inline ...
Chris Wright wrote:
* Janak Desai ([EMAIL PROTECTED]) wrote:
diff -Naurp linux-2.6.13-mm1/kernel/fork.c
linux-2.6.13-mm1+unshare-patch1/kernel/fork.c
--- linux-2.6.13-mm1/kernel/fork.c 2005-09-07 13:25:01.0 +
+++ linux-2.6.13-mm1+unshare-patch1/kernel/fork.c 2005-09-07
13:40:11.0 +
@@ -58,6 +58,17 @@ int nr_threads; /* The idle threads do
int max_threads;/* tunable limit on nr_threads */
+/*
+ * mm_copy gets called from clone or unshare system calls. When called
+ * from clone, mm_struct may be shared depending on the clone flags
+ * argument, however, when called from the unshare system call, a private
+ * copy of mm_struct is made.
+ */
+enum mm_copy_share {
+ MAY_SHARE,
+ UNSHARE,
+};
+
DEFINE_PER_CPU(unsigned long, process_counts) = 0;
__cacheline_aligned DEFINE_RWLOCK(tasklist_lock); /* outer */
@@ -448,16 +459,26 @@ void mm_release(struct task_struct *tsk,
}
}
-static int copy_mm(unsigned long clone_flags, struct task_struct * tsk)
+static int copy_mm(unsigned long clone_flags, struct task_struct * tsk,
+ enum mm_copy_share copy_share_action)
minor nitpick, pretty verbose name, could just be share.
ok, sounds good. Will change to share.
{
struct mm_struct * mm, *oldmm;
int retval;
- tsk->min_flt = tsk->maj_flt = 0;
- tsk->nvcsw = tsk->nivcsw = 0;
+ /*
+* If the process memory is being duplicated as part of the
+* unshare system call, we are working with the current process
+* and not a newly allocated task strucutre, and should not
+* zero out fault info, context switch counts, mm and active_mm
+* fields.
+*/
+ if (copy_share_action == MAY_SHARE) {
+ tsk->min_flt = tsk->maj_flt = 0;
+ tsk->nvcsw = tsk->nivcsw = 0;
- tsk->mm = NULL;
- tsk->active_mm = NULL;
+ tsk->mm = NULL;
+ tsk->active_mm = NULL;
+ }
/*
* Are we cloning a kernel thread?
@@ -1002,7 +1023,7 @@ static task_t *copy_process(unsigned lon
goto bad_fork_cleanup_fs;
if ((retval = copy_signal(clone_flags, p)))
goto bad_fork_cleanup_sighand;
- if ((retval = copy_mm(clone_flags, p)))
+ if ((retval = copy_mm(clone_flags, p, MAY_SHARE)))
goto bad_fork_cleanup_signal;
if ((retval = copy_keys(clone_flags, p)))
goto bad_fork_cleanup_mm;
@@ -1317,3 +1338,172 @@ void __init proc_caches_init(void)
sizeof(struct mm_struct), 0,
SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL);
}
+
+/*
+ * unshare_mm is called from the unshare system call handler function to
+ * make a private copy of the mm_struct structure. It calls copy_mm with
+ * CLONE_VM flag cleard, to ensure that a private copy of mm_struct is made,
+ * and with mm_copy_share enum set to UNSHARE, to ensure that copy_mm
+ * does not clear fault info, context switch counts, mm and active_mm
+ * fields of the mm_struct.
+ */
+static int unshare_mm(unsigned long unshare_flags, struct task_struct *tsk)
+{
+ int retval = 0;
+ struct mm_struct *mm = tsk->mm;
+
+ /*
+* If the virtual memory is being shared, make a private
+* copy and disassociate the process from the shared virtual
+* memory.
+*/
+ if (atomic_read(>mm_users) > 1) {
+ retval = copy_mm((unshare_flags & ~CLONE_VM), tsk, UNSHARE);
Looks like this could allow aio to be done on behalf of wrong mm? Hmm,
and what about the futex code?
I had missed aio and futex implications, I will carefully
review them to ensure that unshare doesn't break them.
+
+ /*
+* If copy_mm was successful, decrement the number of users
+* on the original, shared, mm_struct.
+*/
+ if (!retval)
+ atomic_dec(>mm_users);
This is not sufficient. Should be mmput(). It's trivial to bump the
refcount without it actually being shared, so you may have just leaked
the mm_struct if you were last holder.
yes, will change to mmput(). I see now how mmput() releases
resources only when the count goes to zero.
+ }
+
Re: [PATCH] 8250.c: Fix to make 16C950 UARTs work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mathias Adam wrote: > Currently serial8250_set_termios() refuses to program a baud rate larger > than uartclk/16. However the 16C950 supports baud rates up to uartclk/4. > This worked already with Linux 2.4 so the biggest part of this patch was > simply taken from there and adapted to 2.6. > - unsigned int baud, quot; > + unsigned int baud, quot, max_baud; > - baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk/16); > + MAX_baud = (up->port.type == PORT_16C950 ? port->uartclk/4 : > port->uartclk/16); Did you even compile test this? // Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFDIOxFBrn2kJu9P78RAnG3AJ9EJKl6q4Q4+jXRdMifvmOEdO+HewCfUPd8 T2qQREDAgUq2C7j9yfaPemQ= =hGK0 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] rmmod notifier chain
"Jan Beulich" <[EMAIL PROTECTED]> wrote: > > >>> Christoph Hellwig <[EMAIL PROTECTED]> 08.09.05 17:16:24 >>> > >On Thu, Sep 08, 2005 at 05:03:58PM +0200, Jan Beulich wrote: > >> (Note: Patch also attached because the inline version is certain to > get > >> line wrapped.) Suggest you get a new email setup. > ... > That's funny - on one hand I'm asked to not submit huge patches (not by > you, but by others), but on the other hand not having the consuming code > in the same patch as the providing one is now deemed to be a problem. Nope. Each patch should do a single logical thing. That doesn't mean that we want to trickle patches in across a period of months. It means that a bunch of spearate (and separately reviewed) patches can all go in at the same time. So the split-it-up request is for reviewing (and debugging) convenience only. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm2
On Thu, 8 Sep 2005 05:30:42 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2/ Hi Andrew, After this error: CC drivers/parport/parport_pc.o drivers/parport/parport_pc.c:2511: error: via_686a_data causes a section type conflict drivers/parport/parport_pc.c:2520: error: via_8231_data causes a section type conflict drivers/parport/parport_pc.c:2705: error: parport_pc_superio_info causes a section type conflict drivers/parport/parport_pc.c:2782: error: cards causes a section type conflict make[2]: *** [drivers/parport/parport_pc.o] Error 1 make[1]: *** [drivers/parport] Error 2 make: *** [drivers] Error 2 got this: [EMAIL PROTECTED]:/opt/linux/linux-2.6.13-mm2a$ make menuconfig HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o HOSTCC scripts/kconfig/mconf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/mconf HOSTCC scripts/lxdialog/checklist.o HOSTCC scripts/lxdialog/inputbox.o HOSTCC scripts/lxdialog/lxdialog.o HOSTCC scripts/lxdialog/menubox.o HOSTCC scripts/lxdialog/msgbox.o HOSTCC scripts/lxdialog/textbox.o HOSTCC scripts/lxdialog/util.o HOSTCC scripts/lxdialog/yesno.o HOSTLD scripts/lxdialog/lxdialog scripts/kconfig/mconf arch/i386/Kconfig Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP IEEE80211_CRYPT_WEP CRYPTO CRYPTO_ANUBIS Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP IEEE80211_CRYPT_WEP CRYPTO CRYPTO_MD4 Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP IEEE80211_CRYPT_WEP CRYPTO CRYPTO_MD5 Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP IEEE80211_CRYPT_WEP CRYPTO CRYPTO_AES_X86_64 Warning! Found recursive dependency: NET_RADIO HOSTAP IEEE80211 NET_RADIO HERMES TMD_HERMES Warning! Found recursive dependency: HOSTAP IEEE80211 NET_RADIO HOSTAP HOSTAP_PCI Warning! Found recursive dependency: NET_RADIO HOSTAP IEEE80211 NET_RADIO WAVELAN # # using defaults found in .config # from this: http://bugsplatter.mine.nu/test/boxen/sempro/config-2.6.13-mm2a.gz and: http://bugsplatter.mine.nu/test/boxen/sempro/config-2.6.13-mm2b.gz when I tried again, slightly different config. I don't do wireless networking, clueless ;-) Grant. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] SUBCPUSETS: a resource control functionality using CPUSETS
On Thu, 8 Sep 2005 05:02:32 -0700 Paul Jackson <[EMAIL PROTECTED]> wrote: > These subcpusets, if I understand correctly, are a bit different > from ordinary cpusets. For instance, it seems one cannot make child > cpusets of them, and one cannot change most of their properties, > such as cpus, mems, cpu_exclusive, mem_exclusive, or notify_on_release. > > Also the mems and cpus of each subcpuset are required to be > exactly equal to the corresponding values of its parent. That's right. > One of my passions is to avoid special cases across API boundaries. > > I am proposing that you don't do subcpusets like this. > > Consider the following alternative I will call 'cpuset meters'. > > For each resource named 'R' (cpu and mem, for instance): > * Add a boolean flag 'meter_R' to each cpuset. If set, that R is >metered, for the tasks in that cpuset or any descendent cpuset. > * If a cpuset is metered, then files named meter_R_guar, meter_R_lim >and meter_R_cur appear in that cpuset to manage R's usage by tasks >in that cpuset and descendents. > * There are no additional rules that restrict the ability to change >various other cpuset properties such as cpus, mems, cpu_exclusive, >mem_exclusive, or notify_on_release, when a cpuset is metered. > * It might be that some (or by design all) resource controllers do >not allow nesting metered cpusets. I don't know. But one should >(if one has permission) be able to make child cpusets of a metered >cpuset, just like one can of any other cpuset. > * A metered cpuset might well have cpus or mems that are not the >same as its parent, just like an unmetered cpuset ordinarly does. Jackson-san's idea looks good for me because users don't need to create special cpusets (parents of subcpusets or subcpusets). >From the point of users, maybe they wouldn't like to create special cpusets. As for the resource controller that I've posted, it assumes that there are groups of tasks that share the same cpumasks/nodemasks, and that there are no hierarchy in that groups in order to make things easier. I'll investigate how I can attach the resource controller to the cpuset meters. > If I understand correctly, one could place a job that managed its > own child cpusets into a metered cpuset, but not into a subcpuset. > Even if you wanted to allow it, it seems jobs in subcpusets cannot > make child cpusets or modify the properties of their current cpuset. > Is that correct? Correct. Subcpusets can't make child cpusets, and they don't have cpumask/nodemask properties actually. Properties like cpumasks/nodemask of subcpusets are the same as their parent and subcpusets can't modify those properties. Thanks, KUROSAWA, Takahiro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
signal race tests
Resurfacing... I put together some "steamroller" race tests, that race a pair of operations (e.g., kill() and exit()) against each other, varying the start times of each operation in an attempt to find any destructive races between the two operations. There are but five pairs of operations coded up thus far, wanted to get thoughts and suggestions. (Forget about continuously varying the start time of three operations unless you are quite a bit more patient than am I -- it already takes several minutes to run some of the tests.) I have no idea where to put this, so, for the moment have attached a bzip2-ed tarball. This actually does find problems with the RCU'ed signal paths, and am thinking of solutions, none of which are particularly attractive. One is to "lock down" tasks that might receive the signal, but this gets complicated and ugly quickly. Another is to create a new per-task lock that must be held when changing the "shape" of the task -- RCU still protects the task list and the sighand structure, but the race with (say) reparenting is protected by the new lock. Thoughts? Thanx, Paul signaltorture.2005.09.08a.tar.bz2 Description: Binary data
Re: [PATCH] ppc: Merge tlb.h
On Sep 8, 2005, at 6:56 PM, Benjamin Herrenschmidt wrote: On Thu, 2005-09-08 at 16:11 -0500, Kumar Gala wrote: Merged tlb.h between asm-ppc32 and asm-ppc64 into asm-powerpc. Also, fixed a compiler warning in arch/ppc/mm/tlb.c since it was roughly related. Signed-off-by: Kumar K. Gala <[EMAIL PROTECTED]> Do we want to do that ? Replacing 2 different files with one split in #ifdef isn't a progress... As I said, I think we need two subdirs for the low level stuffs that is different, and that includes at this point all of the memory management related stuff. I understand, but I'm also not sure if its progress to duplicate a major of a file that is common. In this case it might be better handled by having specific versions per "sub-arch". I think the key is determining which files should be handled via sub-arch diffs and which should be handled via ifdef's in the file. Some cases like ppc_asm are so similar that it seems better to have a single file and ifdef the specific case. In addition, I'd appreciate if we could avoid touching ppc64 mm related files completely for a couple of weeks as I'm working on a fairly big patch that I'm really tired of having to rebase all the time ;) Will avoid touch any other mm related headers than :) - kumar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 8250.c: Fix to make 16C950 UARTs work
Currently serial8250_set_termios() refuses to program a baud rate larger
than uartclk/16. However the 16C950 supports baud rates up to uartclk/4.
This worked already with Linux 2.4 so the biggest part of this patch was
simply taken from there and adapted to 2.6.
I needed this to get a Socket Bluetooth CF Card to work with BlueZ under
2.6 (the card did work under 2.4 already).
I posted the patch a while ago on the BlueZ mailing list and got reports
that it works as it should for a number of people so one could consider
including it into the standard kernel - opinions?
Please CC me as I'm not subscribed to the list.
Mathias Adam
--- linux-2.6.13-org/drivers/serial/8250.c 2005-08-29 01:41:01.0
+0200
+++ linux-2.6.13/drivers/serial/8250.c 2005-09-09 02:16:49.0 +0200
@@ -1665,7 +1665,7 @@
struct uart_8250_port *up = (struct uart_8250_port *)port;
unsigned char cval, fcr = 0;
unsigned long flags;
- unsigned int baud, quot;
+ unsigned int baud, quot, max_baud;
switch (termios->c_cflag & CSIZE) {
case CS5:
@@ -1697,9 +1697,28 @@
/*
* Ask the core to calculate the divisor for us.
*/
- baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk/16);
+ MAX_baud = (up->port.type == PORT_16C950 ? port->uartclk/4 :
port->uartclk/16);
+ baud = uart_get_baud_rate(port, termios, old, 0, max_baud);
quot = serial8250_get_divisor(port, baud);
+ /*
+* 16C950 supports additional prescaler ratios between 1:16 and 1:4
+* thus increasing max baud rate to uartclk/4. The following was taken
+* from kernel 2.4 by Mathias Adam <[EMAIL PROTECTED]> to make the
Socket
+* Bluetooth CF Card work under 2.6.13.
+*/
+ if (up->port.type == PORT_16C950) {
+ unsigned int baud_base = port->uartclk/16;
+ if (baud <= port->uartclk/16)
+ serial_icr_write(up, UART_TCR, 0);
+ else if (baud <= port->uartclk/8) {
+ serial_icr_write(up, UART_TCR, 0x8);
+ } else if (baud <= port->uartclk/4) {
+ serial_icr_write(up, UART_TCR, 0x4);
+ } else
+ serial_icr_write(up, UART_TCR, 0);
+ }
+
/*
* Oxford Semi 952 rev B workaround
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linus Git tree - xfs.o broken?
Hi, I keep posting these messages in LKML because I get no answer from someone to not do it, or cause I dunno what to do with them. This is from Linus git tree - Current as per 6PM PDT. CC fs/xfs/linux-2.6/xfs_lrw.o CC fs/xfs/linux-2.6/xfs_super.o CC fs/xfs/linux-2.6/xfs_vfs.o CC fs/xfs/linux-2.6/xfs_vnode.o CC fs/xfs/support/move.o CC fs/xfs/support/uuid.o LD fs/xfs/xfs.o ld: fs/xfs/quota/: No such file: File format not recognized make[3]: *** [fs/xfs/xfs.o] Error 1 make[2]: *** [fs/xfs] Error 2 make[1]: *** [fs] Error 2 make[1]: Leaving directory `/root/linux-2.6' make: *** [stamp-build] Error 2 debian:~/linux-2.6# cd .. .Alejandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus Git tree - xfs.o broken?
On Thu, Sep 08, 2005 at 07:12:01PM -0600, Alejandro Bonilla Beeche wrote: > Hi, > ld: fs/xfs/quota/: No such file: File format not recognized > make[3]: *** [fs/xfs/xfs.o] Error 1 > make[2]: *** [fs/xfs] Error 2 > make[1]: *** [fs] Error 2 > make[1]: Leaving directory `/root/linux-2.6' > make: *** [stamp-build] Error 2 > debian:~/linux-2.6# cd .. Yes, fix is in progress. Sorry about that. cheers. -- Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 3c59x: read current link status from phy
On Fri, Sep 09, 2005 at 12:39:18AM +0200, Tommy Christensen wrote:
> --- linux-2.6.13-git8/drivers/net/3c59x.c-origFri Sep 9 00:05:49 2005
> +++ linux-2.6.13-git8/drivers/net/3c59x.c Fri Sep 9 00:13:55 2005
> @@ -1889,7 +1889,9 @@ vortex_timer(unsigned long data)
> {
> spin_lock_bh(>lock);
> mii_status = mdio_read(dev, vp->phys[0], 1);
> - mii_status = mdio_read(dev, vp->phys[0], 1);
> + if (!(mii_status & BMSR_LSTATUS))
> + /* Re-read to get actual link status */
> + mii_status = mdio_read(dev, vp->phys[0], 1);
> ok = 1;
> if (vortex_debug > 2)
> printk(KERN_DEBUG "%s: MII transceiver has
> status %4.4x.\n",
Any chance you could re-diff this to apply on top of the patch posted
earlier today by Neil Horman?
Thanks,
John
--
John W. Linville
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] module-init-tools: don't do '-' substitutions in depmod
On Thu, 2005-09-08 at 15:56 -0400, Bill Nottingham wrote: > The attached patch removes the '-' for '_' substitution from > depmod - this makes the names printed for modules in module.alias > match the actual names of the module files. Looks fine, thanks Bill! (Note: this is harmless, because modprobe canonicalizes them itself when reading the file anyway, so no change there). Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm2
I guess something else has changed since I tested the patch. I haven't
tried -mm2, but the current Linus tree I'm having trouble getting to boot
on my x86_64 machine atm ("soft lockup" in the e1000 driver setup).
Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [PATCH] add and handle NMI_VECTOR II
On Fri, Sep 09, 2005 at 02:20:45AM +0200, Andi Kleen wrote:
> On Thu, Sep 08, 2005 at 06:07:56PM +0200, Jan Beulich wrote:
> > (Note: Patch also attached because the inline version is certain to get
> > line wrapped.)
> >
> > Declare NMI_VECTOR and handle it in the IPI sending code.
>
> The earlier consensus was to just rename KDB_VECTOR to NMI vector.
>
> I added the following patch.
[...]
The patch was obviously half backed. Here's one that actually
compiles.
-Andi
Rename KDB_VECTOR to NMI_VECTOR
As a generic NMI IPI vector to be used by debuggers.
And clean up the ICR setup for that slightly (code is equivalent, but cleaner
now)
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/include/asm-x86_64/hw_irq.h
===
--- linux.orig/include/asm-x86_64/hw_irq.h
+++ linux/include/asm-x86_64/hw_irq.h
@@ -52,7 +52,7 @@ struct hw_interrupt_type;
#define ERROR_APIC_VECTOR 0xfe
#define RESCHEDULE_VECTOR 0xfd
#define CALL_FUNCTION_VECTOR 0xfc
-#define KDB_VECTOR 0xfb/* reserved for KDB */
+#define NMI_VECTOR 0xfb/* IPI NMIs for debugging */
#define THERMAL_APIC_VECTOR0xfa
/* 0xf9 free */
#define INVALIDATE_TLB_VECTOR_END 0xf8
Index: linux/include/asm-x86_64/ipi.h
===
--- linux.orig/include/asm-x86_64/ipi.h
+++ linux/include/asm-x86_64/ipi.h
@@ -29,11 +29,14 @@
* We use 'broadcast', CPU->CPU IPIs and self-IPIs too.
*/
-static inline unsigned int __prepare_ICR (unsigned int shortcut, int vector,
unsigned int dest)
+static inline unsigned int
+__prepare_ICR (unsigned int shortcut, int vector, unsigned int dest)
{
- unsigned int icr = APIC_DM_FIXED | shortcut | vector | dest;
- if (vector == KDB_VECTOR)
- icr = (icr & (~APIC_VECTOR_MASK)) | APIC_DM_NMI;
+ unsigned int icr = shortcut | dest;
+ if (vector == NMI_VECTOR)
+ icr |= APIC_DM_NMI;
+ else
+ icr |= APIC_DM_FIXED | vector;
return icr;
}
Index: linux/arch/x86_64/kernel/traps.c
===
--- linux.orig/arch/x86_64/kernel/traps.c
+++ linux/arch/x86_64/kernel/traps.c
@@ -931,7 +931,7 @@ void __init trap_init(void)
set_system_gate(IA32_SYSCALL_VECTOR, ia32_syscall);
#endif
- set_intr_gate(KDB_VECTOR, call_debug);
+ set_intr_gate(NMI_VECTOR, call_debug);
/*
* Should be a barrier for any external CPU state.
Index: linux/arch/x86_64/kernel/i8259.c
===
--- linux.orig/arch/x86_64/kernel/i8259.c
+++ linux/arch/x86_64/kernel/i8259.c
@@ -551,7 +551,7 @@ void __init init_IRQ(void)
int vector = FIRST_EXTERNAL_VECTOR + i;
if (i >= NR_IRQS)
break;
- if (vector != IA32_SYSCALL_VECTOR && vector != KDB_VECTOR) {
+ if (vector != IA32_SYSCALL_VECTOR && vector != NMI_VECTOR) {
set_intr_gate(vector, interrupt[i]);
}
}
Index: linux/arch/x86_64/kernel/smp.c
===
--- linux.orig/arch/x86_64/kernel/smp.c
+++ linux/arch/x86_64/kernel/smp.c
@@ -283,11 +283,6 @@ void flush_tlb_all(void)
on_each_cpu(do_flush_tlb_all, NULL, 1, 1);
}
-void smp_kdb_stop(void)
-{
- send_IPI_allbutself(KDB_VECTOR);
-}
-
/*
* this function sends a 'reschedule' IPI to another CPU.
* it goes straight through and wastes no time serializing
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm2
On Thu, Sep 08, 2005 at 07:30:01AM -0700, Martin J. Bligh wrote: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2/ > > > > (kernel.org propagation is slow. There's a temp copy at > > http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-mm2.bz2) > > > > > > > > - Added Andi's x86_64 tree, as separate patches > > > > - Added a driver for TI acx1xx cardbus wireless NICs > > > > - Large revamp of pcmcia suspend handling > > > > - Largeish v4l and DVB updates > > > > - Significant parport rework > > > > - Many tty drivers still won't compile > > > > - Lots of framebuffer driver updates > > > > - There are still many patches here for 2.6.14. We're doing pretty well > > with merging up the subsystem trees. ia64 and CIFS are still pending. > > x86_64 and several of Greg's trees (especially USB) aren't merged yet. > > Build fails on x86_64, at least, with this config: > http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64 > > arch/x86_64/pci/built-in.o(.init.text+0xa88): In function > `pci_acpi_scan_root': > : undefined reference to `pxm_to_node' > make: *** [.tmp_vmlinux1] Error 1 > 09/08/05-06:52:31 Build the kernel. Failed rc = 2 > 09/08/05-06:52:31 build: kernel build Failed rc = 1 > 09/08/05-06:52:31 command complete: (2) rc=126 > Failed and terminated the run I tried the config in my (non mm) tree and it compiled just fine. Must be some bad interaction with another patch in -mm* or a bad merge. The original patch that introduces it is ftp://ftp.firstfloor.org/pub/ak/x86_64/x86_64-2.6.13-1/patches/pci-pxm pxm_to_node for x86-64 is supposed to be declared in arch/x86_64/mm/srat.c Andrew? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix i386 condition to call nmi_watchdog_tick
On Thu, 8 Sep 2005, Jan Beulich wrote:
> diff -Npru 2.6.13/arch/i386/kernel/traps.c
> 2.6.13-i386-watchdog-active/arch/i386/kernel/traps.c
> --- 2.6.13/arch/i386/kernel/traps.c 2005-08-29 01:41:01.0
> +0200
> +++
> 2.6.13-i386-watchdog-active/arch/i386/kernel/traps.c 2005-09-01
> 14:04:35.0 +0200
> @@ -611,7 +611,7 @@ static void default_do_nmi(struct pt_reg
>* Ok, so this is none of the documented NMI sources,
>* so it must be the NMI watchdog.
>*/
> - if (nmi_watchdog) {
> + if (nmi_watchdog && nmi_active > 0) {
> nmi_watchdog_tick(regs);
> return;
> }
I dislike this patch, and it's not your fault. The reason being is that
there are a few systems (i have one such) which always reports "CPU stuck"
during watchdog setup but then eventually the watchdog starts ticking
during runtime. Unfortunately if this gets in you'll get lots of the
following;
Uhhuh. NMI received for unknown reason 00 on CPU 1.
Dazed and confused, but trying to continue
Do you have a strange power saving mode enabled?
Uhhuh. NMI received for unknown reason 21 on CPU 0.
So, before the patch can go in, the "CPU stuck" systems probably need
looking at. Since i have one, i'll have a look.
Thanks,
Zwane
Ps. why is NMI watchdog perpetually broken?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm2
Andrew Morton wrote: Parag, perhaps you could confirm that reverting that patch fixes things up? Sure - reverting the x86-64-ptrace-ia32-bp-fix patch fixes it. Roland - if seeing backtraces and register info for the failing programs is going to help you, please see the thread "2.6.13-mm1 X86_64: All 32bit programs segfault" Thanks Parag - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [PATCH] add and handle NMI_VECTOR
On Thu, Sep 08, 2005 at 06:07:56PM +0200, Jan Beulich wrote:
> (Note: Patch also attached because the inline version is certain to get
> line wrapped.)
>
> Declare NMI_VECTOR and handle it in the IPI sending code.
The earlier consensus was to just rename KDB_VECTOR to NMI vector.
I added the following patch.
-Andi
Rename KDB_VECTOR to NMI_VECTOR
As a generic NMI IPI vector to be used by debuggers.
And clean up the ICR setup for that slightly (code is equivalent, but cleaner
now)
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/include/asm-x86_64/hw_irq.h
===
--- linux.orig/include/asm-x86_64/hw_irq.h
+++ linux/include/asm-x86_64/hw_irq.h
@@ -52,7 +52,7 @@ struct hw_interrupt_type;
#define ERROR_APIC_VECTOR 0xfe
#define RESCHEDULE_VECTOR 0xfd
#define CALL_FUNCTION_VECTOR 0xfc
-#define KDB_VECTOR 0xfb/* reserved for KDB */
+#define NMI_VECTOR 0xfb/* IPI NMIs for debugging */
#define THERMAL_APIC_VECTOR0xfa
/* 0xf9 free */
#define INVALIDATE_TLB_VECTOR_END 0xf8
Index: linux/include/asm-x86_64/ipi.h
===
--- linux.orig/include/asm-x86_64/ipi.h
+++ linux/include/asm-x86_64/ipi.h
@@ -29,11 +29,14 @@
* We use 'broadcast', CPU->CPU IPIs and self-IPIs too.
*/
-static inline unsigned int __prepare_ICR (unsigned int shortcut, int vector,
unsigned int dest)
+static inline unsigned int
+__prepare_ICR (unsigned int shortcut, int vector, unsigned int dest)
{
- unsigned int icr = APIC_DM_FIXED | shortcut | vector | dest;
- if (vector == KDB_VECTOR)
- icr = (icr & (~APIC_VECTOR_MASK)) | APIC_DM_NMI;
+ unsigned int icr = shortcut | dest;
+ if (vector == NMI_VECTOR)
+ icr |= APIC_DM_DMI;
+ else
+ icr |= APIC_DM_FIXED | vector;
return icr;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Yet another RCU documentation update
Update RCU documentation based on discussions and review of RCU-based
tree patches. Add an introductory whatisRCU.txt file.
Signed-off-by: <[EMAIL PROTECTED]>
---
RTFP.txt | 36 ++
UP.txt| 73
checklist.txt | 23 -
rcu.txt | 48 +++
whatisRCU.txt | 902 ++
5 files changed, 1061 insertions(+), 21 deletions(-)
diff -urpNa -X dontdiff linux-2.6.13/Documentation/RCU/RTFP.txt
linux-2.6.13-RCUdoc/Documentation/RCU/RTFP.txt
--- linux-2.6.13/Documentation/RCU/RTFP.txt 2005-08-28 16:41:01.0
-0700
+++ linux-2.6.13-RCUdoc/Documentation/RCU/RTFP.txt 2005-09-07
11:50:09.0 -0700
@@ -2,7 +2,8 @@ Read the F-ing Papers!
This document describes RCU-related publications, and is followed by
-the corresponding bibtex entries.
+the corresponding bibtex entries. A number of the publications may
+be found at http://www.rdrop.com/users/paulmck/RCU/.
The first thing resembling RCU was published in 1980, when Kung and Lehman
[Kung80] recommended use of a garbage collector to defer destruction
@@ -113,6 +114,10 @@ describing how to make RCU safe for soft
and a paper describing SELinux performance with RCU [JamesMorris04b].
+2005 has seen further adaptation of RCU to realtime use, permitting
+preemption of RCU realtime critical sections [PaulMcKenney05a,
+PaulMcKenney05b].
+
Bibtex Entries
@article{Kung80
@@ -410,3 +415,32 @@ Oregon Health and Sciences University"
\url{http://www.livejournal.com/users/james_morris/2153.html}
[Viewed December 10, 2004]"
}
+
[EMAIL PROTECTED]
+,Author="Paul E. McKenney"
+,Title="{[RFC]} {RCU} and {CONFIG\_PREEMPT\_RT} progress"
+,month="May"
+,year="2005"
+,note="Available:
+\url{http://lkml.org/lkml/2005/5/9/185}
+[Viewed May 13, 2005]"
+,annotation="
+ First publication of working lock-based deferred free patches
+ for the CONFIG_PREEMPT_RT environment.
+"
+}
+
[EMAIL PROTECTED]
+,Author="Paul E. McKenney and Dipankar Sarma"
+,Title="Towards Hard Realtime Response from the Linux Kernel on SMP Hardware"
+,Booktitle="linux.conf.au 2005"
+,month="April"
+,year="2005"
+,address="Canberra, Australia"
+,note="Available:
+\url{http://www.rdrop.com/users/paulmck/RCU/realtimeRCU.2005.04.23a.pdf}
+[Viewed May 13, 2005]"
+,annotation="
+ Realtime turns into making RCU yet more realtime friendly.
+"
+}
diff -urpNa -X dontdiff linux-2.6.13/Documentation/RCU/UP.txt
linux-2.6.13-RCUdoc/Documentation/RCU/UP.txt
--- linux-2.6.13/Documentation/RCU/UP.txt 2005-08-28 16:41:01.0
-0700
+++ linux-2.6.13-RCUdoc/Documentation/RCU/UP.txt2005-09-07
11:50:09.0 -0700
@@ -8,7 +8,7 @@ is that since there is only one CPU, it
wait for anything else to get done, since there are no other CPUs for
anything else to be happening on. Although this approach will -sort- -of-
work a surprising amount of the time, it is a very bad idea in general.
-This document presents two examples that demonstrate exactly how bad an
+This document presents three examples that demonstrate exactly how bad an
idea this is.
@@ -26,6 +26,9 @@ from softirq, the list scan would find i
element B. This situation can greatly decrease the life expectancy of
your kernel.
+This same problem can occur if call_rcu() is invoked from a hardware
+interrupt handler.
+
Example 2: Function-Call Fatality
@@ -44,8 +47,37 @@ its arguments would cause it to fail to
underlying RCU, namely that call_rcu() defers invoking its arguments until
all RCU read-side critical sections currently executing have completed.
-Quick Quiz: why is it -not- legal to invoke synchronize_rcu() in
-this case?
+Quick Quiz #1: why is it -not- legal to invoke synchronize_rcu() in
+ this case?
+
+
+Example 3: Death by Deadlock
+
+Suppose that call_rcu() is invoked while holding a lock, and that the
+callback function must acquire this same lock. In this case, if
+call_rcu() were to directly invoke the callback, the result would
+be self-deadlock.
+
+In some cases, it would possible to restructure to code so that
+the call_rcu() is delayed until after the lock is released. However,
+there are cases where this can be quite ugly:
+
+1. If a number of items need to be passed to call_rcu() within
+ the same critical section, then the code would need to create
+ a list of them, then traverse the list once the lock was
+ released.
+
+2. In some cases, the lock will be held across some kernel API,
+ so that delaying the call_rcu() until the lock is released
+ requires that the data item be passed up via a common API.
+ It is far better to guarantee that callbacks are invoked
+ with no locks held than to have to modify such APIs to allow
+ arbitrary data items to be passed back up through them.
+
+If call_rcu() directly invokes the callback, painful locking restrictions
+or API changes would be required.
+
+Quick Quiz #2: What locking
Re: rc6 keeps hanging and blanking displays where rc4-mm1 works fine.
On Thu, 8 Sep 2005, Andrew Morton wrote:
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> > If you remember/save the good/bad commit ID's, you can restart the whole
> > process and just feed the correct state for the ID's:
> >
> > git bisect start
> > git bisect bad v2.6.13-rc5
> > git bisect good v2.6.13-rc4
> > .. here bisect will start narrowing things down ..
> > git bisect bad
> > git bisect good
> > ..
>
> What do you suggest should be done if you hit a compile error partway
> through the bisection search? Is there some way to go forward or backward
> a few csets while keeping the search markers sane?
Hmm.. There's no really nice interface for doing it, but since bisection
uses a perfectly normal git branch (it's a special "bisect" branch) you
can use other git commands to move around the head of that branch and try
at any other point than the one it selected for you automatically.
In other words, you can "git reset" the head point of the branch to any
point you want to, and the only problem is to pick what point to try next
(since you don't want to mark the current point good or bad). One thing to
do is perhaps to just do:
git bisect visualize
which just starts "gitk" with the proper arguments that you can see what
we're currently looking at bisecting. Then you can pick a new point to
select as the bisection point by hand, and then do
git reset --hard
by just selecting that commit in gitk and pasting the result into that
"git reset --hard xyz.." command line.
("git reset --hard ..." will reset the current branch to the selected
point and force a checkout of the new state while its at it. It's pretty
much equivalent to "git reset ..." followed by a "git checkout -f").
Of course, you can pick the bisection point with any other means too. So
if you just do "git log" and you know what commit broke the compile, just
pick the father by hand.
The only important point is that you should obviously pick something that
is within the current known good/bad range, and that's where the
aforementioned "git bisect visualize" can help.
Oh, and the "git bisect visualize" thing is fairly new: if you have an
older version of git that doesn't have that nice helper function, you can
always do it by hand with the following magic command line.
gitk bisect/bad --not $(cd .git/refs && echo bisect/good-*)
(you can see how "git bisect visualize" is a bit simpler to type and
remember ;)
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: [PATCH] 3c59x: read current link status from phy
Tommy Christensen wrote: Andrew Morton wrote: Should we also decrease the polling interval? Perhaps only when the cable is unplugged? Sounds like a plan. 60 seconds certainly strikes me as being very slow. OTOH, I'm not aware of the reasoning behind this choice in the first place. It might make sense for some odd setups. Since I don't even have any HW to play around with, I think I'll step down for now. The standard for Becker drivers is 5 seconds if link is down, and 60 seconds if link is up, IIRC. 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: [PATCH] ppc: Merge tlb.h
On Thu, 2005-09-08 at 16:11 -0500, Kumar Gala wrote: > Merged tlb.h between asm-ppc32 and asm-ppc64 into asm-powerpc. Also, fixed > a compiler warning in arch/ppc/mm/tlb.c since it was roughly related. > > Signed-off-by: Kumar K. Gala <[EMAIL PROTECTED]> Do we want to do that ? Replacing 2 different files with one split in #ifdef isn't a progress... As I said, I think we need two subdirs for the low level stuffs that is different, and that includes at this point all of the memory management related stuff. In addition, I'd appreciate if we could avoid touching ppc64 mm related files completely for a couple of weeks as I'm working on a fairly big patch that I'm really tired of having to rebase all the time ;) Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 for link detection for R8169
Miroslaw Mieszczak <[EMAIL PROTECTED]> : > Francois Romieu napisał(a): > > >You can silence this message in 2.6.13 by using the 'msglvl' > >option of the ethtool command. > > It would be disabled only this message, or all warning messages from the > net driver? One issues 'ethtool msglvl xyz' where xyz is the bitwise OR of the messages which should be kept. The r8169 driver allows the same mask via the "debug" option of the module. The meaning of the bitflags is driver dependent. A summary of the messages for the r8169 driver is available at: http://www.zoreil.com/~romieu/r8169/doc/msglvl.txt -- 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/
[GIT PATCH] USB patches for 2.6.13
Here are a bunch of USB patches against your latest git tree. These have all been in the -mm tree for a number of weeks. They include a few new drivers, a rework of the usbnet drivers, and lots of bugfixes all around. Please pull from: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/ or if master.kernel.org hasn't synced up yet: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/ The full patches will be sent to the linux-usb-devel mailing lists, if anyone wants to see them. thanks, greg k-h Documentation/input/yealink.txt | 221 ++ MAINTAINERS |6 drivers/block/ub.c | 493 ++--- drivers/net/irda/irda-usb.c | 13 drivers/usb/atm/cxacru.c|2 drivers/usb/class/Kconfig | 21 drivers/usb/class/usblp.c |9 drivers/usb/core/Makefile |4 drivers/usb/core/devio.c| 116 + drivers/usb/core/hcd.h |8 drivers/usb/core/hub.c | 115 - drivers/usb/core/hub.h |7 drivers/usb/core/inode.c|9 drivers/usb/core/message.c |8 drivers/usb/core/urb.c | 26 drivers/usb/core/usb.c | 35 drivers/usb/core/usb.h |5 drivers/usb/gadget/ether.c | 33 drivers/usb/gadget/file_storage.c | 33 drivers/usb/gadget/gadget_chips.h | 55 drivers/usb/gadget/serial.c | 51 drivers/usb/gadget/zero.c | 48 drivers/usb/host/ehci-q.c |7 drivers/usb/host/ehci-sched.c |4 drivers/usb/host/ehci.h |2 drivers/usb/host/isp116x-hcd.c | 88 drivers/usb/host/ohci-ppc-soc.c | 24 drivers/usb/host/ohci-s3c2410.c |4 drivers/usb/input/Kconfig | 14 drivers/usb/input/Makefile |1 drivers/usb/input/hid-core.c|9 drivers/usb/input/keyspan_remote.c |5 drivers/usb/input/map_to_7segment.h | 189 ++ drivers/usb/input/yealink.c | 1023 ++ drivers/usb/input/yealink.h | 220 ++ drivers/usb/misc/auerswald.c|3 drivers/usb/misc/ldusb.c|6 drivers/usb/misc/sisusbvga/sisusb.c |4 drivers/usb/misc/usbtest.c |2 drivers/usb/mon/Makefile|2 drivers/usb/mon/mon_dma.c | 55 drivers/usb/mon/mon_text.c | 35 drivers/usb/mon/usb_mon.h |4 drivers/usb/net/Kconfig | 302 +-- drivers/usb/net/Makefile|8 drivers/usb/net/asix.c | 948 ++ drivers/usb/net/catc.c |2 drivers/usb/net/cdc_ether.c | 509 + drivers/usb/net/cdc_subset.c| 335 +++ drivers/usb/net/gl620a.c| 407 drivers/usb/net/kaweth.c|1 drivers/usb/net/net1080.c | 622 ++ drivers/usb/net/pegasus.c |1 drivers/usb/net/plusb.c | 156 + drivers/usb/net/rndis_host.c| 615 ++ drivers/usb/net/rtl8150.c |1 drivers/usb/net/usbnet.c| 3372 +--- drivers/usb/net/usbnet.h| 195 ++ drivers/usb/net/zaurus.c| 386 drivers/usb/net/zd1201.c|1 drivers/usb/serial/cypress_m8.c | 253 +- drivers/usb/serial/ftdi_sio.c | 56 drivers/usb/serial/ftdi_sio.h | 54 drivers/usb/serial/keyspan.c|8 drivers/usb/serial/option.c | 203 -- drivers/usb/serial/pl2303.c |6 drivers/usb/serial/usb-serial.c | 24 drivers/usb/storage/Kconfig | 12 drivers/usb/storage/Makefile|1 drivers/usb/storage/onetouch.c | 234 ++ drivers/usb/storage/onetouch.h |9 drivers/usb/storage/scsiglue.c |8 drivers/usb/storage/shuttle_usbat.c | 101 - drivers/usb/storage/transport.c | 17 drivers/usb/storage/unusual_devs.h | 19 drivers/usb/storage/usb.c | 79 drivers/usb/storage/usb.h |1 include/linux/usb.h | 11 include/linux/usb_isp116x.h | 30 sound/usb/usbaudio.c| 10 80 files changed, 7673 insertions(+), 4343 deletions(-) -- Adrian Bunk: USB: schedule OSS USB drivers for removal Alan Stern: USB: Fix regression in core/devio.c USB: URB_ASYNC_UNLINK flag removed from the kernel USB: Code motion in the hub driver USB: Disconnect children when unbinding the hub driver USB: Add timeout to usb_lock_device_for_reset USB: Support unbinding of the usb_generic driver Alexey Dobriyan: USB ldusb: fmt warnings fixes for 64-bit platforms Andrew de Quincey: USB: Prevent hid-core claiming Apple Bluetooth device on new G4 powerbooks Andrew Morton: USB: option card driver coding style tweaks Ben Dooks: USB: S3C24XX port numbering fix Dale Farnsworth: USB: Fix typo in
Re: rc6 keeps hanging and blanking displays where rc4-mm1 works fine.
Linus Torvalds <[EMAIL PROTECTED]> wrote: > > If you remember/save the good/bad commit ID's, you can restart the whole > process and just feed the correct state for the ID's: > > git bisect start > git bisect bad v2.6.13-rc5 > git bisect good v2.6.13-rc4 > .. here bisect will start narrowing things down .. > git bisect bad > git bisect good > .. What do you suggest should be done if you hit a compile error partway through the bisection search? Is there some way to go forward or backward a few csets while keeping the search markers sane? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
fbdev status (was Re: kernel status, 5 Sep 2005)
Andrew Morton wrote: > > [Bugme-new] [Bug 5059] New: intelfb - do not keep console resolution > http://bugzilla.kernel.org/show_bug.cgi?id=5059 Fixed in 2.6.13 > > [Bugme-new] [Bug 5130] New: atyfb driver kernel panic on boot on > http://bugzilla.kernel.org/show_bug.cgi?id=5130 Not really a bug, more of a misconfigured kernel. This bug is closed. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm2
[EMAIL PROTECTED] (Ronny V. Vindenes) wrote: > > x86-64-ptrace-ia32-bp-fix.patch breaks all 32bit apps for me on Athlon64 Great, thanks muchly for working that out. Parag, perhaps you could confirm that reverting that patch fixes things 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: [patch] Fix compilation in locomo.c
On Tue, September 6, 2005 9:11 am, Richard Purdie said: > On Sun, 2005-09-04 at 11:33 +0100, Russell King wrote: >> On Tue, Jul 26, 2005 at 08:30:43AM +0200, Pavel Machek wrote: >> > Do not access children in struct device directly, use >> > device_for_each_child helper instead. It fixes compilation. >> > >> > Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> >> >> Given up waiting for John/Richard to okay this, applied anyway. > > You did get a response from me on 20/8/05 which said: > > "Locomo is outside my area of expertise and its not present on the > devices I use/maintain, hence this is something John would have the > definitive opinion on. The patch looks sane to me though." > > I suspect John is between email addresses at the moment. Hopefully he'll > be back with us soon. Yeah... I'm now back but haven't yet had a chance to look at any patches or anything that has been floating around. Next week I will look closer at these patches (even if they have already been applied). John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] W1 patches for 2.6.13
Hi Greg, > Here are some w1 patches that have been in the -mm tree for a while. > They add a new driver, and fix up the netlink logic a lot. They also > add a crc16 implementation that is needed. adding the CRC-16 is very cool. I was just about to submit one by my own, because it is also needed for the Bluetooth L2CAP retransmission and flow control support. What about the 1-Wire notes inside the CRC-16 code. This suppose to be generic code and so this doesn't belong there. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Add suspend/resume support to locomo.c
On Tue, September 6, 2005 2:58 am, Pavel Machek said: > Hi! > >> > From: John Lenz <[EMAIL PROTECTED]> >> > >> > This adds low-level suspend/resume support to locomo.c. >> > >> > Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> >> >> Shouldn't this be signed off by John himself? Not applied. > > Well, it would be nice if it was signed off by him, but John is > nowhere to be reached. Sorry. I have been away from the internet (somewhat unexpectedly) the past three weeks... so I am not up to date on what has been happening. For the near future as I try and come back up to speed, patches can be applied from Pavel. Pavel, perhaps you could send me an email about what you (and others) have done the past few weeks? The patches on my site and such are probably a ways out of date. What/where is the latest code located? What progress has been made... Hopefully sometime next week I can start working on this stuff again. Thanks, John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm2
Andrew Morton <[EMAIL PROTECTED]> writes: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2/ > > (kernel.org propagation is slow. There's a temp copy at > http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-mm2.bz2) > > > > - Added Andi's x86_64 tree, as separate patches > > - Added a driver for TI acx1xx cardbus wireless NICs > > - Large revamp of pcmcia suspend handling > > - Largeish v4l and DVB updates > > - Significant parport rework > > - Many tty drivers still won't compile > > - Lots of framebuffer driver updates > > - There are still many patches here for 2.6.14. We're doing pretty well > with merging up the subsystem trees. ia64 and CIFS are still pending. > x86_64 and several of Greg's trees (especially USB) aren't merged yet. > x86-64-ptrace-ia32-bp-fix.patch breaks all 32bit apps for me on Athlon64 -- Ronny V. Vindenes <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: can't boot 2.6.13
Thanks, Eric. Anyone have any ideas why my cciss based system won't boot? mikem > -Original Message- > From: Moore, Eric Dean [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 08, 2005 5:52 PM > To: Miller, Mike (OS Dev); linux-kernel@vger.kernel.org; > linux-scsi@vger.kernel.org > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: can't boot 2.6.13 > > On Thursday, September 08, 2005 3:19 PM, Mike Miller(HP) wrote: > > I am not able to boot the 2.6.13 version of the kernel. I've tried > > different systems, tried downloading again, still nothing. > Here's the > > last thing I see from the serial port: > > > > md: Autodetecting RAID arrays. > > md: autorun ... > > md: ... autorun DONE. > > RAMDISK: Compressed image found at block 0 > > input: AT Translated Set 2 keyboard on isa0060/serio0 > > VFS: Mounted root (ext2 filesystem). > > logips2pp: Detected unknown logitech mouse model 1 > > input: PS/2 Logitech Mouse on isa0060/serio1 SCSI subsystem > > initialized Fusion MPT base driver 3.03.02 Copyright (c) > 1999-2005 LSI > > Logic Corporation > > > > We introduced split drivers for 2.6.13. There are new layer > drivers that sit ontop of mptscsih.ko. These drivers are > split along bus protocal, so there is mptspi.ko, mptfc.ko, > and mptsas.ko. This is to tie into the scsi transport layers > that are split the same. > > For 1030(a SPI controller) > If your using RedHat, you need to change mptscish to mptspi > in /etc/modprobe.conf. > If your using SuSE, you need to change mptscish to mptspi in > /etc/sysconfig/kernel > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] 3c59x: read current link status from phy
Andrew Morton wrote: Should we also decrease the polling interval? Perhaps only when the cable is unplugged? Sounds like a plan. 60 seconds certainly strikes me as being very slow. OTOH, I'm not aware of the reasoning behind this choice in the first place. It might make sense for some odd setups. Since I don't even have any HW to play around with, I think I'll step down for now. -Tommy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: can't boot 2.6.13
On Thursday, September 08, 2005 3:19 PM, Mike Miller(HP) wrote: > I am not able to boot the 2.6.13 version of the kernel. I've > tried different systems, tried downloading again, still > nothing. Here's the last thing I see from the serial port: > > md: Autodetecting RAID arrays. > md: autorun ... > md: ... autorun DONE. > RAMDISK: Compressed image found at block 0 > input: AT Translated Set 2 keyboard on isa0060/serio0 > VFS: Mounted root (ext2 filesystem). > logips2pp: Detected unknown logitech mouse model 1 > input: PS/2 Logitech Mouse on isa0060/serio1 > SCSI subsystem initialized > Fusion MPT base driver 3.03.02 > Copyright (c) 1999-2005 LSI Logic Corporation > We introduced split drivers for 2.6.13. There are new layer drivers that sit ontop of mptscsih.ko. These drivers are split along bus protocal, so there is mptspi.ko, mptfc.ko, and mptsas.ko. This is to tie into the scsi transport layers that are split the same. For 1030(a SPI controller) If your using RedHat, you need to change mptscish to mptspi in /etc/modprobe.conf. If your using SuSE, you need to change mptscish to mptspi in /etc/sysconfig/kernel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ckrm-tech] Re: [PATCH 0/5] SUBCPUSETS: a resource control functionality using CPUSETS
On Thu, 2005-09-08 at 18:44 +0530, Dinakar Guniguntala wrote: > Interesting implementation of resource controls. Cross posting this I second this :) Browsed a little through the docs/patches... seems to fit very well into a resource management solution (hint CKRM :) than CPUSET (resource isolation). I can see the usefulness of resource management inside CPUSET. We have had discussions earlier(in lkml and lse-tech) about how CKRM can play inside a CPUSET, and this plays directly into that, providing resource management inside a CPUSET. The parameters used, guarantee and limit, fits very well into CKRM's shares usage model. Takahiro-san, How much effort you think will be needed to make this work under CKRM. thanks. > to ckrm-tech as well. I am sure CKRM folks have something to say... > > Any thoughts about how you want to add more resource control features > on top of/in addition to this setup. (Such as memory etc) > > > On Thu, Sep 08, 2005 at 12:23:23AM -0700, Paul Jackson wrote: > > I'm guessing you do not want such cpusets (the parents of subcpusets) > > to overlap, because if they did, it would seem to confuse the meaning > > of getting a fixed proportion of available cpu and memory resources. I > > was a little surprised not to see any additional checks that > > cpu_exclusive and mem_exclusive must be set true in these cpusets, to > > insure non- overlapping cpusets. > > I agree with Paul here. You would want to build your controllers > on top of exclusive cpusets to keep things sane. > > > On the other hand, Dinakar had more work to do than you might, because > > he needed a complete covering (so had to round up cpus in non exclusive > > cpusets to form more covering elements). From what I can tell, you > > don't need a complete covering - it seems fine if some cpus are not > > managed by this resource control function. > > > I think it makes more sense to add this functionality directly as part > of the existing cpusets instead of creating further leaf cpusets (or > subcpusets > as you call it) where we can specify resource control parameters. I think > that > approach would be much more intuitive and simple to work with rather than > what you have currently. > > -Dinakar > > > --- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > ___ > ckrm-tech mailing list > https://lists.sourceforge.net/lists/listinfo/ckrm-tech > -- -- Chandra Seetharaman | Be careful what you choose - [EMAIL PROTECTED] | ...you may get it. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
On Thu, September 8, 2005 4:18 pm, Bill Davidsen said: > Is "maintain your own operating system" really better in your mind? Does > that sound like a viable alternative? No, that's a false choice. You folks just need to convince your distribution to apply the patches you "need" or create your own distribution. That does not mean this cruft should be in the mainline kernel. > It's not old hardware that's the problem, it's new hardware which isn't > supported. And unlike desktops, there's a lot less in the way of > hardware options on a lappie, you take what you get, you get what you > can afford, and often that means running on what someone else chooses. So? Cheers, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] 3c59x: read current link status from phy
Tommy Christensen <[EMAIL PROTECTED]> wrote: > > In order to spare some I/O operations, be more intelligent about > when to read from the PHY. Seems sane. Should we also decrease the polling interval? Perhaps only when the cable is unplugged? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] 3c59x: read current link status from phy
Bogdan Costescu wrote:
I now understood what the problem was, so I'll put it in words for
posterity: the Link Status bit of the MII Status register needs to be
read twice to first clear the error state (link bit=0) after which the
bit reports the actual value of the link. From the manual:
Yes, this is exactly the point.
But I still don't agree with your solution: you are reading the Status
register twice in all cases, which is wrong. What you want is to read it
a second time only after the link was marked as down: a simple check if
bit 2 of the Status register is 0, in which case you issue the second
read. This still means that there will be 2 reads if the link remains
down, but at least there is only 1 read for the case where the link is
up and remains up.
I don't think this makes much of a difference in the big picture, but
you're certainly right: let's not waste more cycles than we have to.
Can we agree on the patch below?
-Tommy
[3c59x] Avoid blindly reading link status twice
In order to spare some I/O operations, be more intelligent about
when to read from the PHY.
Pointed out by Bogdan Costescu.
Signed-off-by: Tommy S. Christensen <[EMAIL PROTECTED]>
--- linux-2.6.13-git8/drivers/net/3c59x.c-orig Fri Sep 9 00:05:49 2005
+++ linux-2.6.13-git8/drivers/net/3c59x.c Fri Sep 9 00:13:55 2005
@@ -1889,7 +1889,9 @@ vortex_timer(unsigned long data)
{
spin_lock_bh(>lock);
mii_status = mdio_read(dev, vp->phys[0], 1);
- mii_status = mdio_read(dev, vp->phys[0], 1);
+ if (!(mii_status & BMSR_LSTATUS))
+ /* Re-read to get actual link status */
+ mii_status = mdio_read(dev, vp->phys[0], 1);
ok = 1;
if (vortex_debug > 2)
printk(KERN_DEBUG "%s: MII transceiver has
status %4.4x.\n",
[PATCH] w1: Detouching bug fixed.
[PATCH] w1: Detouching bug fixed.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
commit 3aca692d3ec7cf89da4575f598e41f74502b22d7
tree 84740dbcf1ea648b303020f2106e7f9e46f92835
parent d2a4ef6a0ce4d841293b49bf2cdc17a0ebfaaf9d
author Evgeniy Polyakov <[EMAIL PROTECTED]> Thu, 11 Aug 2005 17:27:50 +0400
committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 08 Sep 2005 14:41:26 -0700
drivers/w1/w1.c | 93 +++
drivers/w1/w1.h |3 +-
drivers/w1/w1_int.c |6 +--
3 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -45,10 +45,12 @@ MODULE_AUTHOR("Evgeniy Polyakov dev_released);
+
+ dev_dbg(dev, "%s: Releasing %s.\n", __func__, md->name);
+
+ if (md->nls && md->nls->sk_socket)
+ sock_release(md->nls->sk_socket);
+ memset(md, 0, sizeof(struct w1_master) + sizeof(struct w1_bus_master));
+ kfree(md);
}
static void w1_slave_release(struct device *dev)
{
struct w1_slave *sl = dev_to_w1_slave(dev);
- complete(>dev_released);
+
+ dev_dbg(dev, "%s: Releasing %s.\n", __func__, sl->name);
+
+ while (atomic_read(>refcnt)) {
+ dev_dbg(dev, "Waiting for %s to become free: refcnt=%d.\n",
+ sl->name, atomic_read(>refcnt));
+ if (msleep_interruptible(1000))
+ flush_signals(current);
+ }
+
+ w1_family_put(sl->family);
+ sl->master->slave_count--;
+
+ complete(>released);
}
static ssize_t w1_slave_read_name(struct device *dev, struct device_attribute
*attr, char *buf)
{
- struct w1_slave *sl = dev_to_w1_slave(dev);
+ struct w1_slave *sl = dev_to_w1_slave(dev);
- return sprintf(buf, "%s\n", sl->name);
+ return sprintf(buf, "%s\n", sl->name);
}
static ssize_t w1_slave_read_id(struct kobject *kobj, char *buf, loff_t off,
size_t count)
{
- struct w1_slave *sl = kobj_to_w1_slave(kobj);
+ struct w1_slave *sl = kobj_to_w1_slave(kobj);
- atomic_inc(>refcnt);
- if (off > 8) {
- count = 0;
+ atomic_inc(>refcnt);
+ if (off > 8) {
+ count = 0;
} else {
if (off + count > 8)
count = 8 - off;
@@ -109,7 +125,7 @@ static ssize_t w1_slave_read_id(struct k
atomic_dec(>refcnt);
return count;
- }
+}
static struct device_attribute w1_slave_attr_name =
__ATTR(name, S_IRUGO, w1_slave_read_name, NULL);
@@ -139,7 +155,6 @@ struct device_driver w1_master_driver =
.name = "w1_master_driver",
.bus = _bus_type,
.probe = w1_master_probe,
- .remove = w1_master_remove,
};
struct device w1_master_device = {
@@ -160,6 +175,7 @@ struct device w1_slave_device = {
.bus = _bus_type,
.bus_id = "w1 bus slave",
.driver = _slave_driver,
+ .release = _slave_release
};
static ssize_t w1_master_attribute_show_name(struct device *dev, struct
device_attribute *attr, char *buf)
@@ -406,8 +422,7 @@ static int __w1_attach_slave_device(stru
(unsigned int) sl->reg_num.family,
(unsigned long long) sl->reg_num.id);
- dev_dbg(>dev, "%s: registering %s.\n", __func__,
- >dev.bus_id[0]);
+ dev_dbg(>dev, "%s: registering %s as %p.\n", __func__,
>dev.bus_id[0]);
err = device_register(>dev);
if (err < 0) {
@@ -480,7 +495,7 @@ static int w1_attach_slave_device(struct
memcpy(>reg_num, rn, sizeof(sl->reg_num));
atomic_set(>refcnt, 0);
- init_completion(>dev_released);
+ init_completion(>released);
spin_lock(_flock);
f = w1_family_registered(rn->family);
@@ -512,6 +527,8 @@ static int w1_attach_slave_device(struct
msg.type = W1_SLAVE_ADD;
w1_netlink_send(dev, );
+ dev_info(>dev, "Finished %s for sl=%p.\n", __func__, sl);
+
return 0;
}
@@ -519,29 +536,23 @@ static void w1_slave_detach(struct w1_sl
{
struct w1_netlink_msg msg;
- dev_info(>dev, "%s: detaching %s.\n", __func__, sl->name);
+ dev_info(>dev, "%s: detaching %s [%p].\n", __func__, sl->name, sl);
- while (atomic_read(>refcnt)) {
- printk(KERN_INFO "Waiting for %s to become free: refcnt=%d.\n",
- sl->name, atomic_read(>refcnt));
-
- if (msleep_interruptible(1000))
- flush_signals(current);
- }
+ list_del(>w1_slave_entry);
if (sl->family->fops && sl->family->fops->remove_slave)
sl->family->fops->remove_slave(sl);
+ memcpy(, >reg_num, sizeof(msg.id.id));
+ msg.type = W1_SLAVE_REMOVE;
+ w1_netlink_send(sl->master, );
+
sysfs_remove_bin_file(>dev.kobj, _slave_attr_bin_id);
[PATCH] w1: Decreased debug level.
[PATCH] w1: Decreased debug level.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
commit 7c8f5703de91ade517d4fd6c3cc8e08dbba2b739
tree aa01c3513c66569f9626a51978cd82b10fd6615e
parent 3aca692d3ec7cf89da4575f598e41f74502b22d7
author Evgeniy Polyakov <[EMAIL PROTECTED]> Thu, 11 Aug 2005 17:27:50 +0400
committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 08 Sep 2005 14:41:27 -0700
drivers/w1/w1.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -527,8 +527,6 @@ static int w1_attach_slave_device(struct
msg.type = W1_SLAVE_ADD;
w1_netlink_send(dev, );
- dev_info(>dev, "Finished %s for sl=%p.\n", __func__, sl);
-
return 0;
}
@@ -536,7 +534,7 @@ static void w1_slave_detach(struct w1_sl
{
struct w1_netlink_msg msg;
- dev_info(>dev, "%s: detaching %s [%p].\n", __func__, sl->name, sl);
+ dev_dbg(>dev, "%s: detaching %s [%p].\n", __func__, sl->name, sl);
list_del(>w1_slave_entry);
@@ -579,7 +577,7 @@ void w1_reconnect_slaves(struct w1_famil
spin_lock_bh(_mlock);
list_for_each_entry(dev, _masters, w1_master_entry) {
- dev_info(>dev, "Reconnecting slaves in %s into new family
%02x.\n",
+ dev_dbg(>dev, "Reconnecting slaves in %s into new family
%02x.\n",
dev->name, f->fid);
set_bit(W1_MASTER_NEED_RECONNECT, >flags);
}
@@ -768,7 +766,7 @@ static int w1_control(void *data)
}
if (test_bit(W1_MASTER_NEED_RECONNECT, >flags)) {
- dev_info(>dev, "Reconnecting slaves in
device %s.\n", dev->name);
+ dev_dbg(>dev, "Reconnecting slaves in
device %s.\n", dev->name);
down(>mutex);
list_for_each_entry_safe(sl, sln, >slist,
w1_slave_entry) {
if (sl->family->fid ==
W1_FAMILY_DEFAULT) {
@@ -780,7 +778,7 @@ static int w1_control(void *data)
w1_attach_slave_device(dev,
);
}
}
- dev_info(>dev, "Reconnecting slaves in
device %s has been finished.\n", dev->name);
+ dev_dbg(>dev, "Reconnecting slaves in
device %s has been finished.\n", dev->name);
clear_bit(W1_MASTER_NEED_RECONNECT,
>flags);
up(>mutex);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] w1: Added w1_reset_select_slave() - Resets the bus and then selects the slave by
[PATCH] w1: Added w1_reset_select_slave() - Resets the bus and then selects the
slave by
sending either a skip rom or a rom match.
Patch from Ben Gardner <[EMAIL PROTECTED]>
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
commit ea7d8f65c865ebfa1d7cd67c360a87333ff013c1
tree 1e687c32d53a92c10a61fb23ab14763459ff5779
parent db2d0008de519c5db6baec45f7831e08790301cf
author Evgeniy Polyakov <[EMAIL PROTECTED]> Thu, 11 Aug 2005 17:27:49 +0400
committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 08 Sep 2005 14:41:26 -0700
drivers/w1/w1_io.c| 24
drivers/w1/w1_io.h|1 +
drivers/w1/w1_therm.c | 11 ++-
3 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/w1/w1_io.c b/drivers/w1/w1_io.c
--- a/drivers/w1/w1_io.c
+++ b/drivers/w1/w1_io.c
@@ -277,6 +277,29 @@ void w1_search_devices(struct w1_master
w1_search(dev, cb);
}
+/**
+ * Resets the bus and then selects the slave by sending either a skip rom
+ * or a rom match.
+ * The w1 master lock must be held.
+ *
+ * @param sl the slave to select
+ * @return 0=success, anything else=error
+ */
+int w1_reset_select_slave(struct w1_slave *sl)
+{
+ if (w1_reset_bus(sl->master))
+ return -1;
+
+ if (sl->master->slave_count == 1)
+ w1_write_8(sl->master, W1_SKIP_ROM);
+ else {
+ u8 match[9] = {W1_MATCH_ROM, };
+ memcpy([1], (u8 *)>reg_num, 8);
+ w1_write_block(sl->master, match, 9);
+ }
+ return 0;
+}
+
EXPORT_SYMBOL(w1_touch_bit);
EXPORT_SYMBOL(w1_write_8);
EXPORT_SYMBOL(w1_read_8);
@@ -286,3 +309,4 @@ EXPORT_SYMBOL(w1_delay);
EXPORT_SYMBOL(w1_read_block);
EXPORT_SYMBOL(w1_write_block);
EXPORT_SYMBOL(w1_search_devices);
+EXPORT_SYMBOL(w1_reset_select_slave);
diff --git a/drivers/w1/w1_io.h b/drivers/w1/w1_io.h
--- a/drivers/w1/w1_io.h
+++ b/drivers/w1/w1_io.h
@@ -34,5 +34,6 @@ u8 w1_calc_crc8(u8 *, int);
void w1_write_block(struct w1_master *, const u8 *, int);
u8 w1_read_block(struct w1_master *, u8 *, int);
void w1_search_devices(struct w1_master *dev, w1_slave_found_callback cb);
+int w1_reset_select_slave(struct w1_slave *sl);
#endif /* __W1_IO_H */
diff --git a/drivers/w1/w1_therm.c b/drivers/w1/w1_therm.c
--- a/drivers/w1/w1_therm.c
+++ b/drivers/w1/w1_therm.c
@@ -176,15 +176,10 @@ static ssize_t w1_therm_read_bin(struct
crc = 0;
while (max_trying--) {
- if (!w1_reset_bus (dev)) {
+ if (!w1_reset_select_slave(sl)) {
int count = 0;
- u8 match[9] = {W1_MATCH_ROM, };
unsigned int tm = 750;
- memcpy([1], (u64 *) & sl->reg_num, 8);
-
- w1_write_block(dev, match, 9);
-
w1_write_8(dev, W1_CONVERT_TEMP);
while (tm) {
@@ -193,8 +188,7 @@ static ssize_t w1_therm_read_bin(struct
flush_signals(current);
}
- if (!w1_reset_bus (dev)) {
- w1_write_block(dev, match, 9);
+ if (!w1_reset_select_slave(sl)) {
w1_write_8(dev, W1_READ_SCRATCHPAD);
if ((count = w1_read_block(dev, rom, 9)) != 9) {
@@ -205,7 +199,6 @@ static ssize_t w1_therm_read_bin(struct
if (rom[8] == crc && rom[0])
verdict = 1;
-
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] w1: Added DS2433 driver.
[PATCH] w1: Added DS2433 driver.
Work by Ben Gardner <[EMAIL PROTECTED]>.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
commit 80895392c83e54653540e72e7d40573aac7ee690
tree 3fb57983caf779f0648baebf18672f232a3c8c58
parent 7c8f5703de91ade517d4fd6c3cc8e08dbba2b739
author Evgeniy Polyakov <[EMAIL PROTECTED]> Thu, 11 Aug 2005 17:27:50 +0400
committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 08 Sep 2005 14:41:27 -0700
drivers/w1/Kconfig |7 ++
drivers/w1/Makefile|1
drivers/w1/w1_ds2433.c | 222
3 files changed, 230 insertions(+), 0 deletions(-)
diff --git a/drivers/w1/Kconfig b/drivers/w1/Kconfig
--- a/drivers/w1/Kconfig
+++ b/drivers/w1/Kconfig
@@ -54,4 +54,11 @@ config W1_SMEM
Say Y here if you want to connect 1-wire
simple 64bit memory rom(ds2401/ds2411/ds1990*) to you wire.
+config W1_DS2433
+ tristate "4kb EEPROM family support (DS2433)"
+ depends on W1
+ help
+ Say Y here if you want to use a 1-wire
+ 4kb EEPROM family device (DS2433).
+
endmenu
diff --git a/drivers/w1/Makefile b/drivers/w1/Makefile
--- a/drivers/w1/Makefile
+++ b/drivers/w1/Makefile
@@ -18,3 +18,4 @@ ds9490r-objs:= dscore.o
obj-$(CONFIG_W1_DS9490_BRIDGE) += ds_w1_bridge.o
+obj-$(CONFIG_W1_DS2433)+= w1_ds2433.o
diff --git a/drivers/w1/w1_ds2433.c b/drivers/w1/w1_ds2433.c
new file mode 100644
--- /dev/null
+++ b/drivers/w1/w1_ds2433.c
@@ -0,0 +1,222 @@
+/*
+ * w1_ds2433.c - w1 family 23 (DS2433) driver
+ *
+ * Copyright (c) 2005 Ben Gardner <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the smems of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "w1.h"
+#include "w1_io.h"
+#include "w1_int.h"
+#include "w1_family.h"
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Ben Gardner <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("w1 family 23 driver for DS2433, 4kb EEPROM");
+
+#define W1_EEPROM_SIZE 512
+#define W1_PAGE_SIZE 32
+#define W1_PAGE_BITS 5
+#define W1_PAGE_MASK 0x1F
+
+#define W1_F23_READ_EEPROM 0xF0
+#define W1_F23_WRITE_SCRATCH 0x0F
+#define W1_F23_READ_SCRATCH0xAA
+#define W1_F23_COPY_SCRATCH0x55
+
+/**
+ * Check the file size bounds and adjusts count as needed.
+ * This may not be needed if the sysfs layer checks bounds.
+ */
+static inline size_t w1_f23_fix_count(loff_t off, size_t count, size_t size)
+{
+ if (off > size)
+ return 0;
+
+ if ((off + count) > size)
+ return (size - off);
+
+ return count;
+}
+
+static ssize_t w1_f23_read_bin(struct kobject *kobj, char *buf, loff_t off,
size_t count)
+{
+ struct w1_slave *sl = kobj_to_w1_slave(kobj);
+ u8 wrbuf[3];
+
+ if ((count = w1_f23_fix_count(off, count, W1_EEPROM_SIZE)) == 0)
+ return 0;
+
+ atomic_inc(>refcnt);
+ if (down_interruptible(>master->mutex)) {
+ count = 0;
+ goto out_dec;
+ }
+
+ /* read directly from the EEPROM */
+ if (w1_reset_select_slave(sl)) {
+ count = -EIO;
+ goto out_up;
+ }
+
+ wrbuf[0] = W1_F23_READ_EEPROM;
+ wrbuf[1] = off & 0xff;
+ wrbuf[2] = off >> 8;
+ w1_write_block(sl->master, wrbuf, 3);
+ w1_read_block(sl->master, buf, count);
+
+out_up:
+ up(>master->mutex);
+out_dec:
+ atomic_dec(>refcnt);
+
+ return count;
+}
+
+/**
+ * Writes to the scratchpad and reads it back for verification.
+ * The master must be locked.
+ *
+ * @param sl The slave structure
+ * @param addr Address for the write
+ * @param len length must be <= (W1_PAGE_SIZE - (addr & W1_PAGE_MASK))
+ * @param data The data to write
+ * @return 0=Success -1=failure
+ */
+static int w1_f23_write(struct w1_slave *sl, int addr, int len, const u8 *data)
+{
+ u8 wrbuf[4];
+ u8 rdbuf[W1_PAGE_SIZE + 3];
+ u8 es = (addr + len - 1) & 0x1f;
+
+ /* Write the data to the scratchpad */
+ if (w1_reset_select_slave(sl))
+ return -1;
+
+ wrbuf[0] = W1_F23_WRITE_SCRATCH;
+ wrbuf[1] = addr & 0xff;
+ wrbuf[2] = addr >> 8;
+
+ w1_write_block(sl->master, wrbuf, 3);
+ w1_write_block(sl->master, data, len);
+
+ /* Read the scratchpad and verify */
+ if (w1_reset_select_slave(sl))
+ return -1;
+
+ w1_write_8(sl->master, W1_F23_READ_SCRATCH);
+ w1_read_block(sl->master, rdbuf, len + 3);
+
+ /* Compare what was read against the data written */
+ if ((rdbuf[0] != wrbuf[1]) || (rdbuf[1] != wrbuf[2]) ||
+ (rdbuf[2] != es) || (memcmp(data, [3], len) != 0))
+ return -1;
+
+ /*
[PATCH] w1: hotplug support.
[PATCH] w1: hotplug support.
Here is W1 hotplug in addition to netlink notifications.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
commit 7f772ed8df27c6941952452330c618512389c4c7
tree 6ad8320e0ee8bd2f4709176381662460ec4b1e45
parent 8949d2aa05ddf5e9a31d738568a79915970cb38e
author Evgeniy Polyakov <[EMAIL PROTECTED]> Thu, 11 Aug 2005 13:20:07 +0400
committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 08 Sep 2005 14:41:26 -0700
drivers/w1/w1.c | 90 +--
drivers/w1/w1_int.c |6 ++-
2 files changed, 82 insertions(+), 14 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -125,27 +125,41 @@ static struct bin_attribute w1_slave_bin
.read = _default_read_bin,
};
+static int w1_hotplug(struct device *dev, char **envp, int num_envp, char
*buffer, int buffer_size);
static struct bus_type w1_bus_type = {
.name = "w1",
.match = w1_master_match,
+ .hotplug = w1_hotplug,
};
-struct device_driver w1_driver = {
- .name = "w1_driver",
+struct device_driver w1_master_driver = {
+ .name = "w1_master_driver",
.bus = _bus_type,
.probe = w1_master_probe,
.remove = w1_master_remove,
};
-struct device w1_device = {
+struct device w1_master_device = {
.parent = NULL,
.bus = _bus_type,
.bus_id = "w1 bus master",
- .driver = _driver,
+ .driver = _master_driver,
.release = _master_release
};
+struct device_driver w1_slave_driver = {
+ .name = "w1_slave_driver",
+ .bus = _bus_type,
+};
+
+struct device w1_slave_device = {
+ .parent = NULL,
+ .bus = _bus_type,
+ .bus_id = "w1 bus slave",
+ .driver = _slave_driver,
+};
+
static ssize_t w1_master_attribute_show_name(struct device *dev, struct
device_attribute *attr, char *buf)
{
struct w1_master *md = container_of(dev, struct w1_master, dev);
@@ -329,12 +343,55 @@ void w1_destroy_master_attributes(struct
sysfs_remove_group(>dev.kobj, _master_defattr_group);
}
+#ifdef CONFIG_HOTPLUG
+static int w1_hotplug(struct device *dev, char **envp, int num_envp, char
*buffer, int buffer_size)
+{
+ struct w1_master *md = NULL;
+ struct w1_slave *sl = NULL;
+ char *event_owner, *name;
+ int err, cur_index=0, cur_len=0;
+
+ if (dev->driver == _master_driver) {
+ md = container_of(dev, struct w1_master, dev);
+ event_owner = "master";
+ name = md->name;
+ } else if (dev->driver == _slave_driver) {
+ sl = container_of(dev, struct w1_slave, dev);
+ event_owner = "slave";
+ name = sl->name;
+ } else {
+ dev_dbg(dev, "Unknown hotplug event.\n");
+ return -EINVAL;
+ }
+
+ dev_dbg(dev, "Hotplug event for %s %s, bus_id=%s.\n", event_owner,
name, dev->bus_id);
+
+ if (dev->driver != _slave_driver || !sl)
+ return 0;
+
+ err = add_hotplug_env_var(envp, num_envp, _index, buffer,
buffer_size, _len, "W1_FID=%02X", sl->reg_num.family);
+ if (err)
+ return err;
+
+ err = add_hotplug_env_var(envp, num_envp, _index, buffer,
buffer_size, _len, "W1_SLAVE_ID=%024llX", sl->reg_num.id);
+ if (err)
+ return err;
+
+ return 0;
+};
+#else
+static int w1_hotplug(struct device *dev, char **envp, int num_envp, char
*buffer, int buffer_size)
+{
+ return 0;
+}
+#endif
+
static int __w1_attach_slave_device(struct w1_slave *sl)
{
int err;
sl->dev.parent = >master->dev;
- sl->dev.driver = sl->master->driver;
+ sl->dev.driver = _slave_driver;
sl->dev.bus = _bus_type;
sl->dev.release = _slave_release;
@@ -507,7 +564,6 @@ void w1_reconnect_slaves(struct w1_famil
spin_unlock_bh(_mlock);
}
-
static void w1_slave_found(unsigned long data, u64 rn)
{
int slave_count;
@@ -783,7 +839,7 @@ static int w1_init(void)
goto err_out_exit_init;
}
- retval = driver_register(_driver);
+ retval = driver_register(_master_driver);
if (retval) {
printk(KERN_ERR
"Failed to register master driver. err=%d.\n",
@@ -791,18 +847,29 @@ static int w1_init(void)
goto err_out_bus_unregister;
}
+ retval = driver_register(_slave_driver);
+ if (retval) {
+ printk(KERN_ERR
+ "Failed to register master driver. err=%d.\n",
+ retval);
+ goto err_out_master_unregister;
+ }
+
control_thread = kernel_thread(_control, NULL, 0);
if (control_thread < 0) {
printk(KERN_ERR "Failed to create control thread. err=%d\n",
control_thread);
[PATCH] W1: Sync with w1/ds9490 tree.
[PATCH] W1: Sync with w1/ds9490 tree.
Whitespace, static/nonstatic cleanups.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
commit 8949d2aa05ddf5e9a31d738568a79915970cb38e
tree bb5c18d4a5ff014a4a521fb5817ad231e8d0c81f
parent 2d8331792ea3f5ccfd147288afba148537337019
author Evgeniy Polyakov <[EMAIL PROTECTED]> Wed, 03 Aug 2005 15:14:50 +0400
committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 08 Sep 2005 14:41:26 -0700
drivers/w1/ds_w1_bridge.c | 24 +++
drivers/w1/dscore.c | 161 +++--
drivers/w1/dscore.h | 10 +--
3 files changed, 99 insertions(+), 96 deletions(-)
diff --git a/drivers/w1/ds_w1_bridge.c b/drivers/w1/ds_w1_bridge.c
--- a/drivers/w1/ds_w1_bridge.c
+++ b/drivers/w1/ds_w1_bridge.c
@@ -1,8 +1,8 @@
/*
- * ds_w1_bridge.c
+ * ds_w1_bridge.c
*
* Copyright (c) 2004 Evgeniy Polyakov <[EMAIL PROTECTED]>
- *
+ *
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -25,7 +25,7 @@
#include "../w1/w1.h"
#include "../w1/w1_int.h"
#include "dscore.h"
-
+
static struct ds_device *ds_dev;
static struct w1_bus_master *ds_bus_master;
@@ -120,7 +120,7 @@ static u8 ds9490r_reset(unsigned long da
static int __devinit ds_w1_init(void)
{
int err;
-
+
ds_bus_master = kmalloc(sizeof(*ds_bus_master), GFP_KERNEL);
if (!ds_bus_master) {
printk(KERN_ERR "Failed to allocate DS9490R USB<->W1 bus_master
structure.\n");
@@ -136,14 +136,14 @@ static int __devinit ds_w1_init(void)
memset(ds_bus_master, 0, sizeof(*ds_bus_master));
- ds_bus_master->data = (unsigned long)ds_dev;
- ds_bus_master->touch_bit= _touch_bit;
- ds_bus_master->read_bit = _read_bit;
- ds_bus_master->write_bit= _write_bit;
- ds_bus_master->read_byte= _read_byte;
- ds_bus_master->write_byte = _write_byte;
- ds_bus_master->read_block = _read_block;
- ds_bus_master->write_block = _write_block;
+ ds_bus_master->data = (unsigned long)ds_dev;
+ ds_bus_master->touch_bit= _touch_bit;
+ ds_bus_master->read_bit = _read_bit;
+ ds_bus_master->write_bit= _write_bit;
+ ds_bus_master->read_byte= _read_byte;
+ ds_bus_master->write_byte = _write_byte;
+ ds_bus_master->read_block = _read_block;
+ ds_bus_master->write_block = _write_block;
ds_bus_master->reset_bus= _reset;
err = w1_add_master_device(ds_bus_master);
diff --git a/drivers/w1/dscore.c b/drivers/w1/dscore.c
--- a/drivers/w1/dscore.c
+++ b/drivers/w1/dscore.c
@@ -1,8 +1,8 @@
/*
- * dscore.c
+ * dscore.c
*
* Copyright (c) 2004 Evgeniy Polyakov <[EMAIL PROTECTED]>
- *
+ *
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -32,19 +32,16 @@ static struct usb_device_id ds_id_table
};
MODULE_DEVICE_TABLE(usb, ds_id_table);
-int ds_probe(struct usb_interface *, const struct usb_device_id *);
-void ds_disconnect(struct usb_interface *);
+static int ds_probe(struct usb_interface *, const struct usb_device_id *);
+static void ds_disconnect(struct usb_interface *);
int ds_touch_bit(struct ds_device *, u8, u8 *);
int ds_read_byte(struct ds_device *, u8 *);
int ds_read_bit(struct ds_device *, u8 *);
int ds_write_byte(struct ds_device *, u8);
int ds_write_bit(struct ds_device *, u8);
-int ds_start_pulse(struct ds_device *, int);
-int ds_set_speed(struct ds_device *, int);
+static int ds_start_pulse(struct ds_device *, int);
int ds_reset(struct ds_device *, struct ds_status *);
-int ds_detect(struct ds_device *, struct ds_status *);
-int ds_stop_pulse(struct ds_device *, int);
struct ds_device * ds_get_device(void);
void ds_put_device(struct ds_device *);
@@ -79,11 +76,11 @@ void ds_put_device(struct ds_device *dev
static int ds_send_control_cmd(struct ds_device *dev, u16 value, u16 index)
{
int err;
-
- err = usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev,
dev->ep[EP_CONTROL]),
+
+ err = usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev,
dev->ep[EP_CONTROL]),
CONTROL_CMD, 0x40, value, index, NULL, 0, 1000);
if (err < 0) {
- printk(KERN_ERR "Failed to send command control message %x.%x:
err=%d.\n",
+ printk(KERN_ERR "Failed to send command control message %x.%x:
err=%d.\n",
value, index, err);
return err;
}
@@ -94,11 +91,11 @@ static int ds_send_control_cmd(struct ds
static int ds_send_control_mode(struct ds_device *dev, u16 value, u16 index)
{
int err;
-
- err =
[GIT PATCH] PCI patches for 2.6.13
Here are some PCI patches against your latest git tree. All of these have been in the -mm tree for a while. They do the following major things: - remove the pci ids database, finally - some pci hotplug driver fixes - clean up pci.h to be a bit smaller - add compiler warnings if you don't check the return value of some pci api functions. - other minor fixes. Please pull from: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/pci-2.6.git/ or if master.kernel.org hasn't synced up yet: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6.git/ The full patches will be sent to the linux-pci mailing lists, if anyone wants to see them. thanks, greg k-h Documentation/feature-removal-schedule.txt |9 MAINTAINERS|7 arch/alpha/kernel/sys_marvel.c |5 arch/i386/pci/i386.c |6 arch/ppc/kernel/pci.c |1 arch/ppc64/kernel/eeh.c| 31 arch/ppc64/kernel/iSeries_VpdInfo.c|5 arch/ppc64/kernel/pci.c|1 arch/sparc64/kernel/pci.c | 139 arch/sparc64/kernel/pci_psycho.c | 34 arch/sparc64/kernel/pci_sabre.c| 36 arch/sparc64/kernel/pci_schizo.c | 48 drivers/char/drm/drmP.h|4 drivers/infiniband/hw/mthca/mthca_main.c |8 drivers/infiniband/hw/mthca/mthca_reset.c |8 drivers/net/irda/vlsi_ir.h |6 drivers/parport/parport_pc.c |2 drivers/pci/Kconfig| 17 drivers/pci/Makefile | 24 drivers/pci/bus.c | 51 drivers/pci/gen-devlist.c | 132 drivers/pci/hotplug/Makefile |3 drivers/pci/hotplug/pciehp.h |2 drivers/pci/hotplug/rpadlpar_core.c| 355 - drivers/pci/hotplug/rpaphp.h | 37 drivers/pci/hotplug/rpaphp_core.c | 144 drivers/pci/hotplug/rpaphp_pci.c | 373 - drivers/pci/hotplug/rpaphp_slot.c | 66 drivers/pci/hotplug/rpaphp_vio.c | 129 drivers/pci/hotplug/sgi_hotplug.c | 195 drivers/pci/hotplug/shpchp.h |2 drivers/pci/msi.c | 10 drivers/pci/names.c| 137 drivers/pci/pci-driver.c | 37 drivers/pci/pci.c | 106 drivers/pci/pci.ids|10180 - drivers/pci/pcie/portdrv_pci.c |8 drivers/pci/probe.c|4 drivers/pci/proc.c | 12 drivers/pci/quirks.c |7 drivers/pci/setup-res.c|7 drivers/scsi/ahci.c| 16 drivers/scsi/ata_piix.c| 14 drivers/scsi/sata_sis.c| 14 drivers/scsi/sata_uli.c| 14 drivers/usb/core/hcd-pci.c | 28 drivers/usb/host/ehci-hcd.c|4 drivers/video/nvidia/nvidia.c |4 drivers/video/riva/fbdev.c |4 include/asm-alpha/pci.h| 13 include/asm-arm/pci.h | 13 include/asm-generic/pci.h | 13 include/asm-ia64/pci.h | 13 include/asm-parisc/pci.h | 13 include/asm-ppc/pci.h | 13 include/asm-ppc64/pci.h| 13 include/asm-sparc64/pci.h |2 include/linux/mempolicy.h |1 include/linux/pci.h| 511 - include/linux/pci_regs.h | 448 + mm/mempolicy.c |2 61 files changed, 1379 insertions(+), 12162 deletions(-) Adrian Bunk: PCI: remove CONFIG_PCI_NAMES Alan Stern: PCI: Fix regression in pci_enable_device_bars Andi Kleen: PCI: Run PCI driver initialization on local node Andrew Morton: PCI: Move PCI fixup data into r/o section PCI: fix up pretty-names removal patch Brett M Russ: PCI/libata INTx cleanup Daniel Ritz: PCI: Support PCM PM CAP version 3 David S. Miller: Make sparc64 use setup-res.c Greg Kroah-Hartman: PCI: clean up pci.h and split pci register info to separate header file. PCI: start paying attention to a lot of pci function return values Jiri Slaby: PCI: remove pci_find_device from parport_pc.c John Rose: PCI Hotplug: rpaphp: Move VIO registration PCI Hotplug: rpaphp: Change slot pci reference PCI Hotplug: rpaphp: Remove unused stuff PCI Hotplug: rpaphp: Remove rpaphp_find_pci PCI Hotplug: rpaphp: Purify hotplug PCI Hotplug: rpaphp: Export slot enable John W. Linville: PCI: restore BAR values after D3hot->D0 for
[PATCH] w1: Added inline functions on top of container_of().
[PATCH] w1: Added inline functions on top of container_of().
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
commit db2d0008de519c5db6baec45f7831e08790301cf
tree f100b05ab42f54740b967a24ba07d79518337f8e
parent 5e8eb8501212eb92826ccf191f9ca8c186f531c3
author Evgeniy Polyakov <[EMAIL PROTECTED]> Thu, 11 Aug 2005 17:27:49 +0400
committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 08 Sep 2005 14:41:26 -0700
drivers/w1/w1.c | 22 ++
drivers/w1/w1.h | 15 +++
drivers/w1/w1_smem.c |6 ++
drivers/w1/w1_therm.c |6 ++
4 files changed, 29 insertions(+), 20 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -89,15 +89,13 @@ static int w1_master_remove(struct devic
static void w1_master_release(struct device *dev)
{
- struct w1_master *md = container_of(dev, struct w1_master, dev);
-
+ struct w1_master *md = dev_to_w1_master(dev);
complete(>dev_released);
}
static void w1_slave_release(struct device *dev)
{
- struct w1_slave *sl = container_of(dev, struct w1_slave, dev);
-
+ struct w1_slave *sl = dev_to_w1_slave(dev);
complete(>dev_released);
}
@@ -162,7 +160,7 @@ struct device w1_slave_device = {
static ssize_t w1_master_attribute_show_name(struct device *dev, struct
device_attribute *attr, char *buf)
{
- struct w1_master *md = container_of(dev, struct w1_master, dev);
+ struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
if (down_interruptible (>mutex))
@@ -179,7 +177,7 @@ static ssize_t w1_master_attribute_store
struct device_attribute *attr,
const char * buf, size_t count)
{
- struct w1_master *md = container_of(dev, struct w1_master, dev);
+ struct w1_master *md = dev_to_w1_master(dev);
if (down_interruptible (>mutex))
return -EBUSY;
@@ -195,7 +193,7 @@ static ssize_t w1_master_attribute_show_
struct device_attribute *attr,
char *buf)
{
- struct w1_master *md = container_of(dev, struct w1_master, dev);
+ struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
if (down_interruptible (>mutex))
@@ -210,7 +208,7 @@ static ssize_t w1_master_attribute_show_
static ssize_t w1_master_attribute_show_pointer(struct device *dev, struct
device_attribute *attr, char *buf)
{
- struct w1_master *md = container_of(dev, struct w1_master, dev);
+ struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
if (down_interruptible(>mutex))
@@ -231,7 +229,7 @@ static ssize_t w1_master_attribute_show_
static ssize_t w1_master_attribute_show_max_slave_count(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct w1_master *md = container_of(dev, struct w1_master, dev);
+ struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
if (down_interruptible(>mutex))
@@ -245,7 +243,7 @@ static ssize_t w1_master_attribute_show_
static ssize_t w1_master_attribute_show_attempts(struct device *dev, struct
device_attribute *attr, char *buf)
{
- struct w1_master *md = container_of(dev, struct w1_master, dev);
+ struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
if (down_interruptible(>mutex))
@@ -259,7 +257,7 @@ static ssize_t w1_master_attribute_show_
static ssize_t w1_master_attribute_show_slave_count(struct device *dev, struct
device_attribute *attr, char *buf)
{
- struct w1_master *md = container_of(dev, struct w1_master, dev);
+ struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
if (down_interruptible(>mutex))
@@ -273,7 +271,7 @@ static ssize_t w1_master_attribute_show_
static ssize_t w1_master_attribute_show_slaves(struct device *dev, struct
device_attribute *attr, char *buf)
{
- struct w1_master *md = container_of(dev, struct w1_master, dev);
+ struct w1_master *md = dev_to_w1_master(dev);
int c = PAGE_SIZE;
if (down_interruptible(>mutex))
diff --git a/drivers/w1/w1.h b/drivers/w1/w1.h
--- a/drivers/w1/w1.h
+++ b/drivers/w1/w1.h
@@ -191,6 +191,21 @@ struct w1_master
int w1_create_master_attributes(struct w1_master *);
void w1_search(struct w1_master *dev, w1_slave_found_callback cb);
+static inline struct w1_slave* dev_to_w1_slave(struct device *dev)
+{
+ return container_of(dev, struct w1_slave, dev);
+}
+
+static inline struct w1_slave* kobj_to_w1_slave(struct kobject *kobj)
+{
+ return dev_to_w1_slave(container_of(kobj, struct device, kobj));
+}
+
+static inline struct w1_master* dev_to_w1_master(struct device *dev)
+{
+ return container_of(dev, struct w1_master,
[PATCH] w1: added private family data into w1_slave strucutre.
[PATCH] w1: added private family data into w1_slave strucutre. Add family_data to struct w1_slave. Signed-off-by: Ben Gardner <[EMAIL PROTECTED]> Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- commit a45f105ad4b456f99f622642056ae533f70710b7 tree 67bc83922a2bbda6ecf4131ca69ab1626fe9937b parent 7657ec1fcb69e266ab876af56332d0c484ca6d00 author Evgeniy Polyakov <[EMAIL PROTECTED]> Wed, 17 Aug 2005 15:19:08 +0400 committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 08 Sep 2005 14:41:27 -0700 drivers/w1/w1.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/w1/w1.h b/drivers/w1/w1.h --- a/drivers/w1/w1.h +++ b/drivers/w1/w1.h @@ -75,6 +75,7 @@ struct w1_slave struct w1_master*master; struct w1_family*family; + void*family_data; struct device dev; struct completion released; }; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] w1: Added DS2433 driver - family id update.
[PATCH] w1: Added DS2433 driver - family id update. Work by Ben Gardner <[EMAIL PROTECTED]>. Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- commit a3d65f254274567daa89d8b99ab3d481d60fcaef tree 4cdd137a5ec753c04a8da41a0f61ef034c92fe84 parent 80895392c83e54653540e72e7d40573aac7ee690 author Evgeniy Polyakov <[EMAIL PROTECTED]> Thu, 11 Aug 2005 17:27:50 +0400 committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 08 Sep 2005 14:41:27 -0700 drivers/w1/w1_family.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/w1/w1_family.h b/drivers/w1/w1_family.h --- a/drivers/w1/w1_family.h +++ b/drivers/w1/w1_family.h @@ -31,6 +31,7 @@ #define W1_FAMILY_SMEM_81 0x81 #define W1_THERM_DS18S20 0x10 #define W1_THERM_DS18220x22 +#define W1_EEPROM_DS2433 0x23 #define W1_THERM_DS18B20 0x28 #define MAXNAMELEN 32 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] w1_ds2433: Added crc16 protection and read caching.
[PATCH] w1_ds2433: Added crc16 protection and read caching.
The changes to ds2433 to add CRC16 protection and read caching.
Signed-off-by: Ben Gardner <[EMAIL PROTECTED]>
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
commit 0a25e4d5647003a32ba5496f9d0f40ba9c1e3863
tree 678a0f192d7b72270ea3431f642baca9566a249b
parent a45f105ad4b456f99f622642056ae533f70710b7
author Evgeniy Polyakov <[EMAIL PROTECTED]> Wed, 17 Aug 2005 15:24:37 +0400
committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 08 Sep 2005 14:41:27 -0700
drivers/w1/Kconfig |9
drivers/w1/Makefile|6 ++
drivers/w1/w1_ds2433.c | 117 ++--
3 files changed, 125 insertions(+), 7 deletions(-)
diff --git a/drivers/w1/Kconfig b/drivers/w1/Kconfig
--- a/drivers/w1/Kconfig
+++ b/drivers/w1/Kconfig
@@ -61,4 +61,13 @@ config W1_DS2433
Say Y here if you want to use a 1-wire
4kb EEPROM family device (DS2433).
+config W1_DS2433_CRC
+ bool "Protect DS2433 data with a CRC16"
+ depends on W1_DS2433
+ select CRC16
+ help
+ Say Y here to protect DS2433 data with a CRC16.
+ Each block has 30 bytes of data and a two byte CRC16.
+ Full block writes are only allowed if the CRC is valid.
+
endmenu
diff --git a/drivers/w1/Makefile b/drivers/w1/Makefile
--- a/drivers/w1/Makefile
+++ b/drivers/w1/Makefile
@@ -6,6 +6,10 @@ ifneq ($(CONFIG_NET), y)
EXTRA_CFLAGS += -DNETLINK_DISABLED
endif
+ifeq ($(CONFIG_W1_DS2433_CRC), y)
+EXTRA_CFLAGS += -DCONFIG_W1_F23_CRC
+endif
+
obj-$(CONFIG_W1) += wire.o
wire-objs := w1.o w1_int.o w1_family.o w1_netlink.o w1_io.o
@@ -13,7 +17,7 @@ obj-$(CONFIG_W1_MATROX) += matrox_w1.o
obj-$(CONFIG_W1_THERM) += w1_therm.o
obj-$(CONFIG_W1_SMEM) += w1_smem.o
-obj-$(CONFIG_W1_DS9490)+= ds9490r.o
+obj-$(CONFIG_W1_DS9490)+= ds9490r.o
ds9490r-objs:= dscore.o
obj-$(CONFIG_W1_DS9490_BRIDGE) += ds_w1_bridge.o
diff --git a/drivers/w1/w1_ds2433.c b/drivers/w1/w1_ds2433.c
--- a/drivers/w1/w1_ds2433.c
+++ b/drivers/w1/w1_ds2433.c
@@ -3,9 +3,8 @@
*
* Copyright (c) 2005 Ben Gardner <[EMAIL PROTECTED]>
*
- * This program is free software; you can redistribute it and/or modify
- * it under the smems of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
+ * This source code is licensed under the GNU General Public License,
+ * Version 2. See the file COPYING for more details.
*/
#include
@@ -14,6 +13,9 @@
#include
#include
#include
+#ifdef CONFIG_W1_F23_CRC
+#include
+#endif
#include "w1.h"
#include "w1_io.h"
@@ -25,18 +27,26 @@ MODULE_AUTHOR("Ben Gardner <[EMAIL PROTECTED]
MODULE_DESCRIPTION("w1 family 23 driver for DS2433, 4kb EEPROM");
#define W1_EEPROM_SIZE 512
+#define W1_PAGE_COUNT 16
#define W1_PAGE_SIZE 32
#define W1_PAGE_BITS 5
#define W1_PAGE_MASK 0x1F
+#define W1_F23_TIME300
+
#define W1_F23_READ_EEPROM 0xF0
#define W1_F23_WRITE_SCRATCH 0x0F
#define W1_F23_READ_SCRATCH0xAA
#define W1_F23_COPY_SCRATCH0x55
+struct w1_f23_data {
+ u8 memory[W1_EEPROM_SIZE];
+ u32 validcrc;
+};
+
/**
* Check the file size bounds and adjusts count as needed.
- * This may not be needed if the sysfs layer checks bounds.
+ * This would not be needed if the file size didn't reset to 0 after a write.
*/
static inline size_t w1_f23_fix_count(loff_t off, size_t count, size_t size)
{
@@ -49,10 +59,45 @@ static inline size_t w1_f23_fix_count(lo
return count;
}
-static ssize_t w1_f23_read_bin(struct kobject *kobj, char *buf, loff_t off,
size_t count)
+#ifdef CONFIG_W1_F23_CRC
+static int w1_f23_refresh_block(struct w1_slave *sl, struct w1_f23_data *data,
+ int block)
+{
+ u8 wrbuf[3];
+ int off = block * W1_PAGE_SIZE;
+
+ if (data->validcrc & (1 << block))
+ return 0;
+
+ if (w1_reset_select_slave(sl)) {
+ data->validcrc = 0;
+ return -EIO;
+ }
+
+ wrbuf[0] = W1_F23_READ_EEPROM;
+ wrbuf[1] = off & 0xff;
+ wrbuf[2] = off >> 8;
+ w1_write_block(sl->master, wrbuf, 3);
+ w1_read_block(sl->master, >memory[off], W1_PAGE_SIZE);
+
+ /* cache the block if the CRC is valid */
+ if (crc16(CRC16_INIT, >memory[off], W1_PAGE_SIZE) == CRC16_VALID)
+ data->validcrc |= (1 << block);
+
+ return 0;
+}
+#endif /* CONFIG_W1_F23_CRC */
+
+static ssize_t w1_f23_read_bin(struct kobject *kobj, char *buf, loff_t off,
+ size_t count)
{
struct w1_slave *sl = kobj_to_w1_slave(kobj);
+#ifdef CONFIG_W1_F23_CRC
+ struct w1_f23_data *data = sl->family_data;
+ int i, min_page, max_page;
+#else
[PATCH] w1: Fixed 64bit compilation warning.
[PATCH] w1: Fixed 64bit compilation warning. Fixed 64bit compilation warning. Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- commit 5e8eb8501212eb92826ccf191f9ca8c186f531c3 tree 20008154898e8964b12ed86ecd767eff87b462bf parent 7f772ed8df27c6941952452330c618512389c4c7 author Evgeniy Polyakov <[EMAIL PROTECTED]> Thu, 11 Aug 2005 13:45:54 +0400 committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 08 Sep 2005 14:41:26 -0700 drivers/w1/w1.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c --- a/drivers/w1/w1.c +++ b/drivers/w1/w1.c @@ -373,7 +373,7 @@ static int w1_hotplug(struct device *dev if (err) return err; - err = add_hotplug_env_var(envp, num_envp, _index, buffer, buffer_size, _len, "W1_SLAVE_ID=%024llX", sl->reg_num.id); + err = add_hotplug_env_var(envp, num_envp, _index, buffer, buffer_size, _len, "W1_SLAVE_ID=%024LX", (u64)sl->reg_num.id); if (err) return err; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] w1: Added add/remove slave callbacks.
[PATCH] w1: Added add/remove slave callbacks.
Patch is based on work from Ben Gardner <[EMAIL PROTECTED]>
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
commit d2a4ef6a0ce4d841293b49bf2cdc17a0ebfaaf9d
tree 2d49373e06fd65aae5217aad864fafb849c8cda2
parent ea7d8f65c865ebfa1d7cd67c360a87333ff013c1
author Evgeniy Polyakov <[EMAIL PROTECTED]> Thu, 11 Aug 2005 17:27:50 +0400
committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 08 Sep 2005 14:41:26 -0700
drivers/w1/w1.c| 119 +++-
drivers/w1/w1.h|3 -
drivers/w1/w1_family.c | 11
drivers/w1/w1_family.h |6 ++
drivers/w1/w1_smem.c | 47 ---
drivers/w1/w1_therm.c | 32 +
6 files changed, 93 insertions(+), 125 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -59,19 +59,6 @@ static pid_t control_thread;
static int control_needs_exit;
static DECLARE_COMPLETION(w1_control_complete);
-/* stuff for the default family */
-static ssize_t w1_famdefault_read_name(struct device *dev, struct
device_attribute *attr, char *buf)
-{
- struct w1_slave *sl = container_of(dev, struct w1_slave, dev);
- return(sprintf(buf, "%s\n", sl->name));
-}
-static struct w1_family_ops w1_default_fops = {
- .rname = _famdefault_read_name,
-};
-static struct w1_family w1_default_family = {
- .fops = _default_fops,
-};
-
static int w1_master_match(struct device *dev, struct device_driver *drv)
{
return 1;
@@ -99,30 +86,47 @@ static void w1_slave_release(struct devi
complete(>dev_released);
}
-static ssize_t w1_default_read_name(struct device *dev, struct
device_attribute *attr, char *buf)
+static ssize_t w1_slave_read_name(struct device *dev, struct device_attribute
*attr, char *buf)
{
- return sprintf(buf, "No family registered.\n");
+ struct w1_slave *sl = dev_to_w1_slave(dev);
+
+ return sprintf(buf, "%s\n", sl->name);
}
-static ssize_t w1_default_read_bin(struct kobject *kobj, char *buf, loff_t off,
-size_t count)
+static ssize_t w1_slave_read_id(struct kobject *kobj, char *buf, loff_t off,
size_t count)
{
- return sprintf(buf, "No family registered.\n");
-}
+ struct w1_slave *sl = kobj_to_w1_slave(kobj);
-static struct device_attribute w1_slave_attribute =
- __ATTR(name, S_IRUGO, w1_default_read_name, NULL);
+ atomic_inc(>refcnt);
+ if (off > 8) {
+ count = 0;
+ } else {
+ if (off + count > 8)
+ count = 8 - off;
-static struct bin_attribute w1_slave_bin_attribute = {
- .attr = {
- .name = "w1_slave",
- .mode = S_IRUGO,
- .owner = THIS_MODULE,
- },
- .size = W1_SLAVE_DATA_SIZE,
- .read = _default_read_bin,
+ memcpy(buf, (u8 *)>reg_num, count);
+ }
+ atomic_dec(>refcnt);
+
+ return count;
+ }
+
+static struct device_attribute w1_slave_attr_name =
+ __ATTR(name, S_IRUGO, w1_slave_read_name, NULL);
+
+static struct bin_attribute w1_slave_attr_bin_id = {
+ .attr = {
+ .name = "id",
+ .mode = S_IRUGO,
+ .owner = THIS_MODULE,
+ },
+ .size = 8,
+ .read = w1_slave_read_id,
};
+/* Default family */
+static struct w1_family w1_default_family;
+
static int w1_hotplug(struct device *dev, char **envp, int num_envp, char
*buffer, int buffer_size);
static struct bus_type w1_bus_type = {
@@ -413,36 +417,44 @@ static int __w1_attach_slave_device(stru
return err;
}
- memcpy(>attr_bin, _slave_bin_attribute, sizeof(sl->attr_bin));
- memcpy(>attr_name, _slave_attribute, sizeof(sl->attr_name));
-
- sl->attr_bin.read = sl->family->fops->rbin;
- sl->attr_name.show = sl->family->fops->rname;
+ /* Create "name" entry */
+ err = device_create_file(>dev, _slave_attr_name);
+ if (err < 0) {
+ dev_err(>dev,
+ "sysfs file creation for [%s] failed. err=%d\n",
+ sl->dev.bus_id, err);
+ goto out_unreg;
+ }
- err = device_create_file(>dev, >attr_name);
+ /* Create "id" entry */
+ err = sysfs_create_bin_file(>dev.kobj, _slave_attr_bin_id);
if (err < 0) {
dev_err(>dev,
"sysfs file creation for [%s] failed. err=%d\n",
sl->dev.bus_id, err);
- device_unregister(>dev);
- return err;
+ goto out_rem1;
}
- if ( sl->attr_bin.read ) {
- err = sysfs_create_bin_file(>dev.kobj, >attr_bin);
- if (err < 0) {
- dev_err(>dev,
- "sysfs file creation for [%s] failed. err=%d\n",
-
[PATCH] lib/crc16: added crc16 algorithm.
[PATCH] lib/crc16: added crc16 algorithm.
Add the crc16 routines, as used by w1 devices.
Signed-off-by: Ben Gardner <[EMAIL PROTECTED]>
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
commit 7657ec1fcb69e266ab876af56332d0c484ca6d00
tree 6118ceffa2f83f43c3086941d96011dc1abeb459
parent a3d65f254274567daa89d8b99ab3d481d60fcaef
author Evgeniy Polyakov <[EMAIL PROTECTED]> Wed, 17 Aug 2005 15:17:26 +0400
committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 08 Sep 2005 14:41:27 -0700
include/linux/crc16.h | 44
lib/Kconfig |8 ++
lib/Makefile |3 +-
lib/crc16.c | 67 +
4 files changed, 121 insertions(+), 1 deletions(-)
diff --git a/include/linux/crc16.h b/include/linux/crc16.h
new file mode 100644
--- /dev/null
+++ b/include/linux/crc16.h
@@ -0,0 +1,44 @@
+/*
+ * crc16.h - CRC-16 routine
+ *
+ * Implements the standard CRC-16, as used with 1-wire devices:
+ * Width 16
+ * Poly 0x8005 (x^16 + x^15 + x^2 + 1)
+ * Init 0
+ *
+ * For 1-wire devices, the CRC is stored inverted, LSB-first
+ *
+ * Example buffer with the CRC attached:
+ * 31 32 33 34 35 36 37 38 39 C2 44
+ *
+ * The CRC over a buffer with the CRC attached is 0xB001.
+ * So, if (crc16(0, buf, size) == 0xB001) then the buffer is valid.
+ *
+ * Refer to "Application Note 937: Book of iButton Standards" for details.
+ * http://www.maxim-ic.com/appnotes.cfm/appnote_number/937
+ *
+ * Copyright (c) 2005 Ben Gardner <[EMAIL PROTECTED]>
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2. See the file COPYING for more details.
+ */
+
+#ifndef __CRC16_H
+#define __CRC16_H
+
+#include
+
+#define CRC16_INIT 0
+#define CRC16_VALID0xb001
+
+extern u16 const crc16_table[256];
+
+extern u16 crc16(u16 crc, const u8 *buffer, size_t len);
+
+static inline u16 crc16_byte(u16 crc, const u8 data)
+{
+ return (crc >> 8) ^ crc16_table[(crc ^ data) & 0xff];
+}
+
+#endif /* __CRC16_H */
+
diff --git a/lib/Kconfig b/lib/Kconfig
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -12,6 +12,14 @@ config CRC_CCITT
the kernel tree does. Such modules that use library CRC-CCITT
functions require M here.
+config CRC16
+ tristate "CRC16 functions"
+ help
+ This option is provided for the case where no in-kernel-tree
+ modules require CRC16 functions, but a module built outside
+ the kernel tree does. Such modules that use library CRC16
+ functions require M here.
+
config CRC32
tristate "CRC32 functions"
default y
diff --git a/lib/Makefile b/lib/Makefile
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -23,11 +23,12 @@ lib-$(CONFIG_GENERIC_FIND_NEXT_BIT) += f
obj-$(CONFIG_LOCK_KERNEL) += kernel_lock.o
obj-$(CONFIG_DEBUG_PREEMPT) += smp_processor_id.o
-ifneq ($(CONFIG_HAVE_DEC_LOCK),y)
+ifneq ($(CONFIG_HAVE_DEC_LOCK),y)
lib-y += dec_and_lock.o
endif
obj-$(CONFIG_CRC_CCITT)+= crc-ccitt.o
+obj-$(CONFIG_CRC16)+= crc16.o
obj-$(CONFIG_CRC32)+= crc32.o
obj-$(CONFIG_LIBCRC32C)+= libcrc32c.o
obj-$(CONFIG_GENERIC_IOMAP) += iomap.o
diff --git a/lib/crc16.c b/lib/crc16.c
new file mode 100644
--- /dev/null
+++ b/lib/crc16.c
@@ -0,0 +1,67 @@
+/*
+ * crc16.c
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2. See the file COPYING for more details.
+ */
+
+#include
+#include
+#include
+
+/** CRC table for the CRC-16. The poly is 0x8005 (x^16 + x^15 + x^2 + 1) */
+u16 const crc16_table[256] = {
+ 0x, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0280, 0xC241,
+ 0xC601, 0x06C0, 0x0780, 0xC741, 0x0500, 0xC5C1, 0xC481, 0x0440,
+ 0xCC01, 0x0CC0, 0x0D80, 0xCD41, 0x0F00, 0xCFC1, 0xCE81, 0x0E40,
+ 0x0A00, 0xCAC1, 0xCB81, 0x0B40, 0xC901, 0x09C0, 0x0880, 0xC841,
+ 0xD801, 0x18C0, 0x1980, 0xD941, 0x1B00, 0xDBC1, 0xDA81, 0x1A40,
+ 0x1E00, 0xDEC1, 0xDF81, 0x1F40, 0xDD01, 0x1DC0, 0x1C80, 0xDC41,
+ 0x1400, 0xD4C1, 0xD581, 0x1540, 0xD701, 0x17C0, 0x1680, 0xD641,
+ 0xD201, 0x12C0, 0x1380, 0xD341, 0x1100, 0xD1C1, 0xD081, 0x1040,
+ 0xF001, 0x30C0, 0x3180, 0xF141, 0x3300, 0xF3C1, 0xF281, 0x3240,
+ 0x3600, 0xF6C1, 0xF781, 0x3740, 0xF501, 0x35C0, 0x3480, 0xF441,
+ 0x3C00, 0xFCC1, 0xFD81, 0x3D40, 0xFF01, 0x3FC0, 0x3E80, 0xFE41,
+ 0xFA01, 0x3AC0, 0x3B80, 0xFB41, 0x3900, 0xF9C1, 0xF881, 0x3840,
+ 0x2800, 0xE8C1, 0xE981, 0x2940, 0xEB01, 0x2BC0, 0x2A80, 0xEA41,
+ 0xEE01, 0x2EC0, 0x2F80, 0xEF41, 0x2D00, 0xEDC1, 0xEC81, 0x2C40,
+ 0xE401, 0x24C0, 0x2580, 0xE541, 0x2700, 0xE7C1, 0xE681, 0x2640,
+ 0x2200, 0xE2C1, 0xE381, 0x2340, 0xE101, 0x21C0, 0x2080, 0xE041,
+ 0xA001, 0x60C0, 0x6180, 0xA141, 0x6300, 0xA3C1, 0xA281, 0x6240,
+ 0x6600, 0xA6C1, 0xA781, 0x6740, 0xA501, 0x65C0, 0x6480, 0xA441,
+ 0x6C00,
[PATCH] W1: w1_netlink: New init/fini netlink callbacks.
[PATCH] W1: w1_netlink: New init/fini netlink callbacks.
They are guarded with NETLINK_DISABLE compile time options,
so if CONFIG_NET is disabled, no linking errors occur.
Bug noticed by Adrian Bunk <[EMAIL PROTECTED]>.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
commit 2d8331792ea3f5ccfd147288afba148537337019
tree 7d144ae862363a5fd6bfa031cca04a42cc79d879
parent 1b11d78cf87a7014f96e5b7fa2e1233cc8081a00
author Evgeniy Polyakov <[EMAIL PROTECTED]> Wed, 27 Jul 2005 13:10:11 +0400
committer Greg Kroah-Hartman <[EMAIL PROTECTED]> Thu, 08 Sep 2005 14:41:25 -0700
drivers/w1/w1_int.c | 16 ++--
drivers/w1/w1_netlink.c | 26 ++
drivers/w1/w1_netlink.h |2 ++
3 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c
--- a/drivers/w1/w1_int.c
+++ b/drivers/w1/w1_int.c
@@ -88,17 +88,14 @@ static struct w1_master * w1_alloc_dev(u
dev->groups = 1;
dev->seq = 1;
- dev->nls = netlink_kernel_create(NETLINK_W1, 1, NULL, THIS_MODULE);
- if (!dev->nls) {
- printk(KERN_ERR "Failed to create new netlink socket(%u) for w1
master %s.\n",
- NETLINK_NFLOG, dev->dev.bus_id);
- }
+ dev_init_netlink(dev);
err = device_register(>dev);
if (err) {
printk(KERN_ERR "Failed to register master device. err=%d\n",
err);
- if (dev->nls && dev->nls->sk_socket)
- sock_release(dev->nls->sk_socket);
+
+ dev_fini_netlink(dev);
+
memset(dev, 0, sizeof(struct w1_master));
kfree(dev);
dev = NULL;
@@ -107,11 +104,10 @@ static struct w1_master * w1_alloc_dev(u
return dev;
}
-static void w1_free_dev(struct w1_master *dev)
+void w1_free_dev(struct w1_master *dev)
{
device_unregister(>dev);
- if (dev->nls && dev->nls->sk_socket)
- sock_release(dev->nls->sk_socket);
+ dev_fini_netlink(dev);
memset(dev, 0, sizeof(struct w1_master) + sizeof(struct w1_bus_master));
kfree(dev);
}
diff --git a/drivers/w1/w1_netlink.c b/drivers/w1/w1_netlink.c
--- a/drivers/w1/w1_netlink.c
+++ b/drivers/w1/w1_netlink.c
@@ -57,10 +57,36 @@ void w1_netlink_send(struct w1_master *d
nlmsg_failure:
return;
}
+
+int dev_init_netlink(struct w1_master *dev)
+{
+ dev->nls = netlink_kernel_create(NETLINK_W1, 1, NULL, THIS_MODULE);
+ if (!dev->nls) {
+ printk(KERN_ERR "Failed to create new netlink socket(%u) for w1
master %s.\n",
+ NETLINK_W1, dev->dev.bus_id);
+ }
+
+ return 0;
+}
+
+void dev_fini_netlink(struct w1_master *dev)
+{
+ if (dev->nls && dev->nls->sk_socket)
+ sock_release(dev->nls->sk_socket);
+}
#else
#warning Netlink support is disabled. Please compile with NET support enabled.
void w1_netlink_send(struct w1_master *dev, struct w1_netlink_msg *msg)
{
}
+
+int dev_init_netlink(struct w1_master *dev)
+{
+ return 0;
+}
+
+void dev_fini_netlink(struct w1_master *dev)
+{
+}
#endif
diff --git a/drivers/w1/w1_netlink.h b/drivers/w1/w1_netlink.h
--- a/drivers/w1/w1_netlink.h
+++ b/drivers/w1/w1_netlink.h
@@ -52,6 +52,8 @@ struct w1_netlink_msg
#ifdef __KERNEL__
void w1_netlink_send(struct w1_master *, struct w1_netlink_msg *);
+int dev_init_netlink(struct w1_master *dev);
+void dev_fini_netlink(struct w1_master *dev);
#endif /* __KERNEL__ */
#endif /* __W1_NETLINK_H */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] W1 patches for 2.6.13
Here are some w1 patches that have been in the -mm tree for a while. They add a new driver, and fix up the netlink logic a lot. They also add a crc16 implementation that is needed. Please pull from: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/w1-2.6.git/ or from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/w1-2.6.git/ if it isn't synced up yet. The full patch series will sent to the linux-kernel mailing lists, if anyone wants to see them. thanks, greg k-h drivers/w1/Kconfig| 16 ++ drivers/w1/Makefile |7 drivers/w1/ds_w1_bridge.c | 24 +-- drivers/w1/dscore.c | 161 +++-- drivers/w1/dscore.h | 10 - drivers/w1/w1.c | 336 - drivers/w1/w1.h | 22 ++ drivers/w1/w1_ds2433.c| 339 +- drivers/w1/w1_family.c| 11 - drivers/w1/w1_family.h|7 drivers/w1/w1_int.c | 28 +-- drivers/w1/w1_io.c| 24 +++ drivers/w1/w1_io.h|1 drivers/w1/w1_netlink.c | 26 +++ drivers/w1/w1_netlink.h |2 drivers/w1/w1_smem.c | 53 --- drivers/w1/w1_therm.c | 49 +++--- include/linux/crc16.h | 44 + lib/Kconfig |8 + lib/Makefile |3 lib/crc16.c | 67 + 21 files changed, 898 insertions(+), 340 deletions(-) Evgeniy Polyakov: W1: w1_netlink: New init/fini netlink callbacks. w1: Detouching bug fixed. w1: Fixed 64bit compilation warning. w1: hotplug support. W1: Sync with w1/ds9490 tree. w1: Added add/remove slave callbacks. w1: Added inline functions on top of container_of(). w1: Added w1_reset_select_slave() - Resets the bus and then selects the slave by w1_ds2433: Added crc16 protection and read caching. lib/crc16: added crc16 algorithm. w1: Decreased debug level. w1: Added DS2433 driver. w1: Added DS2433 driver - family id update. w1: added private family data into w1_slave strucutre. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] KGDB for Real-Time Preemption systems
Serge Noiraud wrote: mercredi 7 Septembre 2005 23:16, George Anzinger wrote/a écrit : Serge Noiraud wrote: ... I'm trying this kgdb patch with 2.6.13 and I get the following errors. Is there something I forgot ? Where did you get the kgdb you are using? It looks like kgdb_ts is in this version, but it it not in the one on my website http://source.mvista.com/~ganzinger/ This related to kgdb? I.e. does it go away if you either turn off kgdb at configure time or just don't patch with kgdb? (It sure seems unrelated, but...) I don't get those errors with CONFIG_KGDB=n bellow I put the diff between a working . config and a non working .config George ... INSTALL sound/usb/snd-usb-audio.ko INSTALL sound/usb/snd-usb-lib.ko INSTALL sound/usb/usx2y/snd-usb-usx2y.ko if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map -b /var/tmp/kernel-2.6.13-rt4-root -r 2.6.13-rt4; fi WARNING: ... If I redo the make command only ( not make rpm ) I obtain the following : # make CHK include/linux/version.h make[1]: « arch/i386/kernel/asm-offsets.s » est à jour. CHK include/linux/compile.h CHK usr/initramfs_list Kernel: arch/i386/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST *** Warning: "preempt_locks" [net/sunrpc/sunrpc.ko] undefined! *** Warning: "preempt_locks" [net/appletalk/appletalk.ko] undefined! *** Warning: "preempt_locks" [fs/reiserfs/reiserfs.ko] undefined! *** Warning: "preempt_locks" [fs/ntfs/ntfs.ko] undefined! *** Warning: "preempt_locks" [fs/nfs/nfs.ko] undefined! *** Warning: "preempt_locks" [fs/minix/minix.ko] undefined! *** Warning: "preempt_locks" [fs/jbd/jbd.ko] undefined! *** Warning: "preempt_locks" [fs/ext3/ext3.ko] undefined! *** Warning: "preempt_locks" [fs/cifs/cifs.ko] undefined! *** Warning: "preempt_locks" [fs/affs/affs.ko] undefined! *** Warning: "preempt_locks" [drivers/scsi/libata.ko] undefined! *** Warning: "preempt_locks" [drivers/scsi/ide-scsi.ko] undefined! *** Warning: "preempt_locks" [drivers/scsi/gdth.ko] undefined! *** Warning: "preempt_locks" [drivers/md/raid6.ko] undefined! *** Warning: "preempt_locks" [drivers/md/raid5.ko] undefined! *** Warning: "preempt_locks" [drivers/ide/ide-floppy.ko] undefined! *** Warning: "preempt_locks" [drivers/block/pktcdvd.ko] undefined! *** Warning: "preempt_locks" [drivers/block/loop.ko] undefined! preempt_locks is being accessed from a module but is not exported. This is turned on with CONFIG_DEBUG_RT_LOCKING_MODE so change that and it should build. # ~ -# CONFIG_EARLY_PRINTK is not set -# CONFIG_DEBUG_STACKOVERFLOW is not set +CONFIG_LATENCY_TRACE=y +CONFIG_RT_DEADLOCK_DETECT=y +CONFIG_DEBUG_RT_LOCKING_MODE=y <- This one is doing it +CONFIG_DEBUG_KOBJECT=y +CONFIG_DEBUG_HIGHMEM=y ~ +CONFIG_KGDB=y +CONFIG_KGDB_9600BAUD=y +# CONFIG_KGDB_19200BAUD is not set +# CONFIG_KGDB_38400BAUD is not set +# CONFIG_KGDB_57600BAUD is not set +# CONFIG_KGDB_115200BAUD is not set +CONFIG_KGDB_PORT=0x3f8 +CONFIG_KGDB_IRQ=4 +CONFIG_KGDB_MORE=y +CONFIG_KGDB_OPTIONS="-O1" +CONFIG_NO_KGDB_CPUS=8 The following are not in the latest kgdb... +CONFIG_KGDB_TS=y +# CONFIG_KGDB_TS_64 is not set +CONFIG_KGDB_TS_128=y +# CONFIG_KGDB_TS_256 is not set +# CONFIG_KGDB_TS_512 is not set +# CONFIG_KGDB_TS_1024 is not set . +CONFIG_STACK_OVERFLOW_TEST=y +CONFIG_TRAP_BAD_SYSCALL_EXITS=y <--- I recommend against this one, see notes at front of kgdb patch +CONFIG_KGDB_CONSOLE=y<--- Likewise use this only if you have only one serial port and no VGA +CONFIG_KGDB_SYSRQ=y # - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dynticks - implement no idle hz for x86
On 08.09.2005 [14:22:13 -0700], Nishanth Aravamudan wrote:
> On 08.09.2005 [13:00:36 +0300], Tony Lindgren wrote:
> > * Nishanth Aravamudan <[EMAIL PROTECTED]> [050907 18:07]:
> > > On 07.09.2005 [10:37:43 +0300], Tony Lindgren wrote:
> > > > * Nishanth Aravamudan <[EMAIL PROTECTED]> [050905 20:02]:
> > > > > On 05.09.2005 [10:27:05 +0300], Tony Lindgren wrote:
> > > > > > * Srivatsa Vaddagiri <[EMAIL PROTECTED]> [050905 10:03]:
> > > > > > > On Sun, Sep 04, 2005 at 01:10:54PM -0700, Nishanth Aravamudan
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Also, I am a bit confused by the use of "dynamic-tick" to
> > > > > > > > describe these
> > > > > > > > changes. To me, these are all NO_IDLE_HZ implementations, as
> > > > > > > > they are
> > > > > > > > only invoked from cpu_idle() (or their equivalent) routines. I
> > > > > > > > know this
> > > > > > > > is true of s390 and the x86 code, and I believe it is true of
> > > > > > > > the ARM
> > > > > > > > code? If it were dynamic-tick, I would think we would be
> > > > > > > > adjusting the
> > > > > > > > timer interrupt frequency continuously (e.g., at the end of
> > > > > > > > __run_timers() and at every call to {add,mod,del}_timer()). I
> > > > > > > > was
> > > > > > > > working on a patch which did some renaming to no_idle_hz_timer,
> > > > > > > > etc.,
> > > > > > > > but it's mostly code churn :)
> > > > > > >
> > > > > > > Yes, the name 'dynamic-tick' is misleading!
So, after *all* that, I'm going back to dyntick (notice no hyphen though
:-P). Everyone ok with this doc?
Thanks,
Nish
- include/linux/dyntick.h
with definitions in kernel/dyntick.c
#define DYN_TICK_ENABLED(1 << 1)
#define DYN_TICK_SUITABLE (1 << 0)
#define DYN_TICK_MIN_SKIP 2
/* Abstraction of a dynamic tick source
* @state: current state
* @max_skip: current maximum number of jiffies to program h/w to skip
* @min_skip: current minimum number of jiffies to program h/w to skip
* @init: initialization routine
* @enable_dyn_tick: called via sysfs to enable interrupt skipping
* @disable_dyn_tick: called via sysfs to disable interrupt
* skipping
* @reprogram: actually interact with h/w, return number of ticks the
* h/w will skip
* @recover_time: handler for returning from skipped ticks and keeping
* time consistent
* @enter_all_cpus_idle: last cpu to go idle calls this, which should
* disable any timer source (e.g. PIT on x86)
* @exit_all_cpus_idle: first cpu to wake after @enter_all_cpus_idle has
* been called should use this to revert the
* effects of that function
*/
struct dyntick_timer {
unsigned int state;
unsigned long max_skip;
unsigned long min_skip;
int (*init) (void);
void (*enable_dyn_tick) (void);
void (*disable_dyn_tick) (void);
unsigned long (*reprogram) (unsigned long); /* return number of ticks
skipped */
unsigned long (*recover_time) (int, void *, struct pt_regs *); /*
handler in arm */
/* following empty in UP */
void (*enter_all_cpus_idle) (int);
void (*exit_all_cpus_idle) (int);
spinlock_t lock;
};
extern void dyntick_timer_register(struct dyntick_timer *new_dyntick_timer);
/* so do we need this?
Maybe it can just be static to dyntick.c and all the callable
functions will call-down to the structure members? */
extern struct dyntick_timer *current_dyntick_timer;
#ifdef CONFIG_NO_IDLE_HZ /* which means CONFIG_DYNTICK is also on */
extern void set_dyntick_max_skip(unsigned long max_skip);
extern void set_dyntick_min_skip(unsigned long min_skip);
/* return number of ticks skipped, as we can request any number
called from cpu_idle() in dyntick-enabled arch's */
extern unsigned long reprogram_dyntick(void);
extern struct tick_source * __init arch_select_tick_source(void);
/* calls select_tick_source(), then calls tick_source_register() */
extern void __init dyn_tick_init(void);
static inline int dyn_tick_enabled(void)
{
return (current_ticksource->state & DYN_TICK_ENABLED);
}
#else /* CONFIG_NO_IDLE_HZ */
static inline void set_tick_max_skip(unsigned long max_skip)
{
}
static inline void idle_reprogram_tick(void)
{
}
static inline unsigned long reprogram_tick(void)
{
return 0;
}
static inline void dyn_tick_init(void)
{
}
static inline int dyn_tick_enabled(void)
{
return 0;
}
#endif /* CONFIG_NO_IDLE_HZ */
/* Pick up arch specific header */
#include
- timer.c / timer.h
/* moved from sched.c/.h */
cpumask_t no_idle_hz_cpumask;
- each arch-specific file pair needs to provide:
arch_select_tick_source();
an appropriate struct tick_source definitions, functions, etc. per
usable h/w
- include/asm-i386/dyntick.h
with defines in arch/i386/dyntick.c
/* basically
Re: [RFC] Consistently use the name asm-offsets.h
Luck, Tony wrote: The existing ia64 specific rule to generate offsets.h has to "echo #define IA64_TASK_SIZE 0 > include/asm-ia64/offsets.h" before building asm-offsets.s to avoid compilation errors. So long as you take care of this somehow in the generic version, go wild. The right fix is to get rid of that god-awful circular dependency on offset.h -- Brian Gerst
Re: [RFC] Consistently use the name asm-offsets.h
mips has it own private gen-asm-offset macro,
The important part being:
sed -ne "/^@@@/s///p"; \
compared to the generic one:
sed -ne "/^->/{s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:;
s:->::; p;}"; \
I wonder why the assembly for mips is so different...
So for now two architectures needs special care: mips and ia64.
Sam
Re: git_linux addition ; genericity pls
On Thu, September 8, 2005 4:37 pm, Sam Ravnborg said: > cogito? > > cg-clone \ > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/linus/linux-2.6.git \ > linux-2.6.git > > cd linux-2.6 > make menuconfig > The cogito shell scripts don't buy you as much as they once did. For example, the above procedure in raw git, is: git clone rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 cd linux-2.6 make menuconfig Cheers, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serial maintainership
On Thu, 8 Sep 2005, Linus Torvalds wrote: > > (You might even remove the #ifdef inside the function by then, since "ch" > being a constant zero will make 90% of it go away anyway). Sadly, the remaining part checks "port->sysrq", which doesn't even exist unless CONFIG_SERIAL_CORE_CONSOLE is set, so that doesn't work out. Oh, well. That simple three-liner should work fine, I was just hoping we could do the rest more cleanly.. 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: [RFC] Consistently use the name asm-offsets.h
The existing ia64 specific rule to generate offsets.h has to "echo #define IA64_TASK_SIZE 0 > include/asm-ia64/offsets.h" before building asm-offsets.s to avoid compilation errors. So long as you take care of this somehow in the generic version, go wild. -Tony
Re: Serial maintainership
On Thu, Sep 08, 2005 at 02:22:37PM -0700, Linus Torvalds wrote: > On Thu, 8 Sep 2005, David S. Miller wrote: > > Ok, I'll revert the patch and fix the sunsab.c driver as > > Russell indicated. So much for type checking... > > Actually, I think there's a simpler fix. Instead of reverting, how about > something like this? > > (You might even remove the #ifdef inside the function by then, since "ch" > being a constant zero will make 90% of it go away anyway). > > rmk? Davem? Ok, I'll settle for this. > --- > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h > --- a/include/linux/serial_core.h > +++ b/include/linux/serial_core.h > @@ -401,6 +401,9 @@ uart_handle_sysrq_char(struct uart_port > #endif > return 0; > } > +#ifndef SUPPORT_SYSRQ > +#define uart_handle_sysrq_char(port,ch,regs) uart_handle_sysrq_char(port, 0, > NULL) > +#endif > > /* > * We do the SysRQ and SAK checking like this... -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serial maintainership
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Thu, 8 Sep 2005 14:22:37 -0700 (PDT) > On Thu, 8 Sep 2005, David S. Miller wrote: > > > > Ok, I'll revert the patch and fix the sunsab.c driver as > > Russell indicated. So much for type checking... > > Actually, I think there's a simpler fix. Instead of reverting, how about > something like this? > > (You might even remove the #ifdef inside the function by then, since "ch" > being a constant zero will make 90% of it go away anyway). > > rmk? Davem? I'm fine with this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
can't boot 2.6.13
I am not able to boot the 2.6.13 version of the kernel. I've tried different systems, tried downloading again, still nothing. Here's the last thing I see from the serial port: md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. RAMDISK: Compressed image found at block 0 input: AT Translated Set 2 keyboard on isa0060/serio0 VFS: Mounted root (ext2 filesystem). logips2pp: Detected unknown logitech mouse model 1 input: PS/2 Logitech Mouse on isa0060/serio1 SCSI subsystem initialized Fusion MPT base driver 3.03.02 Copyright (c) 1999-2005 LSI Logic Corporation The console shows the reiserfs module loaded and then the message waiting for /dev/sda2 to appear It then dumps a list of devices and sda is not one of them. I've attached the entire boot log if any one is interested. I've tried statically linking cciss on another system and the same basic results. Apparently, MPT cannot be statically linked unless I missed something. What do I have to do to get 2.6.13 to boot up? Thanks, mikem crap :00:00.0 Host bridge: Intel Corp. Server Memory Controller Hub (rev 09) :00:02.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port A0 (rev 09) :00:04.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port B0 (rev 09) :00:05.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port B1 (rev 09) :00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 (rev 02) :00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2 (rev 02) :00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02) :00:1d.3 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4 (rev 02) :00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) :00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB/ER Hub interface to PCI Bridge (rev c2) :00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02) :00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100 Storage Controller (rev 02) :01:03.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) :01:04.0 System peripheral: Compaq Computer Corporation Integrated Lights Out Controller (rev 01) :01:04.2 System peripheral: Compaq Computer Corporation Integrated Lights Out Processor (rev 01) :02:00.0 PCI bridge: Intel Corp. PCI Bridge Hub A (rev 09) :02:00.2 PCI bridge: Intel Corp. PCI Bridge Hub B (rev 09) :03:02.0 RAID bus controller: Hewlett-Packard Company: Unknown device 3220 :03:03.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07) :03:03.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07) :07:01.0 PCI bridge: IBM PCI-X to PCI-X Bridge (rev 02) :07:03.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703 Gigabit Ethernet (rev 10) :08:04.0 RAID bus controller: Compaq Computer Corporation Smart Array 64xx (rev 01) :08:05.0 RAID bus controller: Compaq Computer Corporation Smart Array 64xx (rev 01) :0b:00.0 RAID bus controller: Hewlett-Packard Company: Unknown device 3230 (rev 01) Module Size Used by joydev 12416 0 sg 43960 0 st 42660 0 sr_mod 20004 0 floppy 66000 0 ipv6 280192 17 ehci_hcd 35848 0 hw_random 7072 0 cciss 48392 0 uhci_hcd 34336 0 evdev 11776 0 usbcore 130192 3 ehci_hcd,uhci_hcd tg388708 0 dm_mod 63808 0 reiserfs 253680 1 mptscsih 38836 0 mptbase46944 1 mptscsih sd_mod 20352 3 scsi_mod 148176 6 sg,st,sr_mod,cciss,mptscsih,sd_mod md: stopping all md devices. md: md0 switched to read-only mode. Restarting system. machine restart machine restart ? f?x?? ProLiant System BIOS - P50 (12/02/2004) Copyright 1982, 2004 Hewlett-Packard Development Group, L.P. 5120 MB Detected Processor 1 initialized at 3.40 GHz/800 MHz(1 Mbyte L2) Advanced Memory Protection Mode: Advanced ECC Support Redundant ROM Detected - This system contains a valid backup system ROM. 5120 MB Initialized / 5120 MB Detected ProLiant System BIOS - P50 (12/02/2004) Copyright 1982, 2004 Hewlett-Packard Development Group, L.P. Processor 1 initialized at 3.40 GHz/800 MHz(1 Mbyte L2)
Re: Serial maintainership
On Thu, 8 Sep 2005, David S. Miller wrote: > > Ok, I'll revert the patch and fix the sunsab.c driver as > Russell indicated. So much for type checking... Actually, I think there's a simpler fix. Instead of reverting, how about something like this? (You might even remove the #ifdef inside the function by then, since "ch" being a constant zero will make 90% of it go away anyway). rmk? Davem? Linus --- diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -401,6 +401,9 @@ uart_handle_sysrq_char(struct uart_port #endif return 0; } +#ifndef SUPPORT_SYSRQ +#define uart_handle_sysrq_char(port,ch,regs) uart_handle_sysrq_char(port, 0, NULL) +#endif /* * We do the SysRQ and SAK checking like this... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3 htlb-acct] Demand faulting for hugetlb
Initial Post (Thu, 18 Aug 2005)
Basic overcommit checking for hugetlb_file_map() based on an implementation
used with demand faulting in SLES9.
Since demand faulting can't guarantee the availability of pages at mmap time,
this patch implements a basic sanity check to ensure that the number of huge
pages required to satisfy the mmap are currently available. Despite the
obvious race, I think it is a good start on doing proper accounting. I'd like
to work towards an accounting system that mimics the semantics of normal pages
(especially for the MAP_PRIVATE/COW case). That work is underway and builds on
what this patch starts.
Huge page shared memory segments are simpler and still maintain their commit on
shmget semantics.
Diffed against 2.6.13-git6
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
inode.c | 47 +++
1 files changed, 47 insertions(+)
diff -upN reference/fs/hugetlbfs/inode.c current/fs/hugetlbfs/inode.c
--- reference/fs/hugetlbfs/inode.c
+++ current/fs/hugetlbfs/inode.c
@@ -45,9 +45,51 @@ static struct backing_dev_info hugetlbfs
int sysctl_hugetlb_shm_group;
+static void huge_pagevec_release(struct pagevec *pvec);
+
+unsigned long
+huge_pages_needed(struct address_space *mapping, struct vm_area_struct *vma)
+{
+ int i;
+ struct pagevec pvec;
+ unsigned long start = vma->vm_start;
+ unsigned long end = vma->vm_end;
+ unsigned long hugepages = (end - start) >> HPAGE_SHIFT;
+ pgoff_t next = vma->vm_pgoff;
+ pgoff_t endpg = next + ((end - start) >> PAGE_SHIFT);
+ struct inode *inode = vma->vm_file->f_dentry->d_inode;
+
+ /*
+* Shared memory segments are accounted for at shget time,
+* not at shmat (when the mapping is actually created) so
+* check here if the memory has already been accounted for.
+*/
+ if (inode->i_blocks != 0)
+ return 0;
+
+ pagevec_init(, 0);
+ while (next < endpg) {
+ if (!pagevec_lookup(, mapping, next, PAGEVEC_SIZE))
+ break;
+ for (i = 0; i < pagevec_count(); i++) {
+ struct page *page = pvec.pages[i];
+ if (page->index > next)
+ next = page->index;
+ if (page->index >= endpg)
+ break;
+ next++;
+ hugepages--;
+ }
+ huge_pagevec_release();
+ }
+ return hugepages << HPAGE_SHIFT;
+}
+
static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
{
struct inode *inode = file->f_dentry->d_inode;
+ struct address_space *mapping = inode->i_mapping;
+ unsigned long bytes;
loff_t len, vma_len;
int ret;
@@ -66,6 +108,10 @@ static int hugetlbfs_file_mmap(struct fi
if (vma->vm_end - vma->vm_start < HPAGE_SIZE)
return -EINVAL;
+ bytes = huge_pages_needed(mapping, vma);
+ if (!is_hugepage_mem_enough(bytes))
+ return -ENOMEM;
+
vma_len = (loff_t)(vma->vm_end - vma->vm_start);
down(>i_sem);
@@ -794,6 +840,7 @@ struct file *hugetlb_zero_setup(size_t s
d_instantiate(dentry, inode);
inode->i_size = size;
inode->i_nlink = 0;
+ inode->i_blocks = 1;
file->f_vfsmnt = mntget(hugetlbfs_vfsmount);
file->f_dentry = dentry;
file->f_mapping = inode->i_mapping;
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3 htlb-fault] Demand faulting for hugetlb
Version 3 (Thu, 08 Aug 2005)
Organized logic in hugetlb_pte_fault() by breaking out
find_get_page/alloc_huge_page logic into separate function
Removed a few more paranoid checks <
Fixed tlb flushing in a race case < (thanks Yanmin Zhang)
Version 2 (Wed, 17 Aug 2005)
Removed spurious WARN_ON()
Patches added earlier in the series:
Check for p?d_none() in arch/i386/mm/hugetlbpage.c:huge_pte_offset()
Move i386 stale pte check into huge_pte_alloc()
Initial Post (Fri, 05 Aug 2005)
Below is a patch to implement demand faulting for huge pages. The main
motivation for changing from prefaulting to demand faulting is so that
huge page memory areas can be allocated according to NUMA policy.
Thanks to consolidated hugetlb code, switching the behavior requires changing
only one fault handler. The bulk of the patch just moves the logic from
hugelb_prefault() to hugetlb_pte_fault().
Diffed against 2.6.13-git6
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
fs/hugetlbfs/inode.c|6 -
include/linux/hugetlb.h |2
mm/hugetlb.c| 154 +---
mm/memory.c |2
4 files changed, 98 insertions(+), 66 deletions(-)
diff -upN reference/fs/hugetlbfs/inode.c current/fs/hugetlbfs/inode.c
--- reference/fs/hugetlbfs/inode.c
+++ current/fs/hugetlbfs/inode.c
@@ -48,7 +48,6 @@ int sysctl_hugetlb_shm_group;
static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
{
struct inode *inode = file->f_dentry->d_inode;
- struct address_space *mapping = inode->i_mapping;
loff_t len, vma_len;
int ret;
@@ -79,10 +78,7 @@ static int hugetlbfs_file_mmap(struct fi
if (!(vma->vm_flags & VM_WRITE) && len > inode->i_size)
goto out;
- ret = hugetlb_prefault(mapping, vma);
- if (ret)
- goto out;
-
+ ret = 0;
if (inode->i_size < len)
inode->i_size = len;
out:
diff -upN reference/include/linux/hugetlb.h current/include/linux/hugetlb.h
--- reference/include/linux/hugetlb.h
+++ current/include/linux/hugetlb.h
@@ -25,6 +25,8 @@ int is_hugepage_mem_enough(size_t);
unsigned long hugetlb_total_pages(void);
struct page *alloc_huge_page(void);
void free_huge_page(struct page *);
+int hugetlb_fault(struct mm_struct *mm, struct vm_area_struct * vma,
+ unsigned long address, int write_access);
extern unsigned long max_huge_pages;
extern const unsigned long hugetlb_zero, hugetlb_infinity;
diff -upN reference/mm/hugetlb.c current/mm/hugetlb.c
--- reference/mm/hugetlb.c
+++ current/mm/hugetlb.c
@@ -274,21 +274,22 @@ int copy_hugetlb_page_range(struct mm_st
{
pte_t *src_pte, *dst_pte, entry;
struct page *ptepage;
- unsigned long addr = vma->vm_start;
+ unsigned long addr;
unsigned long end = vma->vm_end;
- while (addr < end) {
+ for (addr = vma->vm_start; addr < end; addr += HPAGE_SIZE) {
+ src_pte = huge_pte_offset(src, addr);
+ if (!src_pte || pte_none(*src_pte))
+ continue;
+
dst_pte = huge_pte_alloc(dst, addr);
if (!dst_pte)
goto nomem;
- src_pte = huge_pte_offset(src, addr);
- BUG_ON(!src_pte || pte_none(*src_pte)); /* prefaulted */
entry = *src_pte;
ptepage = pte_page(entry);
get_page(ptepage);
add_mm_counter(dst, rss, HPAGE_SIZE / PAGE_SIZE);
set_huge_pte_at(dst, addr, dst_pte, entry);
- addr += HPAGE_SIZE;
}
return 0;
@@ -338,61 +339,6 @@ void zap_hugepage_range(struct vm_area_s
spin_unlock(>page_table_lock);
}
-int hugetlb_prefault(struct address_space *mapping, struct vm_area_struct *vma)
-{
- struct mm_struct *mm = current->mm;
- unsigned long addr;
- int ret = 0;
-
- WARN_ON(!is_vm_hugetlb_page(vma));
- BUG_ON(vma->vm_start & ~HPAGE_MASK);
- BUG_ON(vma->vm_end & ~HPAGE_MASK);
-
- hugetlb_prefault_arch_hook(mm);
-
- spin_lock(>page_table_lock);
- for (addr = vma->vm_start; addr < vma->vm_end; addr += HPAGE_SIZE) {
- unsigned long idx;
- pte_t *pte = huge_pte_alloc(mm, addr);
- struct page *page;
-
- if (!pte) {
- ret = -ENOMEM;
- goto out;
- }
-
- idx = ((addr - vma->vm_start) >> HPAGE_SHIFT)
- + (vma->vm_pgoff >> (HPAGE_SHIFT - PAGE_SHIFT));
- page = find_get_page(mapping, idx);
- if (!page) {
- /* charge the fs quota first */
- if (hugetlb_get_quota(mapping)) {
- ret = -ENOMEM;
- goto out;
-
Re: [PATCH 1/3] dynticks - implement no idle hz for x86
On 08.09.2005 [13:00:36 +0300], Tony Lindgren wrote:
> * Nishanth Aravamudan <[EMAIL PROTECTED]> [050907 18:07]:
> > On 07.09.2005 [10:37:43 +0300], Tony Lindgren wrote:
> > > * Nishanth Aravamudan <[EMAIL PROTECTED]> [050905 20:02]:
> > > > On 05.09.2005 [10:27:05 +0300], Tony Lindgren wrote:
> > > > > * Srivatsa Vaddagiri <[EMAIL PROTECTED]> [050905 10:03]:
> > > > > > On Sun, Sep 04, 2005 at 01:10:54PM -0700, Nishanth Aravamudan wrote:
> > > > > > >
> > > > > > > Also, I am a bit confused by the use of "dynamic-tick" to
> > > > > > > describe these
> > > > > > > changes. To me, these are all NO_IDLE_HZ implementations, as they
> > > > > > > are
> > > > > > > only invoked from cpu_idle() (or their equivalent) routines. I
> > > > > > > know this
> > > > > > > is true of s390 and the x86 code, and I believe it is true of the
> > > > > > > ARM
> > > > > > > code? If it were dynamic-tick, I would think we would be
> > > > > > > adjusting the
> > > > > > > timer interrupt frequency continuously (e.g., at the end of
> > > > > > > __run_timers() and at every call to {add,mod,del}_timer()). I was
> > > > > > > working on a patch which did some renaming to no_idle_hz_timer,
> > > > > > > etc.,
> > > > > > > but it's mostly code churn :)
> > > > > >
> > > > > > Yes, the name 'dynamic-tick' is misleading!
> > > > >
> > > > > Huh? For most people dynamic-tick is much more descriptive name than
> > > > > NO_IDLE_HZ or VST!
> > > >
> > > > I understand this. My point is that the structures are *not*
> > > > dynamic-tick specific. They are interrupt source specific, generally
> > > > (also known as hardware timers) -- dynamic tick or NO_IDLE_HZ are the
> > > > users of the interrupt source reprogramming functions, but not the
> > > > reprogrammers themselves, in my mind. Also, it still would be confusing
> > > > to use dynamic-tick, when the .config option is NO_IDLE_HZ! :)
> > >
> > > I see what you mean, it's a confusing naming issue currently :) Would
> > > the following solution work for you:
> > >
> > > - Dynamic tick is the structure you register with, and then you use it
> > > for any kind of non-continuous timer tinkering
> > >
> > > - This structure has at least two possible users, NO_IDLE_HZ and
> > > sub-jiffie timers
> > >
> > > So we could have following config options:
> > >
> > > CONFIG_DYNTICK
> > > CONFIG_NO_IDLE_HZ depends on dyntick
> > > CONFIG_SUBJIFFIE_TIMERdepends on dyntick
> >
> > Hrm, yes, first you are right with the dependency ordering. I take it
> > CONFIG_DYNTICK is simply there as NO_IDLE_HZ and SUBJIFFIE_TIMER are
> > independent users of the same underlying infrastructure.
>
> Cool, I'm glad we got the dependencies figured out now rather than later :)
Yup, I think that makes the most sense. I appreciate your help with it!
> > > > > If you wanted, you could reprogram the next timer to happen from
> > > > > {add,mod,del}_timer() just by calling the timer_dyn_reprogram() there.
> > > >
> > > > I messed with this with my soft-timer rework (which has since has fallen
> > > > by the wayside). It is a bit of overhead, especially del_timer(), but
> > > > it's possible. This is what I would consider "dynamic-tick." And I would
> > > > setup a *different* .config option to enable it. Perhaps depending on
> > > > CONFIG_NO_IDLE_HZ.
> > >
> > > Yes, I agree it should be a different .config option. Maybe the example
> > > above would work for that?
> >
> > Yes, I'm thinking it might.
> >
> > > > > And you would want to do that if you wanted sub-jiffie timer
> > > > > interrupts.
> > > >
> > > > Yes, true, it does enable that. Well, to be honest, it completely
> > > > redefines (in some sense) the jiffy, as it is potentially continuously
> > > > changing, not just at idle times.
> > >
> > > Yeah. But should still work as we already accept interrupts at any point
> > > inbetween jiffies to update time, and update the system time from a
> > > second continuously running timer :)
> >
> > The problem with subjiffie timers is that the precision of soft-timers
> > is jiffies currently. It requires some serious effort to modify the
> > soft-timer subsystem to be aware of the extra bits it needs,
> > efficiently -- take a look at what HRT has had to do.
>
> Yes, we should coordinate that with HRT. BTW, we can reduce the overhead
> of del_timer() by _not_ calling next_timer_interrupt(), and programming
> the next timer interrupt to happen where next jiffie would be. Then once
> we get to the idle, we call next_timer_interrupt()...
Yes, I agree with the del_timer() changes.
> > > > > So I'd rather not limit the name to the currently implemented
> > > > > functionality only :)
> > > >
> > > > I'm not trying to limit the name, but make sure we are tying the
> > > > strcutures and functions to the right abstraction (interrupt source, in
> > > > my opinion).
> > >
> > > But other devices are interrupt sources too... And really the only use
> > > for this stuct is
Re: [PATCH 1/3 htlb-get_user_pages] Demand faulting for hugetlb
Initial Post (Thu, 18 Aug 2005)
In preparation for hugetlb demand faulting, remove this get_user_pages()
optimization. Since huge pages will no longer be prefaulted, we can't assume
that the huge ptes are established and hence, calling follow_hugetlb_page() is
not valid.
With the follow_hugetlb_page() call removed, the normal code path will be
triggered. follow_page() will either use follow_huge_addr() or
follow_huge_pmd() to check for a previously faulted "page" to return. When
this fails (ie. with demand faults), __handle_mm_fault() gets called which
invokes the hugetlb_fault() handler to instantiate the huge page.
This patch doesn't make a lot of sense by itself, but I've broken it out to
facilitate discussion on this specific element of the demand fault changes.
While coding this up, I referenced previous discussion on this topic starting
at http://lkml.org/lkml/2004/4/13/176 , which contains more opinions about the
correctness of this approach.
Diffed against 2.6.13-git6
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
---
memory.c |5 -
1 files changed, 5 deletions(-)
diff -upN reference/mm/memory.c current/mm/memory.c
--- reference/mm/memory.c
+++ current/mm/memory.c
@@ -949,11 +949,6 @@ int get_user_pages(struct task_struct *t
|| !(flags & vma->vm_flags))
return i ? : -EFAULT;
- if (is_vm_hugetlb_page(vma)) {
- i = follow_hugetlb_page(mm, vma, pages, vmas,
- , , i);
- continue;
- }
spin_lock(>page_table_lock);
do {
int write_access = write;
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Automatic .config generation
On 9/8/05, Ahmad Reza Cheraghi <[EMAIL PROTECTED]> wrote: > I made this Framework to generate a .config based on a > Target-System. Right-now it works on my Laptop Acer how about teaching it to generate .config using just sysfs and lsbus? So noone will need to contact you regarding adding their system to your files, especially when all the information is already present in the kernel in a very parsable form (pci.ids, for example). The whole scenary will then shorten to: $ make autoconfig $ make - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: IPW2100 Kconfig
> AFAIK hotplug looks for firmware in /lib/firmware and not > /etc/firmware. > > On 9/8/05, Pavel Machek <[EMAIL PROTECTED]> wrote: > > Hi! > > > > > I checked the IPW2100 in the current git from > linux-2.6 and the menuconfig > > > help (Kconfig) says you need to put the firmware in > /etc/firmware, it should > > > be /lib/firmware. > > > > > > Who should I send the "patch" to? Or can someone simply > change that? > > > > Are you sure it is not distro-dependend? > > -- Right, IPW2100 came with Legacy fw load first. Maybe that was dragged from long time ago and used incorrectly. I'm 100% sure that new versions of hotplug try to look at /lib/firmware and was /usr/lib/hotplug/firmware before, but there was some discussion that /lib would make more sense cause /usr could be dependant on other stuff. Jesper already signed the patch. .Alejandro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] Consistently use the name asm-offsets.h
Today all architectures expect 3 generate an asm-offsets.h file.
The exceptions are: frv, m32r, sparc64
Most architectures uses a name similar to asm_offsets.h with small
differences. A few uses asm-consts.h and a few uses '-' instead of '_'.
I suggest moving all the logic required to build the asm-offsets.h file
to a common places and do proper search in architectures to make
the naming consitent. For frv, m32r and sparc64 we will need to create a
dummy file until they start using asm-offsets.h
The input file is consistently named asm-offsets.c so I plan to use the
name asm-offsets.h all over the place.
Sample patch for i386 (without renaming) below.
Notice that the chunk deleted from arch/i386/Makefile will be the same
for all architectures.
And as an added bonus introducing the below we finally get all
dependencies automatically tracked for the asm-offsets.h file.
This had slipped my mind for a long time but I was remineded when
I thougt about what dependencies could have been missed when using
bisect support in git.
If there is no objections I will see if I can have it ready before -rc1.
It's the dependency thing that want me to have is added soon.
The Kbuild file in the top-level directory is planned to be extended over
time. For now it contains only the asm-offsets stuff.
Sam
Kbuild | 40
Makefile | 37 ++---
arch/i386/Makefile |9 -
3 files changed, 50 insertions(+), 36 deletions(-)
diff --git a/Kbuild b/Kbuild
new file mode 100644
--- /dev/null
+++ b/Kbuild
@@ -0,0 +1,40 @@
+#
+# Kbuild for top-level directory of the kernel
+# This file takes care of the following:
+# 1) Generate asm-offsets.h
+
+# 1) Generate asm-offsets.h
+#
+
+offsets-file := include/asm-$(ARCH)/asm_offsets.h
+
+always := $(offsets-file)
+targets := $(offsets-file)
+targets += arch/$(ARCH)/kernel/asm-offsets.s
+
+quiet_cmd_offsets = GEN $@
+define cmd_offsets
+ cat $< | \
+ (set -e; \
+echo "#ifndef __ASM_OFFSETS_H__"; \
+echo "#define __ASM_OFFSETS_H__"; \
+echo "/*"; \
+echo " * DO NOT MODIFY."; \
+echo " *"; \
+echo " * This file was generated by $(srctree)/Kbuild"; \
+echo " *"; \
+echo " */"; \
+echo ""; \
+sed -ne "/^->/{s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /*
\3 */:; s:->::; p;}"; \
+echo ""; \
+echo "#endif" ) > $@
+endef
+
+# We use internal kbuild rules to avoid the "is up to date" message from make
+arch/$(ARCH)/kernel/asm-offsets.s: arch/$(ARCH)/kernel/asm-offsets.c FORCE
+ $(Q)mkdir -p $(dir $@)
+ $(call if_changed_dep,cc_s_c)
+
+$(srctree)/$(offsets-file): arch/$(ARCH)/kernel/asm-offsets.s Kbuild
+ $(call cmd,offsets)
+
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -776,14 +776,14 @@ $(vmlinux-dirs): prepare-all scripts
# A multi level approach is used. prepare1 is updated first, then prepare0.
# prepare-all is the collection point for the prepare targets.
-.PHONY: prepare-all prepare prepare0 prepare1 prepare2
+.PHONY: prepare-all prepare prepare0 prepare1 prepare2 prepare3
-# prepare2 is used to check if we are building in a separate output directory,
+# preparei3 is used to check if we are building in a separate output directory,
# and if so do:
# 1) Check that make has not been executed in the kernel src $(srctree)
# 2) Create the include2 directory, used for the second asm symlink
-prepare2:
+prepare3:
ifneq ($(KBUILD_SRC),)
@echo ' Using $(srctree) as source for kernel'
$(Q)if [ -f $(srctree)/.config ]; then \
@@ -795,16 +795,19 @@ ifneq ($(KBUILD_SRC),)
$(Q)ln -fsn $(srctree)/include/asm-$(ARCH) include2/asm
endif
-# prepare1 creates a makefile if using a separate output directory
-prepare1: prepare2 outputmakefile
+# prepare2 creates a makefile if using a separate output directory
+prepare2: prepare3 outputmakefile
-prepare0: prepare1 include/linux/version.h include/asm \
+prepare1: prepare2 include/linux/version.h include/asm \
include/config/MARKER
ifneq ($(KBUILD_MODULES),)
$(Q)rm -rf $(MODVERDIR)
$(Q)mkdir -p $(MODVERDIR)
endif
+prepare0: prepare1 FORCE
+ $(Q)$(MAKE) $(build)=$(srctree)
+
# All the preparing..
prepare-all: prepare0 prepare
@@ -949,26 +952,6 @@ modules modules_install: FORCE
endif # CONFIG_MODULES
-# Generate asm-offsets.h
-# ---
-
-define filechk_gen-asm-offsets
- (set -e; \
-echo "#ifndef __ASM_OFFSETS_H__"; \
-echo "#define __ASM_OFFSETS_H__"; \
-echo "/*"; \
-echo " * DO NOT MODIFY."; \
-echo " *"; \
-echo " * This file was generated by arch/$(ARCH)/Makefile"; \
-echo " *"; \
-echo " */"; \
-echo ""; \
-sed -ne "/^->/{s:^->\([^
[UPDATE] [PATCH 0/3] Demand faulting for hugetlb
Sending this out again after incorporating the feedback from Yanmin Zhang and Dave Hansen. Are we ready to go for -mm yet? The only patch which has seen any recent changes is #2 below so I assume people agree with #1 and #3 now :) The three patches: 1) Remove a get_user_pages() optimization that is no longer valid for demand faulting 2) Move fault logic from hugetlb_prefault() to hugetlb_pte_fault() 3) Apply a simple overcommit check so demand fault accounting behaves in a manner in line with how prefault worked Diffed against 2.6.13-git6 -- Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
