Lack of Documentation about SA_RESTART...
The documentation (man pages & info libc) doesn't cover well interaction between various syscalls and SA_RESTART flag of sigaction()... I wonder why! > MAN SIGACTION < "SA_RESTART Provide behaviour compatible with BSD signal semantics by making certain system calls restartable across signals." certain?!? :-O! > INFO LIBC < " One important exception is `EINTR' (*note Interrupted Primitives::). Many stream I/O implementations will treat it as an ordinary error, which can be quite inconvenient. You can avoid this hassle by installing all signals with the `SA_RESTART' flag." " -- Macro: int SA_RESTART This flag controls what happens when a signal is delivered during certain primitives (such as `open', `read' or `write'), and the signal handler returns normally. There are two alternatives: the library function can resume, or it can return failure with error code `EINTR'." Ok, "info libc" is a bit better. But what I'm looking for is a list of syscalls that are automatically restarted when SA_RESTART is set, and especially in what conditions. For example: read(), write(), open() are obviously restarted, but even on non-blocking fd? And what about connect() and select() for example? There are a lot of syscalls that can fail with "EINTR"! What's the advantage of using SA_RESTART if one doesn't know what syscalls are restarted? One should always check for "EINTR" or use "TEMP_FAILURE_RETRY()" macro as suggested in "info libc" ! Looking at the source I can easly see that a syscall is retarted when it returns "-ERESTARTSYS" and SA_RESTART flag is set. Should I look at the code for every syscall / particular condition? Example of behavior: according to source code it seems that "connect()" (the "net/ipv4/af_inet.c : inet_stream_connect()" implementation) returns -ERESTARTSYS if interrupted, but if the socket is in non-blocking mode it returns -EINTR. SUMMARY: 1) there is a reason for this lack of documentation? 2) what can I safely assume about syscalls restart when using SA_RESTART flag? Bye, -- Paolo Ornati Linux 2.6.12.2 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lack of Documentation about SA_RESTART...
On Mon, 11 Jul 2005 10:34:27 -0400 Theodore Ts'o <[EMAIL PROTECTED]> wrote: > According to the Single Unix Specification V3, all functions that > return EINTR are supposed to restart if a process receives a signal > where signal handler has been installed with the SA_RESTART flag. Thanks to have cited SUS... I'm reading it and is much cleaner than manpages :-) "SA_RESTART This flag affects the behavior of interruptible functions; that is, those specified to fail with errno set to [EINTR]. If set, and a function specified as interruptible is interrupted by this signal, the function shall restart and shall not fail with [EINTR] unless otherwise specified. If the flag is not set, interruptible functions interrupted by this signal shall fail with errno set to [EINTR]" Note the "unless otherwise specified". > > > Example of behavior: according to source code it seems that > > "connect()" (the "net/ipv4/af_inet.c : inet_stream_connect()" > > implementation) returns -ERESTARTSYS if interrupted, but if the > > socket is in non-blocking mode it returns -EINTR. > > If the socket is non-blocking mode, and there isn't a connection ready > to be received, then the socket is going to return with some kind of > errno set; either EINPROGRESS (Operation now in progress) or EALREADY > (Operation already in progress), or if a signal came in during the > system call (which would happen pretty rarely, the window for the race > condition is pretty small) it will return EINTR. I _think_ that a > close reading of the specification would state that the system call > should be restarted, and since a connection isn't ready, then at that > point EINPROGRESS or EALREADY would be returned. > Reading SUSV3 it seems that doing a connection with non-blocking socket CANNOT return EINTR... and this make sense. The particular case you analized (blocking connect interrupted by a SA_RESTART signal) is interesting... and since SUSV3 says "but the connection request shall not be aborted, and the connection shall be established asynchronously" (with select() or poll()...) both for EINPROGRESS and EINTR, I think it's quite stupit to automatically restart it and then return EALREADY. The logically correct behaviur with blocking connect interrupted and then restarted should be to continue the blocking wait... IHMO. -- Paolo Ornati Linux 2.6.12.2 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lack of Documentation about SA_RESTART...
On 11 Jul 2005 20:30:20 -0700 Philippe Troin <[EMAIL PROTECTED]> wrote: > Except for select() and poll(), which should always return EINTR even > when interrupted with a SA_RESTART signal. SUSV3 says this for select(): "If SA_RESTART has been set for the interrupting signal, it is implementation-defined whether the function restarts or returns with [EINTR]" and says nothing for poll()... But it says nothing also for "pause()", for example... and I doubt that it's supposed to be automatically restarted :) -- Paolo Ornati Linux 2.6.12.2 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lack of Documentation about SA_RESTART...
On Tue, 12 Jul 2005 10:38:11 +0200
Paolo Ornati <[EMAIL PROTECTED]> wrote:
> The particular case you analized (blocking connect interrupted by a
> SA_RESTART signal) is interesting... and since SUSV3 says
> "but the connection request shall not be aborted, and the
> connection shall be established asynchronously" (with select()
> or poll()...)
> both for EINPROGRESS and EINTR, I think it's quite stupit to
> automatically restart it and then return EALREADY.
>
> The logically correct behaviur with blocking connect interrupted and
> then restarted should be to continue the blocking wait... IHMO.
it seems that Linux is doing the Right Thing... see the attached
program...
$ make
gcc -O2 -Wall -o conntest connect_test.c
FROM ANOTHER CONSOLE: this is needed to block connect()...
# iptables -A OUTPUT -p tcp --dport 3500 -m state --state NEW -j DROP
$ ./conntest WITHOUT_SA_RESTART
connect(): errno = 4# EINTR, as expected
Cannot setup client!
$ ./conntest# connect is restarted after SIGALRM, and then it blocks again
FROM ANOTHER CONSOLE:
# iptables -D OUTPUT -p tcp --dport 3500 -m state --state NEW -j DROP
and then "conntest" (thanks to TCP protocol retries) will terminate.
:-)
--
Paolo Ornati
Linux 2.6.12.2 on x86_64
#include
#include
#include
#include
#include
#include
#include
#include
#include
void sighandler(int sig)
{
/* nothing :) */
}
int setup_alarm_handler(int flags)
{
struct sigaction sa = {
.sa_handler = &sighandler,
.sa_flags = flags
};
return sigaction(SIGALRM, &sa, NULL);
}
int setup_server(int port)
{
int sock;
struct sockaddr_in sa = {
.sin_family = AF_INET,
.sin_port = htons(port),
.sin_addr.s_addr = htonl(INADDR_ANY)
};
if ((sock=socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0)
goto error;
if (bind(sock, (struct sockaddr*)&sa, sizeof(sa)) < 0)
goto error_clean;
if (listen(sock, 16) < 0)
goto error_clean;
return sock;
error_clean:
close(sock);
error:
return -1;
}
int setup_client(const char *server, int port)
{
int sock;
struct sockaddr_in sa = {
.sin_family = AF_INET,
.sin_port = htons(port),
.sin_addr.s_addr = inet_addr(server)
};
if ((sock=socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0)
goto error;
if (connect(sock, (struct sockaddr*)&sa, sizeof(sa)) < 0) {
printf("connect(): errno = %d\n", errno);
goto error_clean;
}
return sock;
error_clean:
close(sock);
error:
return -1;
}
int main(int argc, char *argv[])
{
int server, client;
int flags = SA_RESTART;
if (argc > 1)
flags = 0;
if (setup_alarm_handler(flags))
return 1;
server = setup_server(3500);
if (server < 0) {
printf("Cannot setup server!\n");
return 1;
}
alarm(1);
client = setup_client("127.0.0.1", 3500);
if (client < 0) {
printf("Cannot setup client!\n");
return 1;
}
printf("Ok!\n");
return 0;
}
Makefile
Description: Binary data
Re: Lack of Documentation about SA_RESTART...
On Tue, 12 Jul 2005 08:04:56 -0400 Theodore Ts'o <[EMAIL PROTECTED]> wrote: > > > > The logically correct behaviur with blocking connect interrupted and > > then restarted should be to continue the blocking wait... IHMO. > > I was looking at what happened with a *non-blocking* connect > interrupted by an SA_RESTART signal. Since it is non-blocking, it > will never continue with the wait. The only question is whether it > should return with an EINTR (which is what it currently does) or > return with whatever error code it would have returned if the signal > had not been delievered in the first place. We currently do the > former; a close reading of the spec seems the require the latter. > Fortunately this is a pretty narrow race condition since the chances > of a signal being delivered right in the middle of a non-blocking > connect are small. Hmmm... no, no. A connect() on non-blocking socket will NEVER return EINTR. SUSV3 and Linux code agree. A syscall isn't magically interrupted if a signal arrives... it's the syscall that must check for pending signals and do the proper action (usually it will return with -EINTR or -ERESTARTSYS). A connect() on a blocking socket is something like this (very approssimative): 1) code to activate the connection 2) sleep waiting for something (connection ready / signal received...) 3) if connection is ready then return 0, else if there are pending signals return -ERESTARTSYS With non-blocking socket the syscall never sleeps, and never checks for pending signals. Look at "net/ipv4/af_inet.c": in particular at "net_wait_for_connect" and its usage in "inet_stream_connect". -- Paolo Ornati Linux 2.6.12.2 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lack of Documentation about SA_RESTART...
On Tue, 12 Jul 2005 14:16:35 -0400
Theodore Ts'o <[EMAIL PROTECTED]> wrote:
> Yes, do look at that. From the latest 2.6 sources:
>
> timeo = sock_sndtimeo(sk, flags & O_NONBLOCK);
>
> if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
> /* Error code is set above */
> if (!timeo || !inet_wait_for_connect(sk, timeo))
> goto out;
>
> err = sock_intr_errno(timeo);
> if (signal_pending(current))
> goto out;
> }
>
> If the socket is non-blocking, then we don't call
> inet_wiat_for_connect(), yes. But sock_intr_errno() will set the
> error code to -EINTR if the socket is set to non-nonblocking (see
> include/net/sock.h), and if a signal is pending, return it.
No.
With non-blocking socket "timeo" is set to 0. So the instruction:
if (!timeo || !inet_wait_for_connect(sk, timeo))
goto out;
jumps directly to "out" label. "sock_intr_errno()" isn't called.
--
Paolo Ornati
Linux 2.6.12.2 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.4.20, 2.4.21, 2.4.22 , ... does not compile with gcc-3.4.X
On Fri, 22 Jul 2005 00:53:07 -0700 (PDT) Drosos Kourounis <[EMAIL PROTECTED]> wrote: > Dear Developers, > This might be a known issue but it is not known to me! > I tried to compile kernel 2.4.22 under Crux Linux, > and the compilation stopped in sched.c. I do not have > to say much to you because it seems a compiler > problem! Linux 2.4.22 is quite old: 25-Aug-2003... Have you tried with 2.4.31? -- Paolo Ornati Linux 2.6.13-rc3 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lack of Documentation about SA_RESTART...
On Sat, 23 Jul 2005 17:30:42 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > According to the Single Unix Specification V3, all functions that > > return EINTR are supposed to restart if a process receives a signal > > where signal handler has been installed with the SA_RESTART flag. > > That can't be right. SUV3 is really lacking about it: sigaction() "SA_RESTART [XSI] [Option Start] This flag affects the behavior of interruptible functions; that is, those specified to fail with errno set to [EINTR]. If set, and a function specified as interruptible is interrupted by this signal, the function shall restart and shall not fail with [EINTR] unless otherwise specified. If the flag is not set, interruptible functions interrupted by this signal shall fail with errno set to [EINTR]." Note the "unless otherwise specified"... but then SA_RESTART is only mentioned for: select/pselect "[XSI] [Option Start] If SA_RESTART has been set for the interrupting signal, it is implementation-defined whether the function restarts or returns with [EINTR]." and for other few signal handling functions like bsd_signal(), siginterrupt(), signal()... but just to say what SA_RESTART means. Then, reading xrat/xsh_chap02.html: "Signal Effects on Other Functions The most common behavior of an interrupted function after a signal-catching function returns is for the interrupted function to give an [EINTR] error unless the SA_RESTART flag is in effect for the signal. However, there are a number of specific exceptions, including sleep() and certain situations with read() and write(). The historical implementations of many functions defined by IEEE Std 1003.1-2001 are not interruptible, but delay delivery of signals generated during their execution until after they complete. This is never a problem for functions that are guaranteed to complete in a short (imperceptible to a human) period of time. It is normally those functions that can suspend a process indefinitely or for long periods of time (for example, wait(), pause(), sigsuspend(), sleep(), or read()/ write() on a slow device like a terminal) that are interruptible. This permits applications to respond to interactive signals or to set timeouts on calls to most such functions with alarm(). Therefore, implementations should generally make such functions (including ones defined as extensions) interruptible. Functions not mentioned explicitly as interruptible may be so on some implementations, possibly as an extension where the function gives an [EINTR] error. There are several functions (for example, getpid(), getuid()) that are specified as never returning an error, which can thus never be extended in this way. If a signal-catching function returns while the SA_RESTART flag is in effect, an interrupted function is restarted at the point it was interrupted. Conforming applications cannot make assumptions about the internal behavior of interrupted functions, even if the functions are async-signal-safe. For example, suppose the read() function is interrupted with SA_RESTART in effect, the signal-catching function closes the file descriptor being read from and returns, and the read() function is then restarted; in this case the application cannot assume that the read() function will give an [EBADF] error, since read() might have checked the file descriptor for validity before being interrupted." FreeBSD doc (man page of sigaction) is much better: http://www.gsp.com/cgi-bin/man.cgi?section=2&topic=sigaction "If a signal is caught during the system calls listed below, the call may be forced to terminate with the error EINTR, the call may return with a data transfer shorter than requested, or the call may be restarted. Restart of pending calls is requested by setting the SA_RESTART bit in sa_flags. The affected system calls include open(2), read(2), write(2), sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications channel or a slow device (such as a terminal, but not a regular file) and during a wait(2) or ioctl(2). However, calls that have already committed are not restarted, but instead return a partial success (for example, a short read count)." Finally, in Linux other syscalls can be restarted... like connect(), for example. -- Paolo Ornati Linux 2.6.13-rc3 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lack of Documentation about SA_RESTART...
On Sun, 24 Jul 2005 10:56:08 -0400 Theodore Ts'o <[EMAIL PROTECTED]> wrote: > The spect says "unless otherwise specified". The description for > pause() states that the process will sleep until receiving a signal > that terminates the process or causes it to call signal-handling > function. That would presumably count as an "otherwise specified". I don't think that way for at least 2 reasons: 1) SA_RESTART is an XSI extension, so every exception to the rule "everything automatically restarted" should be under an XSI section (like it is on the "select()" page). 2) The same thing that you claim for "pause()" (that isn't restarted) can be claimed for other syscalls that _ARE_ restarted. Example: wait() SUSV3 DOC: "... The wait() function shall suspend execution of the calling thread until status information for one of the terminated child processes of the calling process is available, or until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process ..." And wait() is actually RESTARTED because: - it makes sense - FreeBSD sigaction() mapage says it is retarted - Linux does it (see kernel/exit.c) ... retval = -ERESTARTSYS; if (signal_pending(current)) goto end; ... See? -- Paolo Ornati Linux 2.6.13-rc3 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel cached memory
On Mon, 25 Jul 2005 12:47:50 -0400 Bill Davidsen <[EMAIL PROTECTED]> wrote: > And IMHO Linux is *way* too willing to evicy clean pages of my > programs to use as disk buffer, so that when system memory is full I > pay the overhead of TWO disk i/o's, one to finally write the data to > the disk and one to read my program back in. If free software is > about choice, I wish there was more in the area of how memory is > used. isn't this tuned enough by "/proc/sys/vm/swappiness" ? -- Paolo Ornati Linux 2.6.13-rc3 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: time
On Thu, 07 Jul 2005 16:44:53 +0530 raja <[EMAIL PROTECTED]> wrote: > would you please tell how to caliculate the time taken to execute a c > program in unix environment. raja, this has nothing to do with Linux Kernel. PS: see "man time" -- Paolo Ornati Linux 2.6.12.2 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ipc
On Thu, 07 Jul 2005 17:01:51 +0530 raja <[EMAIL PROTECTED]> wrote: > Hi, > While working with posix ipc i used the function mq_open. > When i compiled using gcc i am getting error as > > : undefined reference to `mq_open' > collect2: ld returned 1 exit status > > will you please tell me how to avoid that. Also this has nothing to do with kernel, stop posting here these questions. You need to tell GCC to use "libmqueue"... something like this: gcc -Wall -O2 -o prog prog.c -lmqueue Please read this book for other generic programming questions: http://www.advancedlinuxprogramming.com/ And use Google. -- Paolo Ornati Linux 2.6.12.2 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ipc
On Thu, 7 Jul 2005 08:27:48 -0400
Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> If you have glibc 2.3.4 or later, you should use -lrt instead.
Yes... I was just saying that he forgot to add "-lLIBRAY_NAME" :)
--
Paolo Ornati
Linux 2.6.12.2 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] volatile keyword
On Thu, 25 Aug 2005 13:44:55 -0700 (PDT)
Vadim Lobanov <[EMAIL PROTECTED]> wrote:
> int main (void) {
> pthread_t other;
>
> data.lock = 1;
> data.value = 1;
> pthread_create(&other, NULL, thread, NULL);
> while ((volatile unsigned long)(data.lock));
> printf("Value is %lu.\n", data.value);
> pthread_join(other, NULL);
>
> return 0;
> }
The "correct" way should be:
while (*(volatile unsigned long*)(&data.lock));
With only: "while ((volatile unsigned long)(data.lock))" GCC isn't
forced to read to memory simply because "data.lock" isn't volatile.
What than you do with "data.lock" value doesn't change anything. IOW
you should get the same assembly code with and without the cast.
SUMMARY
"(volatile unsigned long)(data.lock)" means:
- take the value of "data.lock" (that isn't volatile so can be
cached)
- cast it to "volatile" (a no-op, since we already HAVE the
value)
"*(volatile unsigned long*)(&data.lock)":
- take the address of "data.lock"
- cast it to "volatile"
- read from _memory_ the value of data.lock (through the
volatile pointer)
Other ways can be:
- use read memory barrier:
while (data.lock)
rmb();
- use everything that implies a memory barrier (eg: locking...)
PS: everything I've said is rigorously NOT tested. :-)
--
Paolo Ornati
Linux 2.6.13-rc7 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: programs vanish with 2.6.22+
On Sat, 8 Dec 2007 13:12:14 +0100 Markus <[EMAIL PROTECTED]> wrote: > I try that, but it will take a lot of time! > > Markus This problem remembers me something... http://groups.google.com/group/linux.kernel/browse_thread/thread/85859519ffec7dc8/591a0b3a05bd3596?lnk=gst&q=konqueror+vanish#591a0b3a05bd3596 Are you the same Markus? (or it's just a coincidence?) It seems the same BUG... -- Paolo Ornati Linux 2.6.24-rc4-g7e1fb765 on x86_64 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT] Port 0x80 I/O speed
On Wed, 12 Dec 2007 00:31:18 +0100 Rene Herman <[EMAIL PROTECTED]> wrote: > > and on a PII 400 (Intel 440BX chipset) a constant: > > [EMAIL PROTECTED]:~/src/port80$ su -c ./port80 > cycles: out 553, in 251 > > Results are (mostly) independent of compiler optimisation, but testing with > an -O2 compile should be most useful. Thanks! > ### Core2 Duo 1.8 GHz ### X86_64 -m32 -O2: $ for i in `seq 5`; do sudo ./port80; sleep 1; done cycles: out 1498, in 964 cycles: out 1498, in 964 cycles: out 1499, in 964 cycles: out 1498, in 964 cycles: out 1498, in 965 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1864.805 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3731.82 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: [...] -- Paolo Ornati Linux 2.6.24-rc4-g94545bad on x86_64 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT] Port 0x80 I/O speed
On 12 Dec 2007 06:20:49 -0500 [EMAIL PROTECTED] wrote: > With -O2, the cycle counts come out (before division) as > out: 0xFFEA6F4F > in: 0xFCE68BB6 > I think the "A" constraint doesn't work quite the same in > 64-bit code. The compiler seems to be using %rdx rather than > %edx:%eax. In another message he says to compile it with "-m32" :) -- Paolo Ornati Linux 2.6.24-rc5-g4af75653 on x86_64 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] blacklist NCQ on Seagate Barracuda ST380817AS
On Tue, 02 Oct 2007 18:19:14 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > Yeah, "World's first" is a pretty good clue indicating "broken". > Blacklisting it seems like a good idea after all. OT: I cannot test anything NCQ related for a while because the Intel Mobo departed yesterday, so I'm on a different board without NCQ support ;) -- Paolo Ornati Linux 2.6.23-rc8generic-ga64314e6 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD 64 and Kernel AGPart support
On Thu, 17 Feb 2005 15:08:32 +0100 Marc Cramdal <[EMAIL PROTECTED]> wrote: > I have an AMD 64 (gentoo compiled for amd64) and I would like to > succeed in my video driver installation (ATI Radeon 9250 :-/). I would > need the agpgart support for the Sis Chipset, but all the entry for > agpgart are grayed, I can't change anything (Kernel 2.6.9, 2.6.10 ...) > > So is it normal or a bug ?? , or am I making a mistake. I have an AMD Athlon64 with Radeon 9200SE on VIA K8T800 Chipset... and AGP works fine with only CONFIG_AGP_AMD64 enabled. The fact is that these AMD processors have an "on-CPU northbridge" for AGP, and the support for the various external AGP bridges (VIA, SiS, Nvidia) is provided directly in "drivers/char/agp/amd64-agp.c" driver (selected by CONFIG_AGP_AMD64). Reading "drivers/char/agp/amd64-agp.c" I can see that "SIS 755" chipset is supported. If you have a chipset that isn't supported you can always try with the "agp_try_unsupported=1" option (as stated in the HELP of CONFIG_AGP_AMD64). > > NB: one of my friends made the test, without AMD64 and exactly the > same kernel he can check these options within agpgart... You don't have to be on a i386 to see the options avaiable for i386... just do a "make menuconfig ARCH=i386" and you are done! But if you are on x86_64, why do you want to enable drivers for other architectures? -- Paolo Ornati Gentoo Linux (kernel 2.6.10-gentoo-r7) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ________________: Re: AMD 64 and Kernel AGPart support
On Thu, 17 Feb 2005 15:42:50 +0100
[EMAIL PROTECTED] wrote:
> ÄúºÃ£º
> ÎÒÒÑ_ÊÕµ_ÄúµÄÀ_ÐÅ
and... what does this means?
--
Paolo Ornati
Gentoo Linux (kernel 2.6.10-gentoo-r7)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ________________: Re: AMD 64 and Kernel AGPart support
On Thu, 17 Feb 2005 10:26:55 -0500 Parag Warudkar <[EMAIL PROTECTED]> wrote: > SPAM. This looks to me like a new way of spamming though, replying to > valid mailing list messages. (I too received couple of these in reply > to my messages.) agrrr.. and I've done a mistake replying! -- Paolo Ornati Gentoo Linux (kernel 2.6.10-gentoo-r7) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: L1_CACHE
On Sat, 05 Feb 2005 11:45:22 + Axel Schmalowsky <[EMAIL PROTECTED]> wrote: > Can anyone tell me if it is destruktive or does it cause lose of > performance if I set up > L1_CACHE_SHIFT_MAX as well as CONFIG_X86_L1_CACHE_SHIFT to the value > of 10? > > I've an Intel centrino processor with 1MB L1-Cache. 1 MB L1? Isn't it L2? -- Paolo Ornati Gentoo Linux (kernel 2.6.10-gentoo-r6) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:
On Wed, 19 Jan 2005 16:25:22 +0200 Gmail <[EMAIL PROTECTED]> wrote: > !!! ERROR: sys-apps/module-init-tools-3.0-r2 failed. > !!! Function src_compile, Line 1980, Exitcode 2 > !!! emake module-init-tools failed > !!! If you need support, post the topmost build error, NOT this status > message. > > phases failed Can you explain me what this has to do with Linux Kernel? You are using Gentoo and a compilation failed, go here: http://bugs.gentoo.org/ and search for "ALL module-init-tools", if you don't find the solution then post a new BUG report. -- Paolo Ornati Gentoo Linux (kernel 2.6.10-gentoo-r4) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 with kernel 2.6.22-git15, 2.6.23-rc1
On Mon, 23 Jul 2007 09:40:04 -0300 (GFT) "werner" <[EMAIL PROTECTED]> wrote: > > The kernel need to stay compatible to old versions of the file system and > other fundamental programs. This sounds new to me... Documentation/stable_api_nonsense.txt -- Paolo Ornati Linux 2.6.22-cfs-v19-g03634801 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "double" hpet clocksource && hard freeze [bisected]
On Mon, 27 Aug 2007 17:34:58 -0300 "Luiz Fernando N. Capitulino" <[EMAIL PROTECTED]> wrote: > | Yea. While I'm still not completely comfortable leaving this up to boot > | order alone (the ia64 hpet clocksource is clearly causing issues on > | x86_64), I think this patch is something we need as well. > > Does -stable need this too? No :) -- Paolo Ornati Linux 2.6.22.5 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "double" hpet clocksource && hard freeze [bisected]
On Tue, 28 Aug 2007 10:27:09 +0200 Clemens Ladisch <[EMAIL PROTECTED]> wrote: > Luck, Tony wrote: > > [...] Given that the hang went away when you applied the earlier patch, I > > conclude that the drivers/char/hpet.c code is the one that got selected when > > you had two "hpet" entries ... and that there is something wrong with that > > code that doesn't work right on x86_64. > > Apparently, the 'generic' code was just copied from ia64 and assumes that the > timer is 64 bits. This is not true with hardware from VIA (even on x86_64). The hardware of this PC is Intel, not VIA. > > This patch should make it work (although I'd prefer to set the mask > dynamically > according to the hardware caps). > > --- a/drivers/char/hpet.c Tue Aug 28 09:42:22 2007 > +++ b/drivers/char/hpet.c Tue Aug 28 10:16:54 2007 > @@ -73,7 +73,7 @@ > .name = "hpet", > .rating = 250, > .read = read_hpet, > -.mask = CLOCKSOURCE_MASK(64), > +.mask = CLOCKSOURCE_MASK(32), Anyway, I've applied it (manually... whitespace/mime damage) to -rc4 and it seems to work, no crash so far (I'm sure I'm testing it because plain -rc4 doesn't have the "2hpet" fix and still manifest the problem). -- Paolo Ornati Linux 2.6.23-rc4-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
WARNING: at arch/x86_64/kernel/smp.c:379 smp_call_function_single()
Just got this warning during suspend2ram (2.6.23-rc2-gac078602). Config and full dmesg attached. [ 756.707601] Disabling non-boot CPUs ... [ 756.712034] kvm: disabling virtualization on CPU1 [ 756.712037] WARNING: at arch/x86_64/kernel/smp.c:379 smp_call_function_single() [ 756.712039] [ 756.712039] Call Trace: [ 756.712046] [] smp_call_function_single+0x119/0x120 [ 756.712050] [] thread_return+0x1bf/0x626 [ 756.712054] [] sys_sched_yield+0x2b/0x80 [ 756.712057] [] kvm_cpu_hotplug+0x4b/0xa0 [ 756.712060] [] notifier_call_chain+0x53/0x80 [ 756.712062] [] __raw_notifier_call_chain+0x9/0x10 [ 756.712065] [] raw_notifier_call_chain+0x11/0x20 [ 756.712068] [] take_cpu_down+0x1b/0x30 [ 756.712071] [] do_stop+0xd2/0x150 [ 756.712073] [] do_stop+0x0/0x150 [ 756.712076] [] kthread+0x4d/0x80 [ 756.712079] [] child_rip+0xa/0x12 [ 756.712081] [] restore_args+0x0/0x30 [ 756.712084] [] kthread+0x0/0x80 [ 756.712086] [] child_rip+0x0/0x12 [ 756.712087] [ 756.815693] CPU 1 is now offline [ 756.815697] lockdep: not fixing up alternatives. [ 756.819276] CPU1 is down -- Paolo Ornati Linux 2.6.23-rc2-gac078602 on x86_64 config.gz Description: GNU Zip compressed data dmesg.gz Description: GNU Zip compressed data
Re: reset during bootup - solved
On Sun, 12 Aug 2007 05:44:36 -0400
"Dan Merillat" <[EMAIL PROTECTED]> wrote:
> However, a git-pull at 2am (b8d3f244) fixed it. Not sure where in
> there it started working again, I can bisect backwards to find out if
> need be.
I think it is was fixed by this one:
Do not replace whole memcpy in apply alternatives
apply_alternatives uses memcpy() to apply alternatives. Which has the
unfortunate effect that while applying memcpy alternative to memcpy
itself it tries to overwrite itself with nops - which causes #UD fault
as it overwrites half of an instruction in copy loop, and from this
point on only possible outcome is triplefault and reboot.
b8d3f2448b8f4ba24f301e23585547ba1acc1f04
arch/x86_64/lib/memcpy.S |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/x86_64/lib/memcpy.S b/arch/x86_64/lib/memcpy.S
index 0ea0ddc..c22981f 100644
--- a/arch/x86_64/lib/memcpy.S
+++ b/arch/x86_64/lib/memcpy.S
@@ -124,6 +124,8 @@ ENDPROC(__memcpy)
.quad memcpy
.quad 1b
.byte X86_FEATURE_REP_GOOD
- .byte .Lfinal - memcpy
+ /* Replace only beginning, memcpy is used to apply alternatives, so it
+* is silly to overwrite itself with nops - reboot is only outcome... */
+ .byte 2b - 1b
.byte 2b - 1b
.previous
--
Paolo Ornati
Linux 2.6.23-rc2-gac078602 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Please remove ab144f5ec64c42218a555ec1dbde6b60cf2982d6 was Re: [discuss] [PATCH] Fix triplefault on x86-64 bootup
On 12 Aug 2007 15:55:50 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > Ok Linus already applied your patch. Even though it's a really bad
> > > fragile hack, not better than the old bug.
> > > Petr are you double sure you really tested with
> > > ab144f5ec64c42218a555ec1dbde6b60cf2982d6
> > > already applied? I bet not -- it is the symptom exactly fixed by this
> > > patch
> >
> > I'm quite sure that this patch is in my tree, as I have that "u8
> > *instr = a->instr;" in apply_alternatives, and it seems that this one
> > was added by checkin you mention... My tree was synced up to:
>
> Can you double check? I have a hard time believing it.
I've seen the reboot too, with "rc2-g3864e8cc" that is newer than
ab144f5ec64c4:
$ git-log ab144f5ec64c4..| grep 3864e8cc
commit 3864e8ccbba1dcdea87398ab80fdc8ae0fab7c45
--
Paolo Ornati
Linux 2.6.23-rc2-gac078602 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at arch/x86_64/kernel/smp.c:379 smp_call_function_single()
On Fri, 10 Aug 2007 14:04:33 +0200 "Michal Piotrowski" <[EMAIL PROTECTED]> wrote: > > [ 756.707601] Disabling non-boot CPUs ... > > [ 756.712034] kvm: disabling virtualization on CPU1 > > [ 756.712037] WARNING: at arch/x86_64/kernel/smp.c:379 > > smp_call_function_single() > > [ 756.712039] > > [ 756.712039] Call Trace: > > [ 756.712046] [] smp_call_function_single+0x119/0x120 > > [ 756.712050] [] thread_return+0x1bf/0x626 > > [ 756.712054] [] sys_sched_yield+0x2b/0x80 > > [ 756.712057] [] kvm_cpu_hotplug+0x4b/0xa0 > > [ 756.712060] [] notifier_call_chain+0x53/0x80 > > [ 756.712062] [] __raw_notifier_call_chain+0x9/0x10 > > [ 756.712065] [] raw_notifier_call_chain+0x11/0x20 > > [ 756.712068] [] take_cpu_down+0x1b/0x30 > > [ 756.712071] [] do_stop+0xd2/0x150 > > [ 756.712073] [] do_stop+0x0/0x150 > > [ 756.712076] [] kthread+0x4d/0x80 > > [ 756.712079] [] child_rip+0xa/0x12 > > [ 756.712081] [] restore_args+0x0/0x30 > > [ 756.712084] [] kthread+0x0/0x80 > > [ 756.712086] [] child_rip+0x0/0x12 > > [ 756.712087] > > [ 756.815693] CPU 1 is now offline > > [ 756.815697] lockdep: not fixing up alternatives. > > [ 756.819276] CPU1 is down > > > > Added to KR list, thanks for the report. I've bisected it down to this commit: cec9ad279b66793bee0b5009b7ca311060061efd KVM: Use CPU_DYING for disabling virtualization Only at the CPU_DYING stage can we be sure that no user process will be scheduled onto the cpu and oops when trying to use virtualization extensions. $ git-bisect log git-bisect start # bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1 git-bisect bad f695baf2df9e0413d3521661070103711545207a # good: [7dcca30a32aadb0520417521b0c44f42d09fe05c] Linux 2.6.22 git-bisect good 7dcca30a32aadb0520417521b0c44f42d09fe05c # good: [1f1c2881f673671539b25686df463518d69c4649] Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6 git-bisect good 1f1c2881f673671539b25686df463518d69c4649 # bad: [3cf01f28c303be34f18cb4f6204cf1bdfe12ba7c] coda: remove statistics counters from /proc/fs/coda git-bisect bad 3cf01f28c303be34f18cb4f6204cf1bdfe12ba7c # bad: [b8c638acacfe32c0bde361916467af00691f1965] Merge branch 'uninit-var' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6 git-bisect bad b8c638acacfe32c0bde361916467af00691f1965 # good: [c06e677aed0c86480b01faa894967daa8aa3568a] SPI: add 3wire mode flag git-bisect good c06e677aed0c86480b01faa894967daa8aa3568a # good: [90da63e54604fd515c17014a0a7f332a018a0a11] fbdev: extract fb_show_logo_line() git-bisect good 90da63e54604fd515c17014a0a7f332a018a0a11 # good: [e495606dd09d79f9fa496334ac3958f6ff179d82] KVM: Clean up #includes git-bisect good e495606dd09d79f9fa496334ac3958f6ff179d82 # good: [27d41718157626e4509026c7dac247a659c0e71f] mark a bunch of ISA|EISA|PCI drivers as such git-bisect good 27d41718157626e4509026c7dac247a659c0e71f # bad: [3bd858ab1c451725c07a805dcb315215dc85b86e] Introduce is_owner_or_cap() to wrap CAP_FOWNER use with fsuid check git-bisect bad 3bd858ab1c451725c07a805dcb315215dc85b86e # bad: [cec9ad279b66793bee0b5009b7ca311060061efd] KVM: Use CPU_DYING for disabling virtualization git-bisect bad cec9ad279b66793bee0b5009b7ca311060061efd # good: [401bbcb0d0be8c916134b4e9074826e89638] x86_64: Allow smp_call_function_single() to current cpu git-bisect good 401bbcb0d0be8c916134b4e9074826e89638 # good: [a52b1752c077cb919b71167c54968a0b91673281] SMP: Allow smp_call_function_single() to current cpu git-bisect good a52b1752c077cb919b71167c54968a0b91673281 # good: [4267c41a458cd7d287dc8031468fc385c2f5b2c3] KVM: Tune hotplug/suspend IPIs git-bisect good 4267c41a458cd7d287dc8031468fc385c2f5b2c3 -- Paolo Ornati Linux 2.6.23-rc3 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
spontaneous disconnect with "usb-storage: implement autosuspend"
Hi, with "CONFIG_USB_SUSPEND=y", since commit: 8dfe4b14869fd185ca25ee88b02ada58a3005eaf usb-storage: implement autosuspend This patch (as930) implements autosuspend for usb-storage. It is adapted from a patch by Oliver Neukum. Autosuspend is allowed except during LUN scanning, resets, and command execution. my USB photo-camera gets automagically disconnected before I can do anything with it ;) Relevant dmesg (what I get by just attaching it): [ 70.722898] scsi 8:0:0:0: Direct-Access HP PHOTOSMART E317 A001 PQ: 0 ANSI: 0 CCS [ 70.727880] sd 8:0:0:0: [sdb] 488448 512-byte hardware sectors (250 MB) [ 70.730876] sd 8:0:0:0: [sdb] Write Protect is off [ 70.730879] sd 8:0:0:0: [sdb] Mode Sense: 00 46 00 00 [ 70.730882] sd 8:0:0:0: [sdb] Assuming drive cache: write through [ 70.742874] sd 8:0:0:0: [sdb] 488448 512-byte hardware sectors (250 MB) [ 70.745873] sd 8:0:0:0: [sdb] Write Protect is off [ 70.745876] sd 8:0:0:0: [sdb] Mode Sense: 00 46 00 00 [ 70.745878] sd 8:0:0:0: [sdb] Assuming drive cache: write through [ 70.745882] sdb: sdb1 [ 70.755192] sd 8:0:0:0: [sdb] Attached SCSI removable disk [ 70.755446] sd 8:0:0:0: Attached scsi generic sg3 type 0 [ 70.755657] usb-storage: device scan complete [ 73.071490] usb 6-2: usb auto-suspend [ 73.321445] hub 6-0:1.0: state 7 ports 2 chg evt 0004 [ 73.321453] uhci_hcd :00:1d.1: port 2 portsc 108a,00 [ 73.321462] hub 6-0:1.0: port 2, status 0100, change 0003, 12 Mb/s [ 73.321465] usb 6-2: USB disconnect, address 2 [ 73.321467] usb 6-2: unregistering device The relevant differences of dmesg between pre and post "autosuspend" patch: @@ -1,4 +1,4 @@ - Linux version 2.6.22-gb0e2a705 ... + Linux version 2.6.22-g8dfe4b14 ... @@ -606,6 +606,12 @@ hub 1-0:1.0: hub_suspend usb usb1: bus auto-suspend ehci_hcd :00:1a.7: suspend root hub + hub 4-0:1.0: hub_suspend + usb usb4: bus auto-suspend + usb usb4: suspend_rh + hub 5-0:1.0: hub_suspend + usb usb5: bus auto-suspend + usb usb5: suspend_rh hub 6-0:1.0: hub_suspend usb usb6: bus auto-suspend usb usb6: suspend_rh @@ -618,12 +624,6 @@ hub 3-0:1.0: hub_suspend usb usb3: bus auto-suspend usb usb3: suspend_rh - hub 4-0:1.0: hub_suspend - usb usb4: bus auto-suspend - usb usb4: suspend_rh - hub 5-0:1.0: hub_suspend - usb usb5: bus auto-suspend - usb usb5: suspend_rh usb usb3: uevent usb 3-0:1.0: uevent usb 3-0:1.0: uevent @@ -686,6 +686,7 @@ usb-storage 6-2:1.0: usb_probe_interface - got id scsi8 : SCSI emulation for USB Mass Storage devices drivers/usb/core/inode.c: creating file '002' + hub 6-0:1.0: state 7 ports 2 chg evt 0004 usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning hub 2-0:1.0: hub_suspend @@ -704,3 +705,22 @@ sd 8:0:0:0: [sdb] Attached SCSI removable disk sd 8:0:0:0: Attached scsi generic sg3 type 0 usb-storage: device scan complete + usb 6-2: usb auto-suspend + hub 6-0:1.0: state 7 ports 2 chg evt 0004 + uhci_hcd :00:1d.1: port 2 portsc 108a,00 + hub 6-0:1.0: port 2, status 0100, change 0003, 12 Mb/s + usb 6-2: USB disconnect, address 2 + usb 6-2: unregistering device + usb 6-2: usb_disable_device nuking all URBs + usb 6-2: unregistering interface 6-2:1.0 + usb_endpoint usbdev6.2_ep82: ep_device_release called for usbdev6.2_ep82 + usb_endpoint usbdev6.2_ep03: ep_device_release called for usbdev6.2_ep03 + usb 6-2:1.0: uevent + usb 6-2:1.0: uevent + usb_endpoint usbdev6.2_ep00: ep_device_release called for usbdev6.2_ep00 + usb 6-2: uevent + hub 6-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100 + usb usb6: suspend_rh (auto-stop) + hub 6-0:1.0: hub_suspend + usb usb6: bus auto-suspend + usb usb6: suspend_rh config for 2.6.22-gb0e2a705 attached -- Paolo Ornati Linux 2.6.23-rc3 on x86_64 config-usb.gz Description: GNU Zip compressed data
Re: [linux-usb-devel] spontaneous disconnect with "usb-storage: implement autosuspend"
On Tue, 14 Aug 2007 15:30:27 +0200 Oliver Neukum <[EMAIL PROTECTED]> wrote: > > my USB photo-camera gets automagically disconnected before I can do > > anything with it ;) > > > > hi, > > I need vendor:product. Please provide "lsusb". > Generally a bug report for a specific usb device without vendor:product > is a bad idea. oopss :) HP PHOTOSMART E317 tux ~ # lsusb Bus 007 Device 001: ID : Bus 006 Device 002: ID 03f0:4002 Hewlett-Packard PhotoSmart 720 / PhotoSmart 935 (storage) ... -- Paolo Ornati Linux 2.6.23-rc3 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] spontaneous disconnect with "usb-storage: implement autosuspend"
On Tue, 14 Aug 2007 17:46:16 +0200 Oliver Neukum <[EMAIL PROTECTED]> wrote: > Am Dienstag 14 August 2007 schrieb Paolo Ornati: > > Hewlett-Packard PhotoSmart 720 / PhotoSmart 935 (storage) > > Please try this patch. Tried on -rc3 but it doesn't work, dmesg attached. However I've found that if "hald" is running the problems doesn't happen (I think it's just hidden by the fact that hald do some polling on it preventing autosuspend to trigger). -- Paolo Ornati Linux 2.6.23-rc3 on x86_64 dmesg.gz Description: GNU Zip compressed data
Re: [linux-usb-devel] spontaneous disconnect with "usb-storage: implement autosuspend"
On Tue, 14 Aug 2007 20:33:22 +0200
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Exactly. This is not reliable. It needs to be done in kernel. This patch
> should do it.
ok, this one works :)
I suspect that there are many more broken devices out there ;)
thanks,
--
Paolo Ornati
Linux 2.6.23-rc3-gbfefa254 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 100% iowait on one of cpus in current -git
On Mon, 22 Oct 2007 08:22:52 +0200 Maxim Levitsky <[EMAIL PROTECTED]> wrote: > I tried to bisect this, but eventually I run into other bugs that cause > system to oops early. You can pick a different revision to test with: git-reset --hard "SHA1" Choose one with "git-bisect visualize". -- Paolo Ornati Linux 2.6.23-ge8b8c977 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kvm_main.c:220: error: implicit declaration of function 'smp_call_function_mask'
CC drivers/kvm/kvm_main.o drivers/kvm/kvm_main.c: In function 'kvm_flush_remote_tlbs': drivers/kvm/kvm_main.c:220: error: implicit declaration of function 'smp_call_function_mask' make[2]: *** [drivers/kvm/kvm_main.o] Error 1 make[1]: *** [drivers/kvm] Error 2 make: *** [drivers] Error 2 --- "smp_call_function_mask" is defined only on "CONFIG_SMP" but kvm uses it unconditionally, oops! -- Paolo Ornati Linux 2.6.23-ge8b8c977 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SATA exceptions triggered by XFS (since 2.6.18)
Sorry for starting a new thread, but I've deleted the messages from my mail-box, and I'm sot sure it's the same problem as here: http://lkml.org/lkml/2007/1/14/108 Today I've decided to try XFS... and just doing anything on it (extracting a tarball, for example) make my SATA HD go crazy ;) I don't remember to have seen this using Ext3. [ 877.839920] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen [ 877.839929] ata1.00: cmd 61/02:00:64:98:98/00:00:00:00:00/40 tag 0 cdb 0x0 data 1024 out [ 877.839931] res 40/00:00:00:4f:c2/00:00:00:4f:c2/00 Emask 0x4 (timeout) [ 878.142367] ata1: soft resetting port [ 878.351791] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 878.354384] ata1.00: configured for UDMA/133 [ 878.354392] ata1: EH complete [ 878.355696] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) [ 878.355716] sda: Write Protect is off [ 878.355718] sda: Mode Sense: 00 3a 00 00 [ 878.355745] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA It takes nothing to reproduce it. My hardware is: 00:00.0 Host bridge: Intel Corporation 82P965/G965 Memory Controller Hub (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82G965 Integrated Graphics Controller (rev 02) 00:03.0 Communication controller: Intel Corporation 82P965/G965 HECI Controller (rev 02) 00:19.0 Ethernet controller: Intel Corporation 82566DC Gigabit Network Connection (rev 02) 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #4 (rev 02) 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #5 (rev 02) 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #2 (rev 02) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 02) 00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #3 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #1 (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2) 00:1f.0 ISA bridge: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801HB (ICH8) 4 port SATA AHCI Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02) 02:00.0 IDE interface: Marvell Technology Group Ltd. Unknown device 6101 (rev b1) 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) with a Seagate Barracurda 7200rpm 80GB HD I've so far tested these kernels: 2.6.20-rc5 BAD 2.6.20-rc4 BAD 2.6.19 BAD 2.6.18 BAD 2.6.17 Good ! I'll start a git-bisection... -- Paolo Ornati Linux 2.6.20-rc5 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions triggered by XFS (since 2.6.18)
EX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 12 occurred at disk power-on lifetime: 2516 hours (104 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 0d 5b 9d 34 e1 Error: UNC 13 sectors at LBA = 0x01349d5b = 20225371 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- c8 00 00 4e 9d 34 e1 00 00:03:03.851 READ DMA c8 00 00 4e 9d 34 e1 00 00:03:03.848 READ DMA c8 00 00 4e 9d 34 e1 00 00:03:03.846 READ DMA c8 00 00 4e 9d 34 e1 00 00:03:03.843 READ DMA c8 00 00 4e 9d 34 e1 00 00:03:03.839 READ DMA Error 11 occurred at disk power-on lifetime: 2516 hours (104 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 0d 5b 9d 34 e1 Error: UNC 13 sectors at LBA = 0x01349d5b = 20225371 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- c8 00 00 4e 9d 34 e1 00 00:03:03.851 READ DMA c8 00 00 4e 9d 34 e1 00 00:03:03.848 READ DMA c8 00 00 4e 9d 34 e1 00 00:03:03.846 READ DMA c8 00 00 4e 9d 34 e1 00 00:03:03.843 READ DMA c8 00 00 4e 9d 34 e1 00 00:03:03.839 READ DMA Error 10 occurred at disk power-on lifetime: 2516 hours (104 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 0d 5b 9d 34 e1 Error: UNC 13 sectors at LBA = 0x01349d5b = 20225371 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- c8 00 00 4e 9d 34 e1 00 00:03:03.851 READ DMA c8 00 00 4e 9d 34 e1 00 00:03:03.848 READ DMA c8 00 00 4e 9d 34 e1 00 00:03:03.846 READ DMA c8 00 00 4e 9d 34 e1 00 00:03:03.843 READ DMA c8 00 00 16 9c 34 e1 00 00:03:03.839 READ DMA Error 9 occurred at disk power-on lifetime: 2516 hours (104 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 0d 5b 9d 34 e1 Error: UNC 13 sectors at LBA = 0x01349d5b = 20225371 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- c8 00 00 4e 9d 34 e1 00 00:03:03.851 READ DMA c8 00 00 4e 9d 34 e1 00 00:03:03.848 READ DMA c8 00 00 4e 9d 34 e1 00 00:03:03.846 READ DMA c8 00 00 16 9c 34 e1 00 00:03:03.843 READ DMA c8 00 00 0e 9b 34 e1 00 00:03:03.839 READ DMA Error 8 occurred at disk power-on lifetime: 2516 hours (104 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 0d 5b 9d 34 e1 Error: UNC 13 sectors at LBA = 0x01349d5b = 20225371 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- c8 00 00 4e 9d 34 e1 00 00:03:03.851 READ DMA c8 00 00 4e 9d 34 e1 00 00:03:03.848 READ DMA c8 00 00 16 9c 34 e1 00 00:03:03.846 READ DMA c8 00 00 0e 9b 34 e1 00 00:03:03.843 READ DMA c8 00 00 8e 99 34 e1 00 00:03:03.839 READ DMA SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 100 Not_testing 200 Not_testing 300 Not_testing 400 Not_testing 500 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. -- Paolo Ornati Linux 2.6.20-rc5 on x86_64 - To unsubscribe from this list:
Re: SATA exceptions triggered by XFS (since 2.6.18)
On Mon, 22 Jan 2007 01:53:21 +0059 Jiri Slaby <[EMAIL PROTECTED]> wrote: > >> 7 Seek_Error_Rate 0x000f 083 060 030Pre-fail Always > >> - 204305750 > >> 1 Raw_Read_Error_Rate 0x000f 059 049 006Pre-fail Always > >> - 215927244 > >> 195 Hardware_ECC_Recovered 0x001a 059 049 000Old_age Always > >> - 215927244 > > > > Wow! that HDD is really in a bad condition. > > I don't think so, this seems to be normal for Seagate drives... I agree. For Chr: I don't think these big raw-numbers are counters, look at the normalized values instead, and see that they are greater than TRESH values (so they are good). The meaning of raw-numbers is vendor specific. -- Paolo Ornati Linux 2.6.20-rc5 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions triggered by XFS (since 2.6.18)
On Mon, 22 Jan 2007 11:46:01 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > > I don't know. It's a two years old ST380817AS. > > > > # smartctl -a -d ata /dev/sda > > > > smartctl version 5.36 [x86_64-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen > > Home page is http://smartmontools.sourceforge.net/ > > > > === START OF INFORMATION SECTION === > > Model Family: Seagate Barracuda 7200.7 and 7200.7 Plus family > > Device Model: ST380817AS > > I'll blacklist it. Thanks. Ok. It will be better if someone else with the same HD could confirm. It looks so strange that an HD that works fine, and should support NCQ, have so big troubles that I can "freeze" it in less than a second by using XFS (while with ext3 I cannot, or at least it's very hard). -- Paolo Ornati Linux 2.6.20-rc5 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions triggered by XFS (since 2.6.18)
On Mon, 22 Jan 2007 18:35:05 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > Yeap, certainly. I'll ask people first before actually proceeding with > the blacklisting. I'm just getting a bit tired of tides of NCQ firmware > problems. > > Anyways, for the time being, you can easily turn off NCQ using sysfs. > Please take a look at http://linux-ata.org/faq.html ok -- Paolo Ornati Linux 2.6.20-rc5 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions triggered by XFS (since 2.6.18)
On Mon, 22 Jan 2007 18:35:05 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > Yeap, certainly. I'll ask people first before actually proceeding with > the blacklisting. I'm just getting a bit tired of tides of NCQ firmware > problems. Another interesting thing: it seems that I'm unable to reproduce the problem mounting XFS with "nobarrier" (using sda queue_depth = 31). So it looks like a problem with NCQ combined with cache flush command... -- Paolo Ornati Linux 2.6.20-rc5 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] select: fix sys_select to not leak ERESTARTNOHAND to userspace
On Tue, 16 Jan 2007 15:13:32 -0500
Neil Horman <[EMAIL PROTECTED]> wrote:
> As it is currently written, sys_select checks its return code to convert
> ERESTARTNOHAND to EINTR. However, the check is within an if (tvp) clause, and
> so if select is called from userspace with a NULL timeval, then it is possible
> for the ERESTARTNOHAND errno to leak into userspace, which is incorrect. This
> patch moves that check outside of the conditional, and prevents the errno
> leak.
the ERESTARTNOHAND thing is handled in arch specific signal code,
syscalls can return -ERESTARTNOHAND as much as they want (and your
change breaks the current behaviour of select()).
For example:
arch/x86_64/kernel/signal.c
/* Are we from a system call? */
if ((long)regs->orig_rax >= 0) {
/* If so, check system call restarting.. */
switch (regs->rax) {
case -ERESTART_RESTARTBLOCK:
case -ERESTARTNOHAND:
regs->rax = -EINTR;
break;
--
Paolo Ornati
Linux 2.6.20-rc5 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: newbie questions about while (1) in kernel mode and spinlocks
On Thu, 21 Dec 2006 10:41:44 +0100 "Sorin Manolache" <[EMAIL PROTECTED]> wrote: > The Linux Device Drivers book says that a spin_lock should not be > shared between a process and an interrupt handler. The explanation is > that the process may hold the lock, an interrupt occurs, the interrupt > handler spins on the lock held by the process and the system freezes. > Why should it freeze? Isn't it possible for the interrupt handler to > re-enable interrupts as its first thing, then to spin at the lock, the > timer interrupt to preempt the interrupt handler and to relinquish > control to the process which in turn will finish its critical section > and release the lock, making way for the interrupt handler to > continue. Iterrupt handlers are executend in the process context (on top of the process that they interrupted). So, if you have a proccess A that does: Usual Kernel Code Interrupt Handler ... spin_lock(my_lock); ... ---interrupt-> ... spin_lock(my_lock); // deadlock! ... <-- back - spin_unlock(my_lock); See? If the interrupt comes in when process A is running and holding the lock PREEMPTION can't do anything. -- Paolo Ornati Linux 2.6.20-rc1-g99f5e971 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: newbie questions about while (1) in kernel mode and spinlocks
On Thu, 21 Dec 2006 10:41:44 +0100
"Sorin Manolache" <[EMAIL PROTECTED]> wrote:
> spin_lock(&lck);
> down(&sem); /* I know that one shouldn't sleep when holding a lock */
> /* but I want to understand why */
I suppose because the lock is held for an indefinite amount of time and
any other process that try to get that lock will "spin" and burn CPU
without doing anything useful (locking the process in kernel mode and
preventing the execution of other processes on that CPU if there
isn't any type of PREEMPTION).
:)
spin_lock is a "while(1) {...}" thing...
--
Paolo Ornati
Linux 2.6.20-rc1-g99f5e971 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: newbie questions about while (1) in kernel mode and spinlocks
On Thu, 21 Dec 2006 10:41:44 +0100 "Sorin Manolache" <[EMAIL PROTECTED]> wrote: > while (1) > ; > > in the read function of a test device driver. I expect the calling > process to freeze, and then a timer interrupt to preempt the kernel > and to schedule another process. This does not happen, the whole > system freezes. I see no effect from pressing keys or moving the > mouse. Why? The hardware interrupts are not disabled, are they? Why do > the interrupt handlers not get executed? Here I'm not sure. I think that interrupts are enabled and processed correctly BUT the process cannot be Preempted because there is some lock held (every lock will increment the preemption count). The mouse doesn't move because X cannot be executed... A quick test you can do is to enable CONFIG_MAGIC_SYSRQ and try with "ALT + Stamp + B" when the system "freezes". If it reboots then interrupts work :) -- Paolo Ornati Linux 2.6.20-rc1-g99f5e971 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.20-rc3] PATA_MARVELL: total machine freeze
S 0 [cha: y, def: "..., 35) = 35 write(1, " APL 150 [cha: y, def:15"..., 35) = 35 ioctl(3, SG_IO, 0x52c010) = 0 ioctl(3, SG_IO, 0x52c010) = 0 ioctl(3, SG_IO, 0x52c010) = 0 ioctl(3, SG_IO, 0x52c010) = 0 ioctl(3, SG_IO, 0x52c010) = 0 ioctl(3, SG_IO, 0x52c010) = 0 ioctl(3, SG_IO, 0x52c010) = 0 ioctl(3, SG_IO, 0x52c010) = 0 write(1, "Protocol specific logical unit m"..., 42) = 42 write(1, " LUPID 0 [cha: n, def: "..., 35) = 35 ioctl(3, SG_IO, 0x52c010) = 0 ioctl(3, SG_IO, 0x52c010) = 0 ioctl(3, SG_IO, 0x52c010) = 0 ioctl(3, SG_IO, 0x52c010) = 0 ioctl(3, SG_IO, 0x52c010) = 0 ioctl(3, SG_IO, 0x52c010) = 0 write(1, "Power condition mode page:\n", 27) = 27 write(1, " IDLE1 [cha: n, def: "..., 35) = 35 write(1, " STANDBY 1 [cha: n, def: "..., 35) = 35 write(1, " ICT 1200 [cha: n, def:1"..., 37) = 37 write(1, " SCT 2400 [cha: n, def:2"..., 37) = 37 ioctl(3, SG_IO, 0x52c010) = 0 ioctl(3, SG_IO, 0x52c010) = 0 ioctl(3, SG_IO ^^^ I don't know why the output is truncated that way... anyway, as said before, the machine works for something like 30s after this (in the above example it survived >60s). dmesg / lspci / config attached Any idea? -- Paolo Ornati Linux 2.6.20-rc3 on x86_64 [0.00] Linux version 2.6.20-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo 4.1.1-r1)) #46 SMP Tue Jan 2 10:46:33 CET 2007 [0.00] Command line: root=/dev/sda6 video=intelfb:[EMAIL PROTECTED] [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0008f000 (usable) [0.00] BIOS-e820: 0008f000 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3e599000 (usable) [0.00] BIOS-e820: 3e599000 - 3e5a6000 (reserved) [0.00] BIOS-e820: 3e5a6000 - 3e655000 (usable) [0.00] BIOS-e820: 3e655000 - 3e6a6000 (ACPI NVS) [0.00] BIOS-e820: 3e6a6000 - 3e6ab000 (ACPI data) [0.00] BIOS-e820: 3e6ab000 - 3e6ac000 (usable) [0.00] BIOS-e820: 3e6ac000 - 3e6f2000 (ACPI NVS) [0.00] BIOS-e820: 3e6f2000 - 3e6ff000 (ACPI data) [0.00] BIOS-e820: 3e6ff000 - 3e70 (usable) [0.00] BIOS-e820: 3e70 - 3f00 (reserved) [0.00] BIOS-e820: fff0 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 143) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 255385) 1 entries of 256 used [0.00] Entering add_active_range(0, 255398, 255573) 2 entries of 256 used [0.00] Entering add_active_range(0, 255659, 255660) 3 entries of 256 used [0.00] Entering add_active_range(0, 255743, 255744) 4 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.4 present. [0.00] ACPI: RSDP (v000 INTEL ) @ 0x000fe020 [0.00] ACPI: RSDT (v001 INTEL DG965SS 0x0629 0x0113) @ 0x3e6fd038 [0.00] ACPI: FADT (v001 INTEL DG965SS 0x0629 MSFT 0x0113) @ 0x3e6fc000 [0.00] ACPI: MADT (v001 INTEL DG965SS 0x0629 MSFT 0x0113) @ 0x3e6f6000 [0.00] ACPI: WDDT (v001 INTEL DG965SS 0x0629 MSFT 0x0113) @ 0x3e6f5000 [0.00] ACPI: MCFG (v001 INTEL DG965SS 0x0629 MSFT 0x0113) @ 0x3e6f4000 [0.00] ACPI: ASF! (v032 INTEL DG965SS 0x0629 MSFT 0x0113) @ 0x3e6f3000 [0.00] ACPI: HPET (v001 INTEL DG965SS 0x0629 MSFT 0x0113) @ 0x3e6f2000 [0.00] ACPI: SSDT (v001 INTEL CpuPm 0x0629 MSFT 0x0113) @ 0x3e6aa000 [0.00] ACPI: SSDT (v001 INTEL Cpu0Ist 0x0629 MSFT 0x0113) @ 0x3e6a9000 [0.00] ACPI: SSDT (v001 INTEL Cpu1Ist 0x0629 MSFT 0x0113) @ 0x3e6a8000 [0.00] ACPI: SSDT (v001 INTEL Cpu2Ist 0x0629 MSFT 0x0113) @ 0x3e6a7000 [0.00] ACPI: SSDT (v001 INTEL Cpu3Ist 0x0629 MSFT 0x0113) @ 0x3e6a6000 [0.00] ACPI: DSDT (v001 INTEL DG965SS 0x0629 MSFT 0x0113) @ 0x [0.00] Entering add_active_range(0, 0, 143) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 255385) 1 entries of 256 used [0.00] Entering add_active_range(0, 255398, 255573) 2 entries of 256 used [0.00] Entering add_active_range(
Re: [PATCH] [TRIVIAL] Fixing occurrences of "the the "
On Thu, 22 Feb 2007 09:27:28 +0100 Michael Opdenacker <[EMAIL PROTECTED]> wrote: > - Note the the latest Xeons (Xeon 51xx and 53xx) are not based on the > + Note the latest Xeons (Xeon 51xx and 53xx) are not based on the shouldn't this be "Note that the"? (and so on) IOW: some of these are typos. Some time ago I've done a similar patch for "Documentation/" (remove duplicated words) and fallen in the same mistake :) -- Paolo Ornati Linux 2.6.20 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: sata timeouts with intel 82801HB on amd64
On Mon, 5 Feb 2007 21:08:33 -0500 (EST)
"Trevor Offner Caira" <[EMAIL PROTECTED]> wrote:
> (1) One-line summary: I'm getting SATA timeouts with Intel 82801HB on amd64.
>
> (2) Full description: Unless CONFIG_RCU_TORTURE_TEST is set, I get sata
> timeouts of this form periodically:
>
> ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen
> ata1.00: cmd 60/18:00:b3:22:0a/00:00:00:00:00/40 tag 0 cdb 0x0 data 12288 in
> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata1: soft resetting port
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: configured for UDMA/133
> ata1: EH complete
> SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
> sda: Write Protect is off
> SCSI device sda: write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA
>
> This entails complete blocking of all disk i/o (I only have one disk) for
> about 45 seconds. The kernel then negotiates the next lowest transfer
> speed (UDMA/166 all the way down to PIO0, when it errors saying it cannot
> go slower). I get this issue on amd64 kernels only. The issue is only
> present in 2.6.18+, since earlier kernels do not support my chipset at all
> (intel 82801HB).
>
> Knoppix 5.1.1 does not show this issue (i.e., no disk i/o issues even
> without rcutorture running). However, a native amd64 build of exactly the
> same kernel config shows the issue.
>
> (3) Keywords: SATA, AHCI, modules, kernel, Intel.
>
[CUT]
> (8.7) Other information: There's nothing in the system except for the
> DG965WH motherboard, E6600 processor, 1GB of kingston RAM, the ST3320620AS
> hard drive and 430 W PSU.
>
> Thanks for reading this far! :)
Are you using XFS, right?
Can you see if the problem goes away either:
1) disabling NCQ ("echo 1 > /sys/block/sda/device/queue_depth" in a
boot script)
OR
2) mounting XFS filesystem(s) with "nobarrier" option
?
I've seen this problem with very similar hardware (and so I've added
Tejun to CC :).
If mounting XFS with "nobarrier" fixes the problem it seems that more
than one Seagate disk cannot handle the Cache Flush command while other
commands are in fly...
--
Paolo Ornati
Linux 2.6.20 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: sata timeouts with intel 82801HB on amd64
On Wed, 7 Feb 2007 07:59:46 -0500 (EST)
"Trevor Offner Caira" <[EMAIL PROTECTED]> wrote:
> > 1) disabling NCQ ("echo 1 > /sys/block/sda/device/queue_depth" in a
> > boot script)
>
> No, this does not fix it.
>
> > OR
> >
> > 2) mounting XFS filesystem(s) with "nobarrier" option
>
> Neither does this.
ok, so it's a different problem (I've tried :)
--
Paolo Ornati
Linux 2.6.20 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: sata timeouts with intel 82801HB on amd64
On Wed, 07 Feb 2007 22:56:45 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote: > Paolo Ornati wrote: > > If mounting XFS with "nobarrier" fixes the problem it seems that more > > than one Seagate disk cannot handle the Cache Flush command while other > > commands are in fly... > > It's not allowed to overlap NCQ (FPDMA read/write) commands with any > other commands such as cache flushes. libata core guarantees that this > doesn't happen by deferring such requests until the FPDMA commands are > complete. (At least, it's supposed to..) I didn't know that. Anyway just mounting XFS with "nobarrier" fixes the ploblem for me... so libata is buggy or I don't know! -- Paolo Ornati Linux 2.6.20 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Slower CPU frequency reported by the kernel
On Fri, 2 Feb 2007 12:11:25 +0100 "Francis Moreau" <[EMAIL PROTECTED]> wrote: > Hi, > > I'm using a PC with AMD 64 3000+ cpu which is theoricaly running at > 2Ghz. But when looking at /proc/cpuinfo, the kernel reports that it > runs only at 1Ghz: > > # cat /proc/cpuinfo > > processor : 0 > vendor_id : AuthenticAMD > cpu family : 15 > model : 12 > model name : AMD Athlon(tm) 64 Processor 3000+ > stepping: 0 > cpu MHz : 1000.000 > cache size : 512 KB > fdiv_bug: no > hlt_bug : no > f00f_bug: no > coma_bug: no > fpu : yes > fpu_exception : yes > cpuid level : 1 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm > 3dnowext 3dnow ts fid vid ttp > bogomips: 2004.89 > > I tried with a 2.6.20-rc7 kernel and still have the same. > > What's going wrong ? You are using frequency scaling(*) and "/proc/cpuinfo" reflects the current speed. (*) = # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_DEBUG=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m Read "Documentation/cpu-freq/user-guide.txt" for more info. -- Paolo Ornati Linux 2.6.20-rc7 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Slower CPU frequency reported by the kernel
On Fri, 2 Feb 2007 15:03:31 +0100 "Francis Moreau" <[EMAIL PROTECTED]> wrote: > it's seems that the cpu freq scaling depends on a user space tool. Yes, it depends on the selected governor. In the case of "userspace" governor you (or a program) can set the speed writing to "/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed". Usually a deamon monitor the CPU usage and increase the frequency when you need it. > Could you tell me how I can find if there're such tools installed on > my computer ? "ps -A" and look for something like "cpufreqd" There are different deamon for this: cpufreqd, cpudyn... Anyway it is started by an init script, so you should find it looking at "ls /etc/init.d/". -- Paolo Ornati Linux 2.6.20-rc7 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Thu, 14 Dec 2006 12:08:11 -0800 "David Schwartz" <[EMAIL PROTECTED]> wrote: > > That is something that I think is well worth fixing. Doesn't Linus own the > trademark 'Linux'? How about some rules for use of that trademark and a > 'Works with Linux' logo that can only be used if the hardware specifications > are provided? > > Let them provide a closed-source driver if they want. Let them provide > user-space applications for which no source is provided if they want. But > don't let them use the logo unless they release sufficient information to > allow people to develop their own drivers and applications to interface with > the hardware. This is the same I think, but not Linux specific: http://wiki.duskglow.com/tiki-index.php?page=Open+Hardware+Foundation -- P. Mc Namara 12 Jul 06: about the OHF foundation providing "certificates" for hardware, I'd propose (...) levels. * First, any company that pledges full and complete interface and behavioral documentation for a device, any docs necessary to make the device do everything it is designed to do, and makes it publicly available under nothing more cumbersome than the basic copyright that exists on all written works receives one certificate. Somebody else used "community friendly" or something similar. I don't know what to call it. Perhaps just "Open Documentation" (...) * A company that contributes back to the community during the development of a device get labeled "Community Supporter" or something similar. * A company that enters into a legal agreement to release the entire RTL and supporting information for a project at a given point in the future (far enough ahead to protect the companies commercial viability) can get the "Open Hardware" certificate. -- -- Paolo Ornati Linux 2.6.18 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
s2disk curiosity :)
Hello,
I'm using uswsusp and with commit
3592695c363c3f3119621bdcf5ed852d6b9d1a5c
uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode")
My PC power-light starts flashing during s2disk as expected (comment
from the commit that fixes the same thing in in-kernel suspend):
"[PATCH] swsusp: fix platform mode
At some point after 2.6.13, in-kernel software suspend got "incomplete" for
the so-called "platform" mode. pm_ops->prepare() is never called. A
visible sign of this is the "moon" light on thinkpads not flashing during
suspend. Fix by readding the pm_ops->prepare call during suspend."
BUT: another thing that happens is that now my PC powers itself on
_without_ pressing the power button (just by plugging the AC power).
I don't like this all that much...
I understand this is probably MOBO specific but, is this behaviour
expected/common?
--
Paolo Ornati
Linux 2.6.20-rc1-g99f5e971 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: s2disk curiosity :)
On Mon, 18 Dec 2006 10:36:24 +0100
Stefan Seyfried <[EMAIL PROTECTED]> wrote:
> It depends on the BIOS. Many BIOSes have a setting where you can set the
> "power fail mode" to "on", "off" or "as before".
Ok, I've found the BIOS setting: Restore on AC Poer Loss = {Power Off,
Power On, Last State}.
Anyway I found strange that the "state" after s2disk is considered
"ON" ;)
--
Paolo Ornati
Linux 2.6.20-rc1-g99f5e971 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Jumping into Kernel development: About -rc kernels...
On Wed, 10 Jan 2007 19:07:32 +0100 Stefan Richter <[EMAIL PROTECTED]> wrote: > On 1/10/2007 4:00 PM, Lei W wrote: > > If now i have applied patch-2.6.19.1,how can i goto > > 2.6.20-rc4 ? > > $ cd linux/ > $ patch -p1 -R < patch-2.6.19.1 > $ patch -p1 < patch-2.6.20-rc4 for Lei W: cd linux/ ketchup 2.6.20-rc4 http://www.selenic.com/ketchup/wiki/ :) -- Paolo Ornati Linux 2.6.20-rc4-gf3a2c3ee on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.18.2 kernel BUG at mm/vmscan.c:606!
On Thu, 16 Nov 2006 02:43:30 +0100 Paul Seelig <[EMAIL PROTECTED]> wrote: > Today i fetched the newest suspend2 patches and rebooted the machine with a > 2.6.18.2 kernel containing them. Now let's see if the problem i reported > persists. If yes, i'll report them to Nigel Cunningham instead. You can also do suspend without external patches... for example with http://suspend.sourceforge.net/ it's also packaged by Debian: http://packages.debian.org/testing/admin/uswsusp :) -- Paolo Ornati Linux 2.6.19-rc4-g2de6c39f on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping functions called in invalid context during resume
On Fri, 17 Nov 2006 08:30:08 -0800
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > > > APIC error on CPU0: 00(00)
> > > >
> > > > Is it an ACPI problem?
> > >
> > > a 00 error code? Never seen that ... How frequently does it happen?
> >
> > On my x86-64 boxes the "APIC error on CPU0" message appears on every resume,
> > but it doesn't seem to be related to any visible problems.
> >
> > It's been there forever, AFAICT.
>
> Yes, it is there on every resume.
Here too... so it's common on x86_64 ;)
$ dmesg | grep Suspending | wc -l
9
$ dmesg | grep "APIC err" | wc -l
9
--
Paolo Ornati
Linux 2.6.19-rc4-g2de6c39f on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping functions called in invalid context during resume
On Sat, 18 Nov 2006 13:55:04 +0100 Karsten Wiese <[EMAIL PROTECTED]> wrote: > > Could you try the following, as of yet untested patch? > It's i386 twin makes an APIC error vanish here on a K8. > > Karsten > --- > From 54248a43231de8d6d64354b51646c54121e3f395 Mon Sep 17 00:00:00 2001 > From: Karsten Wiese <[EMAIL PROTECTED]> > Date: Sat, 18 Nov 2006 13:44:14 +0100 > Subject: [PATCH 1/1] x86_64: Regard MSRs in lapic_suspend()/lapic_resume() It works! :) -- Paolo Ornati Linux 2.6.19-rc6-ge030f829-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[SOLVED] Re: [discuss] 2.6.19-rc5: known regressions (v2)
On Tue, 14 Nov 2006 17:44:51 +0100 Paolo Ornati <[EMAIL PROTECTED]> wrote: > > > Okay, please let us know if it survives the next several cycles. > > > > > > OTOH, the problem may be hiding. > > > > Ok, and if it survives againg and again I can do a partial bisection... > > "-rc5" is still alive: 6 days of uptime using suspend/resume many times > every day... > > so if the problem is there it's hiding very well. > > > Now I'll slowly go back with older kernels and see what happens... SHORT CONCLUSION: it was just a kernel miscompilation (I usually do "make oldconfig; make clean; make" so I don't know if I missed "make clean" or if it was caused by ccache...). The fact that it's a miscompilation is "proved" by 3 simple things: 1) I've only seen the problem with that particular version 2) slow bisection pointed that the ipotetic bug was fixed between 4b1c46a3..d1ed6a3e, but I don't see any change that matters (on x86_64). 3) I'm running a clean recompiled 2.6.19-rc4-g4b1c46a3, that doesn't have any problem. :D -- Paolo Ornati Linux 2.6.19-rc4-g4b1c46a3 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about fair schedulers
On Sat, 23 Jun 2007 00:07:15 +0200 Alberto Gonzalez <[EMAIL PROTECTED]> wrote: > My conclusion is that SD behaves as expected: it's more fair. But for a > desktop, shouldn't an "intelligently unfair" scheduler be better? "intelligently unfair" is what the current scheduler is (because of interactivity estimator). When it works (say 90% of the time) the desktop feels really good... but when it doesn't it can be a disaster. Look this for example: http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/6aa5c93c379ae9e1/98ab31c0e6fed2ee?&hl=en#98ab31c0e6fed2ee -- Paolo Ornati Linux 2.6.22-rc5-g0864a4e2 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about fair schedulers
On Sat, 23 Jun 2007 10:01:02 +0200 Alberto Gonzalez <[EMAIL PROTECTED]> wrote: > I see. So you mean that in 90% of the cases the mainline scheduler behaves > better than fair schedulers, but when its "logic" fails it behaves much worse > (the other 10% cases)? Yes and no... the "logic" is supposed to identify what processes are somehow interactive and give them more priority / CPU time. This makes the system behaves better when there are CPU hog processes (like encoders etc...) because the interactive ones doesn't suffer too much. The big problem is that it can identify an almost CPU hog process as interactive and giving him an insane amount of CPU starve the others. In my case it was "trancode", and I assure you... it wasn't funny. Sometimes it happened that running it (at standard nice 0) made the machine totally unusable! (something like 30s to switch from X to a virtual terminal... and I don't tell you how hard was doing login and killing/renicing it). So far I've seen these pathological behaviour only with trancode and wine (only with particular programs I don't remember now). But the fact is, the "interactivity estimator" is too fragile, and when it fails it can do much damage. Fair scheduler instead: - are robust - provide consistent behaviour - provide good interactivity within the bounds of fairness > In my very simple test scenario the mainline scheduler > did behave much better. Of course... because of the two competing processes the "interactive" (for you) one needs 60%, that is more than it's 50% fair share. The real solution is to use nice levels so the scheduler doesn't have to guess what process is more important. And yes, programs/distributions should set good defaults for you... and if they don't, just complain to them :) -- Paolo Ornati Linux 2.6.22-rc5-g0864a4e2 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about fair schedulers
On Sat, 23 Jun 2007 15:56:36 +0200 Alberto Gonzalez <[EMAIL PROTECTED]> wrote: > > And yes, programs/distributions should set good defaults for you... and > > if they don't, just complain to them :) > > I'm sure they'll do once a fair scheduler goes into mainline :) Some already does... for example the current version of: http://www.exit1.org/dvdrip/ it sets transcode nice to "+19" by default :) > > I guess what I was missing from the beginning is that "fair" means that the > scheduler will be fair among tasks that have the same priority, but if a task > has a higher priority, it _will_ get more CPU. So we'll just have to mark > applications like video players, audio players or games with a high priority, > others like encoders or compilers with low priority, and leave the rest > (browsers, word processors, email readers, etc...) as normal priority. This > way a fair scheduler would be able to give each task right amount of CPU. Yes. I think that the more important thing is to nice background tasks (like encoders etc..), then games / video players can run without problems even without renicing (usually normal programs don't eat much CPU). -- Paolo Ornati Linux 2.6.22-rc5-g0864a4e2 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)
On Thu, 14 Jun 2007 13:37:32 +0200 Matthew <[EMAIL PROTECTED]> wrote: > now back to topic: > > /dev/loop* seems to be broken since (at least) 2.6.22-rc3, since that > was the first kernel I tried of the 2.6.22-rc* series > > ls -l /dev/ | grep loop > > shows no output Yes, now the "loop" devices are dynamically allocated a patch to provide the 8 "static allocated" loop devices is already in current git (post -rc4, will be in -rc5). commit a47653fc2643cf61bcabba8c9ff5c45517c089ba Author: Ken Chen <[EMAIL PROTECTED]> Date: Fri Jun 8 13:46:44 2007 -0700 loop: preallocate eight loop devices The kernel on-demand loop device instantiation breaks several user space tools as the tools are not ready to cope with the "on-demand feature". Fix it by instantiate default 8 loop devices and also reinstate max_loop module parameter. -- Paolo Ornati Linux 2.6.22-rc4-cfs-v16-g47932c49 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)
On Thu, 14 Jun 2007 16:10:44 +0200 Matthew <[EMAIL PROTECTED]> wrote: > I just tried out > > modprobe loop max_loop=32 > > output of dmesg is: > > [ 457.607575] loop: the max_loop option is obsolete and will be > removed in March 2008 > [ 457.607578] loop: module loaded > > but there are NO loop devices in /dev: > > ls -l /dev/ | grep loop > still shows nothing, strange ... it's not strange, with your kernel version "max_loop" will just limit the max number of loop devices at most. This is what happens with the mentioned patch (-rc5 and later): + /* +* loop module now has a feature to instantiate underlying device +* structure on-demand, provided that there is an access dev node. +* However, this will not work well with user space tool that doesn't +* know about such "feature". In order to not break any existing +* tool, we do the following: +* +* (1) if max_loop is specified, create that many upfront, and this +* also becomes a hard limit. +* (2) if max_loop is not specified, create 8 loop device on module +* load, user can further extend loop device by create dev node +* themselves and have kernel automatically instantiate actual +* device on-demand. +*/ So with this patch "max_loop=32" will create 32 loop devices... but then it doesn't allow more of them. Without options it creates 8 and you (or some userspace tool) can add more dynamically. -- Paolo Ornati Linux 2.6.22-rc4-cfs-v16-g47932c49 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/loop* devices not appearing in /dev (at least since 2.6.22-rc3*)
On Fri, 15 Jun 2007 12:19:35 +0100 "Simon Arlott" <[EMAIL PROTECTED]> wrote: > > It *is* a good idea. MD works that way too. > > There's a patch around somewhere to create at least 8 devices, I don't know > why it's not in Linus' tree yet... It is! It's just that it was applied after -rc4... commit a47653fc2643cf61bcabba8c9ff5c45517c089ba Author: Ken Chen <[EMAIL PROTECTED]> Date: Fri Jun 8 13:46:44 2007 -0700 loop: preallocate eight loop devices [...] -- Paolo Ornati Linux 2.6.22-rc4-cfs-v16-g47932c49 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.1 - 97% wait time on IDE operations
On Sat, 26 May 2007 15:05:38 +0200 Tommy Vercetti <[EMAIL PROTECTED]> wrote: > I was trying to get answer to my question around, but no one knows. > I do have DMA turned on, etc, yet - on extensive harddrive operations wait > time is 90+% , which means that machine is waiting, rather than doing > something meanwhile. (I guess). > Can someone describe to me , in more detail why is that happening, and what > steps should I consider to avoid it ? I couldn't find any answers that would > have help me on net. It means that the disk is slow and the CPU is fast... so while the disk is busy seeking and reading data the CPU has nothing to do but wait for it. Idle == CPU has nothing to do Waiting == CPU has nothing to do, but it will have as soon as the slow disk (or whatever) delivers data Anyway 97% is quite high... what CPU / Hard Disk do you have? What kernel version? I/O scheduler? (cat /sys/block/DEVICE/queue/scheduler) Filesystem? And what time of "operations" are you doing? -- Paolo Ornati Linux 2.6.22-rc3-cfs-v14-gf193016a on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.1 - 97% wait time on IDE operations
On Sat, 26 May 2007 16:07:49 +0200 Tommy Vercetti <[EMAIL PROTECTED]> wrote: > > Anyway 97% is quite high... what CPU / Hard Disk do you have? > Intel(R) Pentium(R) M processor 1400MHz > TOSHIBA MK8025GAS > > > What kernel version? > 2.6.21.1 > > I/O scheduler? (cat /sys/block/DEVICE/queue/scheduler) > [EMAIL PROTECTED]:~$ cat /sys/block/hda/queue/scheduler > noop anticipatory deadline [cfq] > > > Filesystem? > reiser3 > > And what time of "operations" are you doing? > apt-get install, vmware It's probably just a slow disk... try hdparm as suggested by Ray and see if they look sane (PS: just seen the numbers and looks sane to me). If they are and you need more performance buy a better HD :) Improvements from kernel side are possible but don't expect too much. Things to check/try: 1) FS: is it in good shape? Or is it full and fragmented? 2) FS mount options, try adding everything that can reduce accesses (noatime, nodiratime) 3) try experimental patches such as Adaptive Readahead, it seems to help some workload (it was there in older -mm, now there's a much simplier readahead replacement in 2.6.22-rc2-mm1 called "on-demand readahead", maybe that helps too?) -- Paolo Ornati Linux 2.6.22-rc3-cfs-v14-gf193016a on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Contributor Agreement/Copyright Assignment
On Wed, 16 May 2007 10:59:49 -0400 "Bhutani Meeta-W19091" <[EMAIL PROTECTED]> wrote: > > Motorola would like to understand if kernel.org has a contributor > agreement (or a copyright assignment agreement) that is posted somewhere > ? We are investigating what would be needed from a legal standpoint to > possibly contribute in the future. maybe this helps: http://groups.google.com/group/linux.kernel/browse_thread/thread/21d472915541ac48/5a2d152a1d1b62b6?lnk=st&q=&rnum=3&hl=en#5a2d152a1d1b62b6 :) -- Paolo Ornati Linux 2.6.21.1-cfs-v12-gd805260d on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/69] -stable review
On Wed, 23 May 2007 09:09:00 +0200
Romano Giannetti <[EMAIL PROTECTED]> wrote:
> Will try to reboot with clocksource=acpi_pm, althoughI think that this
> is the one I'm using.
you can see that with:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
--
Paolo Ornati
Linux 2.6.22-rc2-gd2579053 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.1 fails to suspend/resume to disk (sort of)
On Thu, 24 May 2007 10:01:21 +0200 "Antonino Ingargiola" <[EMAIL PROTECTED]> wrote: > Is not the ubuntu or debian way to take hours to compile. Is that you > have to trim the config and enable the only modules you need for your > hardware, then a rebuild cycle could last 10-15 min. Even 3-5 min if you strip it down a lot and with good hardware :) Also ccache helps. -- Paolo Ornati Linux 2.6.22-rc2-gd2579053 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 select "Video mode selection support" and "VGA 8x16 font"
On Sun, 15 Apr 2007 13:08:54 +0200 "Luca Lucchesi" <[EMAIL PROTECTED]> wrote: > but I can't select them because they are unselectable (they appear with > "---" in the left). > I checked their requirements but all requirements seem to be active. > > Why I can't active them? > Somebody could help me, please? "---" means that they _ARE_ active and you cannot deselect them (because they are selected by something else) try this: $ grep VIDEO_SEL .config CONFIG_VIDEO_SELECT=y So you have nothing to do :) -- Paolo Ornati Linux 2.6.20.7 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] CFS (Completely Fair Scheduler), v2
On Tue, 17 Apr 2007 01:51:08 -0400 Gene Heskett <[EMAIL PROTECTED]> wrote: > FWIW, I've been using the CFQ I/O scheduler for quite a while, is it time I > gave the AS or Deadline versions another check? They are all built in but I > don't know how to change the default on the fly, or even if it can be done. easy :) # cat /sys/block/DEVICE/queue/scheduler as noop [cfq] ... # echo IO_SCHED > /sys/block/DEVICE/queue/scheduler -- Paolo Ornati Linux 2.6.21-rc7 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to tell linux (on x86) to ignore 1M or memory
On Thu, 19 Apr 2007 10:18:04 -0400
Bart Trojanowski <[EMAIL PROTECTED]> wrote:
> I need to preserve some state from the bios before entering protected
> mode. For now I want to copy it into some ram accessible by real-mode,
> say the last megabyte visible in real-mode.
>
> What's the easiest way to have linux ignore the megabyte starting at 15M?
>
Documentation/kernel-parameters.txt:
memmap=nn[KMG]$ss[KMG]
[KNL,ACPI] Mark specific memory as reserved.
Region of memory to be used, from ss to ss+nn.
So adding this to kernel boot parameters should do the trick:
memmap=15M$1M
--
Paolo Ornati
Linux 2.6.21-rc7-CFS-v3-g6262cd9f on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: error in compilation kernel 2.6.19 - internal compiler error
On Sat, 24 Mar 2007 16:45:46 +0100 Thibaud Hulin <[EMAIL PROTECTED]> wrote: > I'm triyng to compile the kernel 2.6.19 on Debian Testing 4.0 > Unfortunately, I can't success. > This is my error message : > > CC [M] drivers/scsi/lpfc/lpfc_sli.o > In file included from drivers/scsi/lpfc/lpfc_sli.c:23: > include/linux/pci.h:251: internal compiler error: in build_int_cst_wide, > at tree.c:803 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > For Debian GNU/Linux specific bug reporting instructions, > see . > The bug is not reproducible, so it is likely a hardware or OS problem. Have you read the error message? It could be a memory problem (defective module)... try run memtest86 or memtest86+ (http://www.memtest.org/) for many hours (>= 8, someone suggest even 24h, just to be sure :). If the problem is big memtest should find it soon. -- Paolo Ornati Linux 2.6.20.4 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alternative to 'git bisect visualize'?
On Mon, 9 Apr 2007 17:10:23 -0400 "Stuart MacDonald" <[EMAIL PROTECTED]> wrote: > My problem is that I don't have wish/tk installed. Is there a > text-based alternative to visualize that I can use? Or is there a > different method to locate a nearby commit? > > The answer may involve something as simple as looking at some git > state; I am a git newbie, and reading the docs hasn't helped any, so I > won't be surprised to find out I'm overlooking something really > obvious. I think this should work: 1) look at "git-bisect log" and take the last good/bad pair 2) "cat .git/refs/heads/bisect" to see where you are now 3) git-log --pretty=oneline GOOD..BAD 4) search for the current commit (found in #2) with "/CURRENT_COMMIT", now move around and choose another commit to test 5) git-reset --hard COMMIT_TO_TEST Example: $ git-bisect start $ git-bisect good v2.6.17 $ git-bisect bad v2.6.18 Bisecting: 3400 revisions left to test after this [2a2ed2db353d949c06b6ef8b6913f65b39111eab] Merge git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild # 2a2ed2db353d949c06b6ef8b6913f65b39111eab doesn't compile/boot ? $ git-bisect log git-bisect start # good: [8ba130df4b67fa40878ccf80d54615132d24bc68] Linux v2.6.17 git-bisect good 8ba130df4b67fa40878ccf80d54615132d24bc68 # bad: [119248f4578ca60b09c20893724e10f19806e6f1] Linux v2.6.18. Arrr! $ git-log --pretty=oneline 8ba130df4b67fa40878ccf80d54615132d24bc68..119248f4578ca60b09c20893724e10f19806e6f1 search for "2a2ed2db353d949c06b6ef8b6913f65b39111eab": aa4148cfc7b3b93eeaf755a7d14f10afaffe9a96 [PATCH] devfs: Remove devfs support from the serial subsystem bdaf8529385d5126ef791e8f1914afff8cd59bcf [PATCH] devfs: Remove devfs from the init code a29641883f57f36424e3219ae9ff48dd6cd34de0 [PATCH] devfs: Remove devfs from the partition code 5c3927dc3468f47b803c9e1bb82cbed2bbd411ab [PATCH] devfs: Remove devfs documentation from the kernel tree d8deac5094988c7ad1127ee61f52c59a952fcabb [PATCH] devfs: Remove devfs from the kernel tree 5fd571cbc13db113bda26c20673e1ec54bfd26b4 [PATCH] Array overrun in drivers/infiniband/core/cma.c 09c0dc68625c06f5b1e786aad0d5369b592179e6 Revert "[PATCH] kthread: update loop.c to use kthread" 6e58f5c9a841e59233c5997df082e93329ea61e0 [ARM] 3656/1: S3C2412: Add S3C2412 and S3C2413 documenation >>> 2a2ed2db353d949c06b6ef8b6913f65b39111eab Merge >>> git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild 972d19e837833b93466c6f6a8ef2a7d653000aa3 Merge master.kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6 cdf4f383a4b0ffbf458f65380ecffbeee1f79841 Merge master.kernel.org:/pub/scm/linux/kernel/git/dtor/input 954b36d48b495afed2880320750858a2eae312c9 [PATCH] m68knommu: use configurable RAM setup page_offset.h 12ddae3348def8808fb755b23225b18fc4adfbe3 [PATCH] m68knommu: use configurable RAM setup in start up code 73e2fba8dc1e0a686073a5183be1a99e9285d2ac [PATCH] m68knommu: use configurable RAM setup in linker script 63e413d19db0018e443a43c6c7a482993edf79cf [PATCH] m68knommu: create configurable RAM setup d2f386d7c182c1420f797093d67bb09a7251f113 [PATCH] m68knommu: remove unused vars from generic 68328 start code 2ae9cb6bd4c23616b229b135ea57a93a6a24e13a [PATCH] m68knommu: remove __ramvec from 68328/pilot start code # pick another one... $ git-reset --hard aa4148cfc7b3b93eeaf755a7d14f10afaffe9a96 -- Paolo Ornati Linux 2.6.21-rc6-gc2481cc4 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[XFS] INFO: possible circular locking dependency detected
I've not seen this reported...
[ 9564.772749]
[ 9564.772752] ===
[ 9564.772757] [ INFO: possible circular locking dependency detected ]
[ 9564.772760] 2.6.21-rc6-gc2481cc4 #9
[ 9564.772762] ---
[ 9564.772765] xfssyncd/6157 is trying to acquire lock:
[ 9564.772767] (&(&ip->i_lock)->mr_lock){}, at: []
xfs_ilock_nowait+0x6d/0xc8
[ 9564.772775]
[ 9564.772776] but task is already holding lock:
[ 9564.772778] (&mp->m_ilock){--..}, at: []
xfs_finish_reclaim_all+0x1d/0xc1
[ 9564.772785]
[ 9564.772786] which lock already depends on the new lock.
[ 9564.772787]
[ 9564.772789]
[ 9564.772790] the existing dependency chain (in reverse order) is:
[ 9564.772792]
[ 9564.772793] -> #1 (&mp->m_ilock){--..}:
[ 9564.772796][] __lock_acquire+0xa3d/0xbe4
[ 9564.772804][] xfs_iget_core+0x60e/0x6c4
[ 9564.772811][] lock_acquire+0x7b/0x9f
[ 9564.772817][] xfs_iget_core+0x60e/0x6c4
[ 9564.772824][] __mutex_lock_slowpath+0xe1/0x263
[ 9564.772832][] xfs_iget_core+0x60e/0x6c4
[ 9564.772839][] xfs_iget+0xa4/0x14b
[ 9564.772845][] xfs_mountfs+0x708/0x954
[ 9564.772852][] xfs_setsize_buftarg_flags+0x30/0x9e
[ 9564.772859][] xfs_mount+0x317/0x39d
[ 9564.772866][] xfs_fs_fill_super+0x0/0x1a1
[ 9564.772873][] xfs_fs_fill_super+0x7e/0x1a1
[ 9564.772880][] _spin_unlock+0x17/0x20
[ 9564.772887][] sget+0x377/0x389
[ 9564.772894][] set_bdev_super+0x0/0xf
[ 9564.772900][] test_bdev_super+0x0/0xd
[ 9564.772907][] get_sb_bdev+0x121/0x17b
[ 9564.772913][] vfs_kern_mount+0x4f/0x8a
[ 9564.772920][] do_kern_mount+0x36/0x4d
[ 9564.772926][] do_mount+0x625/0x699
[ 9564.772934][] mntput_no_expire+0x1c/0x85
[ 9564.772941][] link_path_walk+0xce/0xe0
[ 9564.772948][] sigprocmask+0x28/0xc1
[ 9564.772956][] kmem_cache_free+0xcf/0xd9
[ 9564.772963][] trace_hardirqs_on+0x124/0x14f
[ 9564.772970][] get_page_from_freelist+0x1ef/0x35d
[ 9564.772977][] trace_hardirqs_on+0x124/0x14f
[ 9564.772984][] __alloc_pages+0x6d/0x2b4
[ 9564.772990][] sys_mount+0x8a/0xd7
[ 9564.772997][] system_call+0x7e/0x83
[ 9564.773004][] 0x
[ 9564.773014]
[ 9564.773015] -> #0 (&(&ip->i_lock)->mr_lock){}:
[ 9564.773018][] print_circular_bug_header+0xcc/0xd3
[ 9564.773025][] __lock_acquire+0x939/0xbe4
[ 9564.773032][] xfs_ilock_nowait+0x6d/0xc8
[ 9564.773039][] lock_acquire+0x7b/0x9f
[ 9564.773045][] xfs_ilock_nowait+0x6d/0xc8
[ 9564.773052][] down_write_trylock+0x2f/0x35
[ 9564.773059][] xfs_ilock_nowait+0x6d/0xc8
[ 9564.773066][] xfs_finish_reclaim_all+0x40/0xc1
[ 9564.773073][] xfs_syncsub+0x4e/0x237
[ 9564.773080][] keventd_create_kthread+0x0/0x6d
[ 9564.773087][] vfs_sync_worker+0x19/0x38
[ 9564.773094][] xfssyncd+0x10c/0x15d
[ 9564.773101][] xfssyncd+0x0/0x15d
[ 9564.773107][] kthread+0xd1/0x103
[ 9564.773114][] child_rip+0xa/0x12
[ 9564.773121][] _spin_unlock_irq+0x24/0x27
[ 9564.773127][] restore_args+0x0/0x30
[ 9564.773134][] kthread+0x0/0x103
[ 9564.773140][] child_rip+0x0/0x12
[ 9564.773147][] 0x
[ 9564.773153]
[ 9564.773154] other info that might help us debug this:
[ 9564.773155]
[ 9564.773158] 1 lock held by xfssyncd/6157:
[ 9564.773159] #0: (&mp->m_ilock){--..}, at: []
xfs_finish_reclaim_all+0x1d/0xc1
[ 9564.773166]
[ 9564.773167] stack backtrace:
[ 9564.773169]
[ 9564.773169] Call Trace:
[ 9564.773173] [] print_circular_bug_tail+0x69/0x72
[ 9564.773177] [] print_circular_bug_header+0xcc/0xd3
[ 9564.773180] [] __lock_acquire+0x939/0xbe4
[ 9564.773183] [] xfs_ilock_nowait+0x6d/0xc8
[ 9564.773187] [] lock_acquire+0x7b/0x9f
[ 9564.773190] [] xfs_ilock_nowait+0x6d/0xc8
[ 9564.773194] [] down_write_trylock+0x2f/0x35
[ 9564.773197] [] xfs_ilock_nowait+0x6d/0xc8
[ 9564.773200] [] xfs_finish_reclaim_all+0x40/0xc1
[ 9564.773204] [] xfs_syncsub+0x4e/0x237
[ 9564.773207] [] keventd_create_kthread+0x0/0x6d
[ 9564.773211] [] vfs_sync_worker+0x19/0x38
[ 9564.773214] [] xfssyncd+0x10c/0x15d
[ 9564.773217] [] xfssyncd+0x0/0x15d
[ 9564.773220] [] kthread+0xd1/0x103
[ 9564.773224] [] child_rip+0xa/0x12
[ 9564.773227] [] _spin_unlock_irq+0x24/0x27
[ 9564.773230] [] restore_args+0x0/0x30
[ 9564.773233] [] kthread+0x0/0x103
[ 9564.773236] [] child_rip+0x0/0x12
[ 9564.773238]
--
Paolo Ornati
Linux 2.6.21-rc6-gc2481cc4 on x86_64
config.gz
Description: GNU Zip compressed data
Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
On Sat, 28 Apr 2007 09:30:06 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > There are worse examples. Try connecting some flash disk over USB-1, and > untar to it. Ugh. > > I'd love to have some per-device dirty limit, but it's harder than it > should be. this one should help: Patch: per device dirty throttling http://lwn.net/Articles/226709/ -- Paolo Ornati Linux 2.6.21-cfs-v7-g13fe02de on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Corrupt XFS -Filesystems on new Hardware and Kernel
On Wed, 28 Mar 2007 09:46:40 +0200 Oliver Joa <[EMAIL PROTECTED]> wrote: > What can be wrong? There is nothing special, only board, cpu and > harddisk, no other hardware. The board is running with the newest > available bios. I bought a Intel-board, because normally Intel is > supported very well. What Seagate is it? (hdparm -I /dev/sda | head) I have this one: ATA device, with non-removable media Model Number: ST380817AS Serial Number: 4MR08EK8 Firmware Revision: 3.42 and it gives problems with NCQ enabled. Try turning NCQ off with: echo 1 > /sys/block/sda/device/queue_depth -- Paolo Ornati Linux 2.6.20.4 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Corrupt XFS -Filesystems on new Hardware and Kernel
On Wed, 28 Mar 2007 12:59:10 +0200
Oliver Joa <[EMAIL PROTECTED]> wrote:
> i did this already (in the first startup-script). It does not help.
>
> Another Idea?
try replacing the SATA cable...
--
Paolo Ornati
Linux 2.6.20.4 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] blacklist NCQ on Seagate Barracuda ST380817AS
Hi, I think you forgot to blacklist this one :)
--
Seagate Barracuda ST380817AS has troubles with NCQ. For example,
unpacking a tarball on an XFS filesystem gives this:
ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen
ata1.00: cmd 61/40:00:29:a3:98/00:00:00:00:00/40 tag 0 cdb 0x0 data 32768 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
More info here:
http://lkml.org/lkml/2007/1/21/76
Blacklist it!
Signed-off-by: Paolo Ornati <[EMAIL PROTECTED]>
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 772be09..be289d0 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3781,6 +3781,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
{ "Maxtor 7B250S0", "BANC1B70", ATA_HORKAGE_NONCQ, },
{ "Maxtor 7B300S0", "BANC1B70", ATA_HORKAGE_NONCQ },
{ "Maxtor 7V300F0", "VA111630", ATA_HORKAGE_NONCQ },
+ { "ST380817AS", "3.42", ATA_HORKAGE_NONCQ },
{ "HITACHI HDS7250SASUN500G 0621KTAWSD", "K2AOAJ0AHITACHI",
ATA_HORKAGE_NONCQ },
/* NCQ hard hangs device under heavier load, needs hard power cycle */
--
Paolo Ornati
Linux 2.6.23-rc8-ga64314e6-dirty on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 07:17:05 -0700 Tejun Heo <[EMAIL PROTECTED]> wrote: > Paolo Ornati wrote: > > Seagate Barracuda ST380817AS has troubles with NCQ. For example, > > unpacking a tarball on an XFS filesystem gives this: > > > > ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen > > ata1.00: cmd 61/40:00:29:a3:98/00:00:00:00:00/40 tag 0 cdb 0x0 data 32768 > > out > > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > > Hmmm... Was there a thread about this one? Also, please cc > [EMAIL PROTECTED] Yes, this was the thread: http://lkml.org/lkml/2007/1/21/43 -- Paolo Ornati Linux 2.6.23-rc8-ga64314e6-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 15:29:08 +0100 Alan Cox <[EMAIL PROTECTED]> wrote: > > Seagate Barracuda ST380817AS has troubles with NCQ. For example, > > unpacking a tarball on an XFS filesystem gives this: > > > > ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen > > ata1.00: cmd 61/40:00:29:a3:98/00:00:00:00:00/40 tag 0 cdb 0x0 data 32768 > > out > > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > > What makes you sure that is an NCQ problem ? It goes away with: echo 1 > /sys/block/sda/device/queue_depth I have this problem only with XFS, and even with XFS it goes away mounting with "nobarrier"... -- Paolo Ornati Linux 2.6.23-rc8-ga64314e6-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] blacklist NCQ on Seagate Barracuda ST380817AS
. Priority:-1 extents:1 across:1004020k [ 53.680358] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 150.036560] SGI XFS with large block/inode numbers, no debug enabled [ 150.076345] XFS mounting filesystem sda1 [ 150.138250] Ending clean XFS mount for filesystem: sda1 [ 372.948796] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen [ 372.948805] ata1.00: cmd 61/40:00:29:a3:98/00:00:00:00:00/40 tag 0 cdb 0x0 data 32768 out [ 372.948806] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 373.252286] ata1: soft resetting port [ 373.458239] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 373.461012] ata1.00: configured for UDMA/133 [ 373.461022] ata1: EH complete [ 373.461061] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB) [ 373.461075] sd 0:0:0:0: [sda] Write Protect is off [ 373.461077] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 373.461095] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA -- Paolo Ornati Linux 2.6.23-rc8-ga64314e6 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 11:43:38 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > it isn't supported here:
> > sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> > support DPO or FUA
>
> Did you actually try my suggestion?
Yes ("libata.fua=1" is ok I think, or it should just be "libata.fua"?):
...
[0.00] Kernel command line: root=/dev/sda6 ro vga=0x305 libata.fua=1
...
[ 285.004166] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2 frozen
...
>
> That message is normal, because libata defaults to FUA==off.
--
Paolo Ornati
Linux 2.6.23-rc8-ga64314e6 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 11:59:45 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Is libata built into the kernel, or a module?
built-in, my kernel is pretty monolithic
--
Paolo Ornati
Linux 2.6.23-rc8-ga64314e6 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] blacklist NCQ on Seagate Barracuda ST380817AS
On Sun, 30 Sep 2007 17:45:41 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote: > Are you sure this isn't just a bum drive? Looking at the SMART listing > that was posted, looks like it's had some uncorrectable sector read > errors in the event log.. Don't know. The error count is still 12 today, the differences are: --> === START OF INFORMATION SECTION === @@ -10,7 +10,7 @@ Device is:In smartctl database [for details use: -P show] ATA Version is: 6 ATA Standard is: ATA/ATAPI-6 T13 1410D revision 2 -Local Time is:Sun Jan 21 20:15:40 2007 CET +Local Time is:Mon Oct 1 09:01:05 2007 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled @@ -48,21 +48,22 @@ SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE - 1 Raw_Read_Error_Rate 0x000f 059 049 006Pre-fail Always - 215927244 + 1 Raw_Read_Error_Rate 0x000f 060 047 006Pre-fail Always - 129093793 3 Spin_Up_Time0x0003 098 098 000Pre-fail Always - 0 - 4 Start_Stop_Count0x0032 098 098 020Old_age Always - 2182 + 4 Start_Stop_Count0x0032 097 097 020Old_age Always - 3094 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 - 7 Seek_Error_Rate 0x000f 083 060 030Pre-fail Always - 204305750 - 9 Power_On_Hours 0x0032 097 097 000Old_age Always - 3494 + 7 Seek_Error_Rate 0x000f 084 060 030Pre-fail Always - 298020973 + 9 Power_On_Hours 0x0032 094 094 000Old_age Always - 5274 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 - 12 Power_Cycle_Count 0x0032 098 098 020Old_age Always - 2541 -194 Temperature_Celsius 0x0022 024 040 000Old_age Always - 24 (Lifetime Min/Max 0/15) -195 Hardware_ECC_Recovered 0x001a 059 049 000Old_age Always - 215927244 + 12 Power_Cycle_Count 0x0032 097 097 020Old_age Always - 3457 +194 Temperature_Celsius 0x0022 023 040 000Old_age Always - 23 (Lifetime Min/Max 0/15) +195 Hardware_ECC_Recovered 0x001a 060 047 000Old_age Always - 129093793 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always - 1 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 1 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always - 0 200 Multi_Zone_Error_Rate 0x 100 253 000Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000Old_age Always - 0 <--- Moreover the five logged errors are all about the same sector: Error 12 occurred at disk power-on lifetime: 2516 hours (104 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 0d 5b 9d 34 e1 Error: UNC 13 sectors at LBA = 0x01349d5b = 20225371 - That sector isn't in mine XFS partition (sda1): First Last # Type Sector Sector OffsetLength Filesystem Type (ID) Flag -- --- --- --- -- --- 1 Primary 02924*632925*Linux (83) Boot 2 Primary2925* 156296384 0 136295460 Extended (05)None 5 Logical2925* 20161574*63 160650 Linux (83) None 6 Logical20161575* 120166199 63 14625 Linux (83) None 7 Logical 120166200 122174324 63 2008125 Linux swap / So (82) None 8 Logical 122174325 156296384 6334122060 Linux (83) None So I don't know. To me it looks like these errors are not related... -- Paolo Ornati Linux 2.6.23-rc8-ga64314e6 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: The vi editor causes brain damage
On Sun, 19 Aug 2007 14:31:21 +0200 Benny Amorsen <[EMAIL PROTECTED]> wrote: > >>>>> "WT" == Willy Tarreau <[EMAIL PROTECTED]> writes: > > WT> Under unix, the shell resolves "*" and passes the 1 file names > WT> to the "rm" command. Now, execve() may fail because 1 names in > WT> arguments can require too much memory. That's why find and xargs > WT> were invented! > > It would be very handy if the argument memory space was expanded. > Many years ago I hit the limit regularly on Solaris, and going to > Linux with its comparatively large limit was a joy. Now it happens to > me quite often on Linux as well. > done :) commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba Author: Ollie Wild <[EMAIL PROTECTED]> Date: Thu Jul 19 01:48:16 2007 -0700 mm: variable length argument support Remove the arg+env limit of MAX_ARG_PAGES by copying the strings directly from the old mm into the new mm. -- Paolo Ornati Linux 2.6.23-rc3-g2a677896 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: at arch/x86_64/kernel/smp.c:379 smp_call_function_single()
On Sun, 19 Aug 2007 13:55:13 +0300
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Sorry about the delay -- here is the fairly simple patch. A Tested-by:
> would be appreciated.
it works :)
Tested-by: Paolo Ornati <[EMAIL PROTECTED]>
--
Paolo Ornati
Linux 2.6.23-rc3-g2a677896-dirty on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: variable length argument support (was: [OT] Re: The vi editor causes brain damage)
On Sun, 19 Aug 2007 15:07:01 +0200 (CEST) Jan Engelhardt <[EMAIL PROTECTED]> wrote: > >Remove the arg+env limit of MAX_ARG_PAGES by copying the strings > >directly from the old mm into the new mm. > > Me wonders. Will that make the "checking for maximum length of command line > arguments" from autotools run forever since execve() will not fail anymore? Since I'm running Gentoo and do many compiles I can tell that it works :) If I remeber correctly it was discussed on LKML and turend out that that check is done starting with a "max" len and going down rather than starting low and going up. -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
On Sun, 19 Aug 2007 06:22:37 -0700 (PDT) Marc Perkel <[EMAIL PROTECTED]> wrote: > 20 years, a million programmers, tens of millions of > users and RM is BROKEN. Am I the only one who has a > problem with this? If so - I'm normal - and Linux is a > cult. Fixed in 2.6.23-rc (and not just for "rm"): commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba Author: Ollie Wild <[EMAIL PROTECTED]> Date: Thu Jul 19 01:48:16 2007 -0700 mm: variable length argument support Remove the arg+env limit of MAX_ARG_PAGES by copying the strings directly from the old mm into the new mm. [...] -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: huge improvement with per-device dirty throttling
On 22 Aug 2007 13:05:13 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote: > "Jeffrey W. Baker" <[EMAIL PROTECTED]> writes: > > > > My system is a Core 2 Duo, 2GB, single SATA disk. > > Hmm, I thought the patch was only supposed to make a real difference > if you have multiple devices? But you only got a single disk. No, there's also: [PATCH 22/23] mm: dirty balancing for tasks :) -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ideas on column length in kernel "problem"?
On Wed, 22 Aug 2007 23:54:41 -0400 "Scott Thompson" <[EMAIL PROTECTED]> wrote: > if anyone knows of a free/inexpensive mail > client that will be able to handle the wordwrap requirements for > the current state of the linux tree please advise. http://www.claws-mail.org/ Configuration -> Preferences -> Wrapping: " [x] Auto wrapping [ ] Wrap quotation [ ] Wrap pasted text Wrap messages at [..] characters" Then use the "Insert File" button or (xclip < mypatch.diff && middle mouse button). Either will wrap with "Wrap pasted text", so keep it off. PS: auto wrapping has effect on the text you write directly in the mailer, you can even turn it off and use "CTRL + L" to wrap the current paragraph. -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ideas on column length in kernel "problem"?
On Thu, 23 Aug 2007 13:56:48 +0200
walter harms <[EMAIL PROTECTED]> wrote:
> xclip converts tabs to space if i remember correctly
no, it doesn't
[EMAIL PROTECTED] ~ $ echo -e "\tHello" | xclip
(middle mouse button)
Hello
:)
--
Paolo Ornati
Linux 2.6.23-rc3-g2a677896-dirty on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
"double" hpet clocksource && hard freeze [bisected]
Hi, since commit: commit 0aa366f351d044703e25c8425e508170e80d83b1 Author: Tony Luck <[EMAIL PROTECTED]> Date: Fri Jul 20 11:22:30 2007 -0700 [IA64] Convert to generic timekeeping/clocksource This is a merge of Peter Keilty's initial patch (which was revived by Bob Picco) for this with Hidetoshi Seto's fixes and scaling improvements. I have a double "hpet" entry in "available_clocksource": $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet hpet acpi_pm jiffies And, more interesting, if I select hpet as clocksource (tsc is used by default here) I get an hard freeze some time later (few minutes)... SysRQ don't work ;) config & dmesg attached Motherboard is a Intel DG965SS CPU: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1864.804 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3731.75 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1864.804 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3729.63 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: -- Paolo Ornati Linux 2.6.22-g5bae7ac9 on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "double" hpet clocksource && hard freeze [bisected]
On Thu, 23 Aug 2007 22:21:15 +0200
Paolo Ornati <[EMAIL PROTECTED]> wrote:
> config & dmesg attached
ehmm..
--
Paolo Ornati
Linux 2.6.22-g5bae7ac9 on x86_64
config.gz
Description: GNU Zip compressed data
dmesg.gz
Description: GNU Zip compressed data
Re: "double" hpet clocksource && hard freeze [bisected]
On Thu, 23 Aug 2007 14:41:45 -0700 john stultz <[EMAIL PROTECTED]> wrote: > > My initial reaction would be to either ifdef ia64 implementation in > > drivers/char/hpet.c or move the code under the ia64 arch dir until it is > > really usable by all arches. > > Here is a possible quick fix. I'm open to other approaches, but I also > want to avoid too much churn before 2.6.23 goes out. > > Paolo, could you verify this fixes the issue for you? It works: there's only one "hpet" in "available_clocksource" and also the hard freeze using it seems gone. :) -- Paolo Ornati Linux 2.6.23-rc3-g1a8f4610-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "double" hpet clocksource && hard freeze [bisected]
On Thu, 23 Aug 2007 17:38:49 -0400 "Bob Picco" <[EMAIL PROTECTED]> wrote: > It appears ACPI discovery failed during driver initialization because > of: > hpet_resources: 0xfed0 is busy Note: this was always there as far as I can remember. -- Paolo Ornati Linux 2.6.23-rc3-g1a8f4610-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "double" hpet clocksource && hard freeze [bisected]
On Fri, 24 Aug 2007 08:46:31 -0400 "Bob Picco" <[EMAIL PROTECTED]> wrote: > Prevent duplicate names being registered with clocksource. This also > eliminates the duplication of hpet clock registration when the arch > uses the hpet timer and the hpet driver does too. The patch was > compile and link tested. This one works too. -- Paolo Ornati Linux 2.6.23-rc3-g1a8f4610-dirty on x86_64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
