Re: [PATCH for testing] Re: Decreasing stime running confuses top
On 10/5/07, Chuck Ebbert <[EMAIL PROTECTED]> wrote: > On 10/04/2007 05:10 PM, Christian Borntraeger wrote: > > > > > Alternative patch: > > procfs: Don't read runtime twice when computing task's stime > > Current code reads p->se.sum_exec_runtime twice and goes through > multiple type conversions to calculate stime. Read it once and > skip some of the conversions. Works fine here. > > Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]> Tested-By: Luca Tettamanti <[EMAIL PROTECTED]> Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] [PATCH] 32-bit pointers in x86-64
This proof of concept patch modifies GCC to have 32-bit pointers and
longs on x86-64.
This allows to create an "x86-32" architecture that takes advantage of
the higher number of registers and support for 64-bit computation in
x86-64 long mode while avoiding the disadvantage of increased memory
usage due to 64-bit pointers and longs in structures.
Thus, such a GCC version could be used to produce a GNU/Linux
distribution with the performance of x86-64 and the reduced memory
usage of i386. Furthermore, programs requiring "large data" could use
special "64-bit pointer" attributes to only use 64-bit pointers to
reference the relevant large arrays/structures, using 32-bit pointers
for everything else.
The current patch is just an hack and should obviously be made
configurable and reimplemented properly.
Just setting POINTER_SIZE to 32 mostly works but more hacks are
necessary to get PIC compilation working (note that the hacks are
probably at least partially wrong, since I'm not an experienced GCC
hacker).
A patch to binutils is also required to stop it from complaining about
32-bit relocations in shared objects.
Currently a simple "Hello world!" program will work using a standard
x86-64 dynamic loader and libc.
This is because the function call ABI is unchanged and thus anything
that doesn't use structures containing pointers or longs should be
binary compatible.
I do not really intend to work on this personally: I did this initial
work for fun and I'm posting these patches to possibly stimulate
broader interest on this concept.
A possible roadmap for this would be:
1. Make it configurable
2. Fix the LEA hacks and allow proper PIC compilation
3. Fix everything else that may not work properly (e.g. PIC,
relocations, exception handling, TLS, debug info)
4. Add a "32-bit object" flag to x86-64 objects
5. Modify libc so that allocations are made in the lower 4GB space for
x86-32 shared objects and modify x86-64 assembly code to work with
32-bit pointers
6. Compile a native x86-32 libc and compile and test a full Debian or
Ubuntu distribution
7. Add support for loading x86-32 and x86-64 objects in the same
address space, using a single modified 64-bit libc (that for
compatibility actually generate pointers in the low 4GB)
7.1. Add __attribute__((pointer_size(XXX))) and #pragma pointer_size
to allow 64-bit pointers in 32-bit mode and viceversa
7.2. Surround glibc headers with #pragma pointer_size 64
7.3. Modify the dynamic loader to support different namespaces and
directories for x86-32 and x86-64. Symbols starting with "__64_" or
"__32_" or similar could be mapped to the other namespace. Also
support "multiarchitecture" objects that would be added to both.
7.4. Split malloc/mmap in __32_malloc, __32_mmap and similar in glibc.
glibc itself would use 32-bit allocations and be loaded in the low
4GB.
7.5. Compile the result and use a modified libc/dynamic loader
compiled in x86-64 mode flagged as multiarchitecture to load both
x86-32 and x86-64 objects
8. Modify popular programs to explicitly use 64-bit allocations and
pointers for potentially huge allocations (e.g. database caches,
compression program data structures, P2P software file mappings)
Patches are against GCC 4.2.2 and Binutils HEAD.
Index: bfd/elf64-x86-64.c
===
RCS file: /cvs/src/src/bfd/elf64-x86-64.c,v
retrieving revision 1.144
diff -u -r1.144 elf64-x86-64.c
--- bfd/elf64-x86-64.c 18 Oct 2007 09:13:51 - 1.144
+++ bfd/elf64-x86-64.c 25 Nov 2007 14:19:17 -
@@ -1038,6 +1038,8 @@
case R_X86_64_TPOFF32:
if (info->shared)
{
+ if(0)
+ {
(*_bfd_error_handler)
(_("%B: relocation %s against `%s' can not be used when making a shared object; recompile with -fPIC"),
abfd,
@@ -1045,6 +1047,7 @@
(h) ? h->root.root.string : "a local symbol");
bfd_set_error (bfd_error_bad_value);
return FALSE;
+ }
}
break;
@@ -1198,6 +1201,8 @@
&& (sec->flags & SEC_ALLOC) != 0
&& (sec->flags & SEC_READONLY) != 0)
{
+ if(0)
+ {
(*_bfd_error_handler)
(_("%B: relocation %s against `%s' can not be used when making a shared object; recompile with -fPIC"),
abfd,
@@ -1205,6 +1210,7 @@
(h) ? h->root.root.string : "a local symbol");
bfd_set_error (bfd_error_bad_value);
return FALSE;
+ }
}
/* Fall through. */
@@ -2599,6 +2605,8 @@
|| !is_32bit_relative_branch (contents,
rel->r_offset)))
{
+ if(0)
+ {
if (h->def_regular
&& r_type == R_X86_64_PC32
&& h->type == STT_FUNC
@@ -2613,6 +2621,7 @@
h->root.root.string);
bfd_set_error (bfd_error_bad_value);
return FALSE;
+ }
}
/* Fall through. */
diff -ur g_orig/gcc-4.2.2/gcc/config/i386/i386.c gcc-4.2.2/gcc/config/i386/i386.c
--- g_orig/gcc-4.2.2/gcc/config/i386/i386.c 2007-09-01 17:28:30.0 +0200
+++ gcc-4.2.2/gcc/config/i386/i386.c
[PATCH 2.6] Check return of copy_from_user value in cifssmb.c [Re: Linux 2.6.11-rc4]
Linus Torvalds <[EMAIL PROTECTED]> ha scritto:
> this is hopefully the last -rc kernel before the real 2.6.11, so please
> give it a whirl, and complain loudly about anything broken.
The following patch against 2.6.11-rc4 fixes this compile time warning:
fs/cifs/cifssmb.c: In function `CIFSSMBWrite':
fs/cifs/cifssmb.c:902: warning: ignoring return value of
`copy_from_user', declared with attribute warn_unused_result
It also fixes the strange indentation of the code in that point. Also
note that pSMB cannot be NULL, since the return value of smb_init (which
initiliaze pSMB) is checked (see line 874).
Signed-off-by: Luca Tettamanti <[EMAIL PROTECTED]>
--- a/fs/cifs/cifssmb.c 2005-02-03 17:43:18.0 +0100
+++ b/fs/cifs/cifssmb.c 2005-02-03 17:47:29.0 +0100
@@ -896,14 +896,17 @@
pSMB->DataLengthHigh = 0;
pSMB->DataOffset =
cpu_to_le16(offsetof(struct smb_com_write_req,Data) - 4);
-if(buf)
- memcpy(pSMB->Data,buf,bytes_sent);
- else if(ubuf)
- copy_from_user(pSMB->Data,ubuf,bytes_sent);
-else {
- /* No buffer */
- if(pSMB)
+
+ if(buf)
+ memcpy(pSMB->Data, buf, bytes_sent);
+ else if(ubuf) {
+ if (copy_from_user(pSMB->Data, ubuf, bytes_sent)) {
cifs_buf_release(pSMB);
+ return -EFAULT;
+ }
+ } else {
+ /* No buffer */
+ cifs_buf_release(pSMB);
return -EINVAL;
}
Luca
--
Home: http://kronoz.cjb.net
Il dottore mi ha detto di smettere di fare cene intime per quattro.
A meno che non ci siamo altre tre persone.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6] Check return value of copy_to_user in fs/cifs/file.c [Re: Linux 2.6.11-rc4]
Linus Torvalds <[EMAIL PROTECTED]> ha scritto:
> this is hopefully the last -rc kernel before the real 2.6.11, so please
> give it a whirl, and complain loudly about anything broken.
The following patch against 2.6.11-rc4 fixes this compile time warning:
CC [M] fs/cifs/file.o
fs/cifs/file.c: In function `cifs_user_read':
fs/cifs/file.c:1168: warning: ignoring return value of
`copy_to_user', declared with attribute warn_unused_result
I also added an explicit check for errors other than -EAGAIN, since
CIFSSMBRead may return -ENOMEM if it's unable to allocate smb_com_read_rsp;
in that case we don't want to call copy_to_user with a NULL pointer.
Signed-off-by: Luca Tettamanti <[EMAIL PROTECTED]>
--- a/fs/cifs/file.c2005-02-03 17:58:07.0 +0100
+++ b/fs/cifs/file.c2005-02-03 18:17:37.0 +0100
@@ -1151,7 +1151,7 @@
current_read_size = min_t(const int,read_size -
total_read,cifs_sb->rsize);
rc = -EAGAIN;
smb_read_data = NULL;
- while(rc == -EAGAIN) {
+ while(1) {
if ((open_file->invalidHandle) &&
(!open_file->closePend)) {
rc = cifs_reopen_file(file->f_dentry->d_inode,
file,TRUE);
@@ -1164,13 +1164,22 @@
current_read_size, *poffset,
&bytes_read, &smb_read_data);
+ if (rc == -EAGAIN)
+ continue;
+ else
+ break;
+
pSMBr = (struct smb_com_read_rsp *)smb_read_data;
- copy_to_user(current_offset,smb_read_data + 4/* RFC1001
hdr*/
+ rc = copy_to_user(current_offset,smb_read_data + 4/*
RFC1001 hdr*/
+ le16_to_cpu(pSMBr->DataOffset), bytes_read);
if(smb_read_data) {
cifs_buf_release(smb_read_data);
smb_read_data = NULL;
}
+ if (rc) {
+ FreeXid(xid);
+ return -EFAULT;
+ }
}
if (rc || (bytes_read == 0)) {
if (total_read) {
Luca
--
Home: http://kronoz.cjb.net
Se non sei parte della soluzione, allora sei parte del problema.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6] Check return value of copy_to_user in fs/cifs/file.c [Re: Linux 2.6.11-rc4]
Il Sun, Feb 13, 2005 at 06:28:38PM +0100, Marcel Sebek ha scritto:
> > @@ -1164,13 +1164,22 @@
> > current_read_size, *poffset,
> > &bytes_read, &smb_read_data);
> >
> > + if (rc == -EAGAIN)
> > + continue;
> > + else
> > + break;
> > +
> > pSMBr = (struct smb_com_read_rsp *)smb_read_data;
> ^
> Perhaps this line and the following lines are never executed with your
> patch, am I right?
Yes, you are. Let's try again:
The following patch against 2.6.11-rc4 fixes this compile time
warning:
CC [M] fs/cifs/file.o
fs/cifs/file.c: In function `cifs_user_read':
fs/cifs/file.c:1168: warning: ignoring return value of
`copy_to_user', declared with attribute warn_unused_result
I also added an explicit check for errors other than -EAGAIN, since
CIFSSMBRead may return -ENOMEM if it's unable to allocate
smb_com_read_rsp; in that case we don't want to call copy_to_user with a
NULL pointer.
Signed-off-by: Luca Tettamanti <[EMAIL PROTECTED]>
--- a/fs/cifs/file.c2005-02-03 17:58:07.0 +0100
+++ b/fs/cifs/file.c2005-02-13 21:18:01.0 +0100
@@ -1151,7 +1151,7 @@
current_read_size = min_t(const int,read_size -
total_read,cifs_sb->rsize);
rc = -EAGAIN;
smb_read_data = NULL;
- while(rc == -EAGAIN) {
+ while(1) {
if ((open_file->invalidHandle) &&
(!open_file->closePend)) {
rc = cifs_reopen_file(file->f_dentry->d_inode,
file,TRUE);
@@ -1164,13 +1164,22 @@
current_read_size, *poffset,
&bytes_read, &smb_read_data);
+ if (rc == -EAGAIN)
+ continue;
+ if (rc)
+ break;
+
pSMBr = (struct smb_com_read_rsp *)smb_read_data;
- copy_to_user(current_offset,smb_read_data + 4/* RFC1001
hdr*/
+ rc = copy_to_user(current_offset,smb_read_data + 4/*
RFC1001 hdr*/
+ le16_to_cpu(pSMBr->DataOffset), bytes_read);
if(smb_read_data) {
cifs_buf_release(smb_read_data);
smb_read_data = NULL;
}
+ if (rc) {
+ FreeXid(xid);
+ return -EFAULT;
+ }
}
if (rc || (bytes_read == 0)) {
if (total_read) {
Luca
--
Home: http://kronoz.cjb.net
"La teoria e` quando sappiamo come funzionano le cose ma non funzionano.
La pratica e` quando le cose funzionano ma non sappiamo perche`.
Abbiamo unito la teoria e la pratica: le cose non funzionano piu` e non
sappiamo il perche`." -- A. Einstein
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6] Check return value of copy_to_user in fs/cifs/file.c
Hello,
the following patch against 2.6.11-rc3 fixes this compile time warning:
CC [M] fs/cifs/file.o
fs/cifs/file.c: In function `cifs_user_read':
fs/cifs/file.c:1168: warning: ignoring return value of
`copy_to_user', declared with attribute warn_unused_result
I also added an explicit check for errors other than -EAGAIN, since
CIFSSMBRead may return -ENOMEM if it's unable to allocate smb_com_read_rsp;
in that case we don't want to call copy_to_user with a NULL pointer.
Signed-off-by: Luca Tettamanti <[EMAIL PROTECTED]>
--- a/fs/cifs/file.c2005-02-03 17:58:07.0 +0100
+++ b/fs/cifs/file.c2005-02-03 18:17:37.0 +0100
@@ -1151,7 +1151,7 @@
current_read_size = min_t(const int,read_size -
total_read,cifs_sb->rsize);
rc = -EAGAIN;
smb_read_data = NULL;
- while(rc == -EAGAIN) {
+ while(1) {
if ((open_file->invalidHandle) &&
(!open_file->closePend)) {
rc = cifs_reopen_file(file->f_dentry->d_inode,
file,TRUE);
@@ -1164,13 +1164,22 @@
current_read_size, *poffset,
&bytes_read, &smb_read_data);
+ if (rc == -EAGAIN)
+ continue;
+ else
+ break;
+
pSMBr = (struct smb_com_read_rsp *)smb_read_data;
- copy_to_user(current_offset,smb_read_data + 4/* RFC1001
hdr*/
+ rc = copy_to_user(current_offset,smb_read_data + 4/*
RFC1001 hdr*/
+ le16_to_cpu(pSMBr->DataOffset), bytes_read);
if(smb_read_data) {
cifs_buf_release(smb_read_data);
smb_read_data = NULL;
}
+ if (rc) {
+ FreeXid(xid);
+ return -EFAULT;
+ }
}
if (rc || (bytes_read == 0)) {
if (total_read) {
Luca
--
Home: http://kronoz.cjb.net
Quando un uomo porta dei fiori a sua moglie senza motivo,
un motivo c'e`.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6] Check return of copy_from_user value in cifssmb.c
Hello,
the following patch against 2.6.11-rc3 fixes this compile time warning:
fs/cifs/cifssmb.c: In function `CIFSSMBWrite':
fs/cifs/cifssmb.c:902: warning: ignoring return value of
`copy_from_user', declared with attribute warn_unused_result
It also fixes the strange indentation of the code in that point. Also
note that pSMB cannot be NULL, since the return value of smb_init (which
initiliaze pSMB) is checked (see line 874).
Signed-off-by: Luca Tettamanti <[EMAIL PROTECTED]>
--- a/fs/cifs/cifssmb.c 2005-02-03 17:43:18.0 +0100
+++ b/fs/cifs/cifssmb.c 2005-02-03 17:47:29.0 +0100
@@ -896,14 +896,17 @@
pSMB->DataLengthHigh = 0;
pSMB->DataOffset =
cpu_to_le16(offsetof(struct smb_com_write_req,Data) - 4);
-if(buf)
- memcpy(pSMB->Data,buf,bytes_sent);
- else if(ubuf)
- copy_from_user(pSMB->Data,ubuf,bytes_sent);
-else {
- /* No buffer */
- if(pSMB)
+
+ if(buf)
+ memcpy(pSMB->Data, buf, bytes_sent);
+ else if(ubuf) {
+ if (copy_from_user(pSMB->Data, ubuf, bytes_sent)) {
cifs_buf_release(pSMB);
+ return -EFAULT;
+ }
+ } else {
+ /* No buffer */
+ cifs_buf_release(pSMB);
return -EINVAL;
}
Luca
--
Home: http://kronoz.cjb.net
Un apostolo vedendo Gesu` camminare sulle acque:
- Cazzo se e` buono 'sto fumo!!!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Garbage on serial console after serial driver loads
Hi, I attached a null modem cable to my notebook and I'm seeing garbage as soon as the serial driver is loaded. I tried booting with init=/bin/bash to be sure that it's not some rc script doing strange things to the serial port, but this didn't solve the problem. This is the relevant part of .config: # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y # CONFIG_SERIAL_8250_CS is not set # CONFIG_SERIAL_8250_ACPI is not set CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set I also tried with ACPI discovery (just in case) without success: # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y # CONFIG_SERIAL_8250_CS is not set CONFIG_SERIAL_8250_ACPI=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set # CONFIG_SERIAL_8250_SHARE_IRQ is not set CONFIG_SERIAL_8250_DETECT_IRQ=y # CONFIG_SERIAL_8250_MULTIPORT is not set # CONFIG_SERIAL_8250_RSA is not set This is kernel command line: Kernel command line: BOOT_IMAGE=linux-2.6.12rc1 ro root=305 video=sisfb:mode:1024x768x16 console=tty0 console=ttyS0,38400n8 init=/bin/bash And this is where garbage appears: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 i8042.c: Detected active multiplexing controller, rev 1.1. serio: i8042 AUX0 port at 0x60,0x64 irq 12 serio: i8042 AUX1 port at 0x60,0x64 irq 12 serio: i8042 AUX2 port at 0x60,0x64 irq 12 serio: i8042 AUX3 port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled [garbage] Once I get the shell using 'clear' cures the problem. The log (from dmesg) should be: Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A This is the first time that I use serial console with the notebook, but I've done this before with other machines and never saw this problem. Googling aroung I found another user with the same problem: http://www.ussg.iu.edu/hypermail/linux/kernel/0503.1/0442.html but no answer :( Any suggestion? Luca -- Home: http://kronoz.cjb.net Un apostolo vedendo Gesu` camminare sulle acque: - Cazzo se e` buono 'sto fumo!!! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Garbage on serial console after serial driver loads
Il Fri, Mar 25, 2005 at 08:38:53PM +, Russell King ha scritto: > On Fri, Mar 25, 2005 at 09:24:15PM +0100, Luca wrote: > > I attached a null modem cable to my notebook and I'm seeing garbage as > > soon as the serial driver is loaded. I tried booting with init=/bin/bash > > to be sure that it's not some rc script doing strange things to the > > serial port, but this didn't solve the problem. > > I'm uncertain how this problem can occur, unless you have one of: > > * serial debugging enabled (which isn't compatible with serial console) Do you mean #define DEBUG in serial_core.c? No. > * a NS16550A, in which case dwmw2 needs to rework his autodetect code to > adjust the baud rate appropriately. Well, serial_core seems to think so: Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A Luca -- Home: http://kronoz.cjb.net La mia opinione puo` essere cambiata, ma non il fatto che ho ragione. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Garbage on serial console after serial driver loads
Il Sat, Mar 26, 2005 at 11:16:09AM +0100, Jan Engelhardt ha scritto: > >Well, serial_core seems to think so: > > > >Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled > >ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A > >ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A > >ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A > > Does it work if you set the baud rate manually, as a bootloader option? I'm using console=ttyS0,38400n8. But it also happens with 9600, 57600 and 115200. Luca -- Home: http://kronoz.cjb.net Mi piace avere amici rispettabili; Mi piace essere il peggiore della compagnia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc4: BAD regression
On 8/30/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Thu, 30 Aug 2007, Daniel Ritz wrote: > > > > i've just tested the minimal fix here: > > http://bugzilla.kernel.org/show_bug.cgi?id=8958#c7 > > works good so far. fan starts and system is responsive. > > Alexey, Len, can we get this fix integrated asap? Tested here, works fine. Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ipv4_get_l4proto: Frag of proto 17
On 9/2/07, Prakash Punnoor <[EMAIL PROTECTED]> wrote: > Hi, > > since 2.6.23-rc1 my log gets cluttered with > > ipv4_get_l4proto: Frag of proto 17 > > What is the reason? netfilter conntrack code. See: http://article.gmane.org/gmane.linux.network/70824 Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hitachi disk: spurious completions during NCQ
On 10/13/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 10 Oct 2007 21:03:43 +0200 > Luca Tettamanti <[EMAIL PROTECTED]> wrote: > > > Hello, > > sometimes kernel complains about spurious completions on my new > > notebook: > > > > ata3.00: exception Emask 0x2 SAct 0x407fd SErr 0x0 action 0x2 frozen > > ata3.00: spurious completions during NCQ issue=0x0 SAct=0x407fd > > FIS=005040a1:0002 > > ata3.00: cmd 61/08:00:c7:5a:82/00:00:1b:00:00/40 tag 0 cdb 0x0 data 4096 out > > res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) > > ata3.00: cmd 61/08:10:3f:5b:fa/00:00:18:00:00/40 tag 2 cdb 0x0 data 4096 out > > res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) > > ata3.00: cmd 61/08:18:5f:5b:fa/00:00:18:00:00/40 tag 3 cdb 0x0 data 4096 out > > res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) > > ata3.00: cmd 61/18:20:6f:5b:fa/00:00:18:00:00/40 tag 4 cdb 0x0 data 12288 > > out > > res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) > > ata3.00: cmd 61/08:28:e7:19:fd/00:00:18:00:00/40 tag 5 cdb 0x0 data 4096 out > > res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) > > ata3.00: cmd 61/08:30:df:59:ae/00:00:1a:00:00/40 tag 6 cdb 0x0 data 4096 out > > res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) > > ata3.00: cmd 61/08:38:3f:5a:ae/00:00:1a:00:00/40 tag 7 cdb 0x0 data 4096 out > > res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) > > ata3.00: cmd 61/08:40:6f:62:ae/00:00:1a:00:00/40 tag 8 cdb 0x0 data 4096 out > > res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) > > ata3.00: cmd 61/28:48:d7:59:7e/00:00:1b:00:00/40 tag 9 cdb 0x0 data 20480 > > out > > res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) > > ata3.00: cmd 61/10:50:07:5b:82/00:00:1b:00:00/40 tag 10 cdb 0x0 data 8192 > > out > > res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) > > ata3.00: cmd 61/30:90:f7:5a:fa/00:00:18:00:00/40 tag 18 cdb 0x0 data 24576 > > out > > res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) > > ata3: soft resetting port > > ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > > ata3.00: configured for UDMA/133 > > ata3: EH complete > > sd 2:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) > > sd 2:0:0:0: [sda] Write Protect is off > > sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 > > sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't > > support DPO or FUA > > > > (this is a very recent 2.6.23-git, SMP, x86_64) > > The latest kernel, a serious-looking problem, sent to the correct mailing > lists. After two days nobody has bothered replying. > > > The disk is: > > > > ATA device, with non-removable media > > Model Number: Hitachi HTS542525K9SA00 > > Firmware Revision: BBFOC31P > > > > The controller is: > > > > 00:1f.2 SATA controller: Intel Corporation Mobile SATA AHCI Controller (rev > > 03) (prog-if 01 [AHCI 1.0]) > > Subsystem: ASUSTeK Computer Inc. Unknown device 14e7 > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > > Stepping- SERR- FastB2B- > > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > > SERR- > Latency: 0 > > Interrupt: pin B routed to IRQ 1272 > > Region 0: I/O ports at ec00 [size=8] > > Region 1: I/O ports at e880 [size=4] > > Region 2: I/O ports at e800 [size=8] > > Region 3: I/O ports at e480 [size=4] > > Region 4: I/O ports at e400 [size=32] > > Region 5: Memory at febff800 (32-bit, non-prefetchable) [size=2K] > > Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- > > Queue=0/2 Enable+ > > Address: fee0300c Data: 41b9 > > Capabilities: [70] Power Management version 3 > > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > > PME(D0-,D1-,D2-,D3hot+,D3cold-) > > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > > Capabilities: [a8] #12 [0010] > > > > and I'm using AHCI driver. > > > > I see that similar disks are already blacklisted, probably this one is > > bugged too - though the error is pretty rare :( > > > > Does this cause any other symptoms? ie: does the system otherwise work OK? The system is stable, the EH seems to be doing its job. Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hitachi disk: spurious completions during NCQ
On 10/15/07, Don Mullis <[EMAIL PROTECTED]> wrote: > > > ata3.00: spurious completions during NCQ issue=0x0 SAct=0x407fd > > FIS=005040a1:0002 > > ata3.00: cmd 61/08:00:c7:5a:82/00:00:1b:00:00/40 tag 0 cdb 0x0 data 4096 out > > res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) > > > This has been seen with several Hitachi drives. There's speculation > that it's due to a bug in the drive firmware: Yes, I'm aware of this. That's why I was suggesting to blacklist this drive. thanks, Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [KVM][PATCH] smp_processor_id() and sleeping functions used in invalid context
On 12/31/06, Avi Kivity <[EMAIL PROTECTED]> wrote:
Luca Tettamanti wrote:
> Hello,
> I'm testing KVM on a Core2 CPU. I'm running kernel 2.6.20-git (pulled
> few hours ago), configured with SMP and PREEMPT.
>
> I'm hitting 2 different warnings:
> BUG: using smp_processor_id() in preemptible [0001] code: kvm/7726
> caller is vmx_create_vcpu+0x9/0x2f [kvm_intel]
[...]
> Second one:
> BUG: sleeping function called from invalid context at
> /home/kronos/src/linux-2.6.git/mm/slab.c:3034
> in_atomic():1, irqs_disabled():0
> 1 lock held by kvm/12706:
> #0: (&vcpu->mutex){--..}, at: [] kvm_dev_ioctl+0x113/0xf97
> [kvm]
> [] kmem_cache_alloc+0x1b/0x6f
>
[...]
There are patches for both (I think) flying around. They should land in
Linus' tree in a few days.
Ah, I just saw them on lkml...
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] radeonfb: add support for newer cards
On 1/2/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: On Mon, 2007-01-01 at 22:44 +0100, Luca Tettamanti wrote: > Il Mon, Jan 01, 2007 at 10:25:51PM +0100, Luca Tettamanti ha scritto: > > Hi Ben, Andrew, > > I've rebased 'ATOM BIOS patch' from Solomon Peachy to apply to 2.6.20. > > The patch adds support for newer Radeon cards and is mainly based on > > X.Org code. > > And - for an easier review - this is the diff between > radeonfb-atom-2.6.19-v6a.diff from Solomon and my patch (whitespace-only > changes not included). Ah good, what I was asking for :-) I'll try to get a new patch combining everything out asap. Great, I didn't know you were working on this, I feared that the patch had been forgotten. I've a X850 (R480) here, feel free to send me any patch for testing. Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] radeonfb: add support for newer cards
On 1/3/07, Gerhard Mack <[EMAIL PROTECTED]> wrote: On Tue, 2 Jan 2007, Luca wrote: > Date: Tue, 2 Jan 2007 01:38:17 +0100 > From: Luca <[EMAIL PROTECTED]> > To: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > Cc: Andrew Morton <[EMAIL PROTECTED]>, Solomon Peachy <[EMAIL PROTECTED]>, > linux-kernel@vger.kernel.org, [EMAIL PROTECTED] > Subject: Re: [PATCH] radeonfb: add support for newer cards > > On 1/2/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-01-01 at 22:44 +0100, Luca Tettamanti wrote: > > > Il Mon, Jan 01, 2007 at 10:25:51PM +0100, Luca Tettamanti ha scritto: > > > > Hi Ben, Andrew, > > > > I've rebased 'ATOM BIOS patch' from Solomon Peachy to apply to 2.6.20. > > > > The patch adds support for newer Radeon cards and is mainly based on > > > > X.Org code. > > > > > > And - for an easier review - this is the diff between > > > radeonfb-atom-2.6.19-v6a.diff from Solomon and my patch (whitespace-only > > > changes not included). > > > > Ah good, what I was asking for :-) I'll try to get a new patch combining > > everything out asap. > > Great, I didn't know you were working on this, I feared that the patch > had been forgotten. > I've a X850 (R480) here, feel free to send me any patch for testing. Is there a list of cards this adds support for? I'm waiting on support for the X1600 The patch is for the "old" generation, R400, R480 and their mobile versions. Unfortunately the new engine used in X1xxx cards is very different and no docs are available from ATI. Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.20-rc6] pktcdvd doesn't work
On 1/31/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: Luca Tettamanti wrote: > Hi Jeff, linux-ide, > I'm having troubles with libata and UDF on RW media. See below. > > Il Tue, Jan 30, 2007 at 09:42:34PM +0100, Jan Engelhardt ha scritto: >> On Jan 30 2007 21:36, Luca Tettamanti wrote: >>> Il Tue, Jan 30, 2007 at 09:02:20PM +0100, Jan Engelhardt ha scritto: >>>> On Jan 30 2007 20:53, Luca Tettamanti wrote: >>>>> Hi, >>>>> pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file that >>>> Did it work previously? >>> Yup, It used to work but since I rarely use it I don't remember which >>> kernel version worked for me. >> Hm, maybe you can take a guess. > > I can bisect pktcdvd.c if necessary, but it seems that it's innocent. > >>>>> is written to the device is lost after umount. >>>>> I rarely use pktcdvd but at some point it used to work on my system. >>>>> >>>>> This is what I'm doing: >>>>> >>>>> [EMAIL PROTECTED]:/tmp# cdrwtool -d /dev/scd0 -q >>>>> scsi 8:0:0:0: CD-ROMHL-DT-ST DVDRAM GSA-4167B DL13 PQ: 0 ANSI: 5 >>>> In case you are using ide-scsi: try without. >>> It's libata jmicron driver. Shall I try the "old" PATA driver on the >>> next reboot? >> If you have lots of CDRs/DVDRs to spare (or a CDRW/DVDRW), every test is >> welcome. > > With the legacy IDE driver it works fine. > The unit is DVD-RAM capable so the firmware should handle random writes > fine; I've tried mounting /dev/scd0 rw *without* pktcdvd and I still > lose files. So I guess it has something to do with libata. > > So to recap, after formatting the disk with UDF: > > * libata > - mount with pktcdvd: all files are lost upon umount > - mount scd0 w/out pktcdvd: all files are lost upon umount > - write the disk with cdrecord: OK > > pktcdvd reports wrong capacity: > > pktcdvd: Fixed packets, 32 blocks, Mode-2 disc > pktcdvd: Max. media speed: 4 > pktcdvd: write speed 4x > pktcdvd: 0kB available on disc > UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2007/01/30 18:18 (103c) > > * legacy IDE driver > - mount with pktcdvd: OK > - mount hda w/out pktcdvd: corrupts FS (duh) > - write the disk with cdrecord: OK > > pktcdvd reports correct capacity: > > pktcdvd: writer pktcdvd0 mapped to hda > pktcdvd: Fixed packets, 32 blocks, Mode-2 disc > pktcdvd: Max. media speed: 4 > pktcdvd: write speed 4x > pktcdvd: 551232kB available on disc > UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2007/01/30 22:19 (103c) > > The HW is a JMicron controller: > 02:00.0 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02) > 02:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02) hmmm, definitely interesting behavior. Would you mind putting this info into a bugzilla.kernel.org report, so that it is not lost? Done, ID is 7910. Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RFC] ACPI based hwmon driver for ASUS
On 6/21/07, Rudolf Marek <[EMAIL PROTECTED]> wrote:
> Ok, it makes sense :)
>
> Name (FBUF, Package (0x06)
> {
> 0x03,
> CPUF,
> CHAF,
> PWRF,
> CHPF,
> CH2F
> })
>
> Clearly the first number is not the number of available readings (though
> it matches the count in the other DSDTs I've seen); don't know what it
> is :|
Maybe study the Pro2.dll from Asus Probe II?
Done that ;-) Disassembling is quite painful though, and most of the
work is performed by a kernel driver which I find a bit difficult to
decode.
Will fix the other issues and resend.
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RFC] ACPI based hwmon driver for ASUS
On 6/21/07, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote: Hi, I think you might be interested in following patch, which implements _ACPI_ driver for the same hardware... It is only "proof of concept" at the moment, but it does main thing -- reads hwmon device using ACPI interfaces. Well, reading is easy and is already implemented in the driver that I posted. The problem is to figure out how to control the various stuff (fans, and maybe some of the other ASUS features). Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Attansic L1 page corruption (was: 2.6.22-rc5: pdflush oops under heavy disk load)
On 6/25/07, Jay L. T. Cornwall <[EMAIL PROTECTED]> wrote: Jay Cliburn wrote: > For reasons not yet clear to me, it appears the L1 driver has a bug or > the device itself has trouble with DMA in high memory. This patch, > drafted by Luca Tettamanti, is being explored as a workaround. I'd be > interested to know if it fixes your problem. Yes, it certainly seems to. Now running with this patch and 4GB active, I've transferred about 15GB with no problem so far. It usually oopses after a GB or two. I guess it's not an ideal solution, architecturally speaking, but it's a good deal better than an unstable driver. It may cause a "bounce" (i.e. data is copied to another buffer in lower memory) when a skb is allocated in high memory. Furthermore - at least on AMD systems - it should be possible to use the IOMMU to remap the memory to a bus address < 4GB. Xiong can you comment on this issue? To recap: users are seeing hard locks when L1 driver does a DMA to/from a high memory area (physical address > 4GB). Limiting DMA to the lower 4GB with: pci_set_dma_mask(pdev, DMA_32BIT_MASK); cures the issue. Does L1 have any know problem decoding 64 addresses? Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] [BUG] Oops with KVM-27
On 6/10/07, Avi Kivity <[EMAIL PROTECTED]> wrote: Luca wrote: > On 6/5/07, Avi Kivity <[EMAIL PROTECTED]> wrote: >> Luca Tettamanti wrote: >> > Il Mon, Jun 04, 2007 at 11:51:10PM +0300, Avi Kivity ha scritto: >> > >> >>> While doing repeated tests with the installer I ran into another >> >>> (unrelated) problem. Sometimes the guest kernel hangs at boot at: >> >>> >> >>> NET: Registered protocol family 2 >> >>> >> >>> with any kind of networking options (except for -net none, which >> works). >> >>> With -no-kvm it boots with any networking option. >> >>> >> >>> >> >>> >> >> Can you try to pin the guest on a single core with taskset: >> >> >> >>taskset 1 qemu ... >> >> >> > >> > Doesn't help. What works is 'nolapic', i.e. disabling the local >> APIC on >> > the guest kernel. >> > I've also tried disabling TSC (notsc) and forcing PIT as the >> clocksource >> > (clocksouce=pit clock=pit); neither of them helped. >> > >> > >> >> Is this a regression relative to a previous kvm version? > > Hello, > sorry for the delay, I was having troubles compiling older KVMs with a > recent kernel... > The last version that works is kvm-21; starting from kvm-22 the VM > hangs during network initialization (now always, but pretty often). > This only occurs when the guest is Fedora7 setup ISO. The regular boot > (i.e. from the hd) seems unaffected. I've managed to reproduce this on kvm-21 (it takes many boots for this to happen, but it does eventually). Hum, any clue on the cause? Should I test older versions? Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] [BUG] Oops with KVM-27
On 6/11/07, Avi Kivity <[EMAIL PROTECTED]> wrote: Luca wrote: >> >> I've managed to reproduce this on kvm-21 (it takes many boots for this >> to happen, but it does eventually). > > Hum, any clue on the cause? From what I've seen, it's the new Linux clocksource code. Actually I tried forcing the PIT (and any other combination of tsc,acpi_pm,jiffies) as the clocksource, without success. > Should I test older versions? They're unlikely to be better. Instead, it would be best to see what the guest is doing. I suggest downloading the source rpm for the kernel, building it, and sprinkling printk()s until we know exactly what source the guest is executing at the time of the hang. Ok, will do. Meanwhile I discovered that the kernel on the boot cd (the one that hangs) is compiled for i586, while the one installed on disk is for i686 (this one works). i686 has this options enabled: +CONFIG_X86_GOOD_APIC=y +CONFIG_X86_USE_PPRO_CHECKSUM=y +CONFIG_X86_TSC=y but disabling tsc on the command line doesn't make any difference. Is it possible that KVM is choking on some instruction not used by the i686 kernel? Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] [BUG] Oops with KVM-27
On 6/15/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
Il Fri, Jun 15, 2007 at 12:53:24AM +0200, Luca Tettamanti ha scritto:
> Il Thu, Jun 14, 2007 at 11:26:29AM +0300, Avi Kivity ha scritto:
> > Luca Tettamanti wrote:
> > >With GOOD_APIC apic_read_around is a nop, while apic_write_around is a
> > >normal write. With !GOOD_APIC apic_write_around writes to the APIC reg
> > >using xchg. With !GOOD_APIC and this patch:
> > >
> > >--- include/asm-i386/apic.h~ 2007-04-26 05:08:32.0 +0200
> > >+++ include/asm-i386/apic.h2007-06-13 22:35:00.0 +0200
> > >@@ -56,7 +56,8 @@
> > > static __inline fastcall void native_apic_write_atomic(unsigned long reg,
> > > unsigned long v)
> > > {
> > >- xchg((volatile unsigned long *)(APIC_BASE+reg), v);
> > >+//xchg((volatile unsigned long *)(APIC_BASE+reg), v);
> > >+ *((volatile unsigned long *)(APIC_BASE+reg)) = v;
> > > }
> > >
> > > static __inline fastcall unsigned long native_apic_read(unsigned long reg)
> > >
> > >The kernel boots fine.
> > >
> >
> > Looking at the xchg emulation code, it seems fine, but clearly it
> > isn't.
>
> Btw, I've put a printk in x86_emulate.c, where it prepares the operands
> for the xchg operations: all the write_atomic are hitting this point,
> so the write is lost somewhere in cmpxchg_emulated->write_emulated.
Got it!
The emulator skips the writeback if the old value is unchanged, so the
apic doesn't see the write.
Forcing the writeback:
- if ((d & Mov) || (dst.orig_val != dst.val)) {
- if ((d & Mov) || (dst.orig_val != dst.val) || isxchg) {
seems to fix the issue :D I'm not sure that fix is correct though.
After a bit of thinking: it's correct but removes an optimization;
furthermore it may miss other instructions that write to memory mapped
areas.
A more proper fix should be "force the writeback if dst.ptr is in some
kind of mmio area".
Ok, enough of reply-to-self. I'll go to sleep...
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Enable legacy support for serial ports when SERIAL_8250_PNP is disabled
On 7/9/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote: On Saturday 07 July 2007 05:33:00 pm Luca Tettamanti wrote: > your patch: > > commit 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26 > Author: Bjorn Helgaas <[EMAIL PROTECTED]> > Date: Tue May 8 00:36:07 2007 -0700 > > x86, serial: convert legacy COM ports to platform devices > > disables probing using legacy code in favour of ACPI/PNP to avoid double > discovery. > > However if SERIAL_8250_PNP is not enabled the user is left without > serial ports (been there, done that - my kernel config suddenly wasn't > working anymore). So: Yes, that's true. Kconfig should automatically turn on SERIAL_8250_PNP if PNP and SERIAL_8250 are selected, but it does give you a choice if you have EMBEDDED set. So I guess you must have this: CONFIG_EMBEDDED=y CONFIG_PNP=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_PNP=n Why do you want PNP support, but not 8250_PNP support? That's a good question :-) IIRC the serial PNP code used to mess up the mode of the port on my laptop, making it useless for debugging the boot. Bug was fixed long ago, but I didn't re-enabled that option. If you turn off PNP completely, you will have "pnp_platform_devices == 0", and the existing code will do what you need. Well for me it's a non-issue, I'm able to "work-around" it in many ways. My point is that a configuration that used to work and is still valid suddenly doesn't work anymore. I missed the dependacy on CONFIG_EMBEDDED though, so feel free to ignore the patch ;-) Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Enable legacy support for serial ports when SERIAL_8250_PNP is disabled
On 7/9/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote: On Monday 09 July 2007 11:30:59 am Luca wrote: > On 7/9/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote: > > If you turn off > > PNP completely, you will have "pnp_platform_devices == 0", and the > > existing code will do what you need. > > Well for me it's a non-issue, I'm able to "work-around" it in many > ways. My point is that a configuration that used to work and is still > valid suddenly doesn't work anymore. You're right about that, and it is a legitimate issue. But given the fact that (PNP && !SERIAL_8250_PNP) should be relatively unusual, my opinion is that it's not worth extra ifdefs in legacy_serial.c. If you have to use any workarounds like "legacy_serial.force", I think that's a bug, and I'll fix it. Ok, I double-checked: the serial port is usable during boot with PNP enabled, so no problem with dropping my patch. Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] [PATCH 2/2] KVM: Use the scheduler preemption hooks to make kvm preemptible
On 7/11/07, Avi Kivity <[EMAIL PROTECTED]> wrote: Current kvm disables preemption while the new virtualization registers are in use. This of course is not very good for latency sensitive workloads (one use of virtualization is to offload user interface and other latency insensitive stuff to a container, so that it is easier to analyze the remaining workload). This patch re-enables preemption for kvm; preemption is now only disabled when switching the registers in and out, and during the switch to guest mode and back. [...] diff --git a/drivers/kvm/Kconfig b/drivers/kvm/Kconfig index 33fa28a..92644b5 100644 --- a/drivers/kvm/Kconfig +++ b/drivers/kvm/Kconfig @@ -10,7 +10,7 @@ if VIRTUALIZATION config KVM tristate "Kernel-based Virtual Machine (KVM) support" - depends on X86 && EXPERIMENTAL + depends on X86 && EXPERIMENTAL && PREEMPT_HOOKS depends on X86_CMPXCHG64 || 64BIT select PREEMPT_HOOKS maybe? Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] [ANNOUNCE] kvm-30 release
On 7/19/07, Avi Kivity <[EMAIL PROTECTED]> wrote: Changes from kvm-29: [...] - revert ide enable changes that caused an I/O regression Not really. Dave is seeing the regression when IDE ports are enabled and KVM BIOS does enable them. Reverting the patch allows running another BIOS (e.g. QEMU BIOS) which doesn't enable the port though. Luca As a side note: I'm currently busy with ICWE and tomorrow I'll be leaving for Rome so I cannot do further tests. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeonfb and X800 cards
On 5/17/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: On Wed, 2007-05-16 at 21:47 -0400, Daniel Drake wrote: > Hi, > > Did anything happen to the patch titled "radeonfb: add support for newer > cards"? > http://lwn.net/Articles/215965/ > > Jimmy at http://bugs.gentoo.org/174063 has extended upon this with some > further fixes based on code the in X11 driver. The patches are on the > bug report. > > Ben, where can the most up-to-date radeonfb code be found? upstream. I haven't released anything else so far. Does the patch still apply ? Nope, but I still rebase against current kernel for my own use. I can send an up to date patch when I get home this evening. Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On 5/17/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote: Il Tue, May 15, 2007 at 11:43:44AM +1000, Herbert Xu ha scritto: > On Mon, May 14, 2007 at 07:38:23PM +0200, Luca Tettamanti wrote: > > I'm running git 705962cc (which is a commit after -rc1) and I still see > > the OOPS on boot. The patch above is already applied though. Note that > > I'm using the SLAB allocator: > > > > CONFIG_SLAB=y > > # CONFIG_SLUB is not set > > # CONFIG_SLOB is not set > > > > > > Ending clean XFS mount for filesystem: dm-4 > > BUG: unable to handle kernel paging request at virtual address 6b6b6ceb > > Please send me your .config file. It seems that build system was confused... I've checked the timestamps of *.o files and make didn't rebuild anything, but rebuilding after a 'make clean' did "fix" the problem. Sorry for the noise... Ok, wait: it's still there. It's just not 100% reproducible, sometimes the system boots fine. So it either crashes on boot or it runs fine for hours. Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kvm-devel] [BUG] Oops with KVM-27
On 6/5/07, Avi Kivity <[EMAIL PROTECTED]> wrote: Luca Tettamanti wrote: > Il Mon, Jun 04, 2007 at 11:51:10PM +0300, Avi Kivity ha scritto: > >>> While doing repeated tests with the installer I ran into another >>> (unrelated) problem. Sometimes the guest kernel hangs at boot at: >>> >>> NET: Registered protocol family 2 >>> >>> with any kind of networking options (except for -net none, which works). >>> With -no-kvm it boots with any networking option. >>> >>> >>> >> Can you try to pin the guest on a single core with taskset: >> >>taskset 1 qemu ... >> > > Doesn't help. What works is 'nolapic', i.e. disabling the local APIC on > the guest kernel. > I've also tried disabling TSC (notsc) and forcing PIT as the clocksource > (clocksouce=pit clock=pit); neither of them helped. > > Is this a regression relative to a previous kvm version? Hello, sorry for the delay, I was having troubles compiling older KVMs with a recent kernel... The last version that works is kvm-21; starting from kvm-22 the VM hangs during network initialization (now always, but pretty often). This only occurs when the guest is Fedora7 setup ISO. The regular boot (i.e. from the hd) seems unaffected. Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] atl1: disable 64bit DMA
On 6/26/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: Jay Cliburn wrote: > On Mon, 25 Jun 2007 17:57:20 -0400 > Chris Snook <[EMAIL PROTECTED]> wrote: > >> Jay L. T. Cornwall wrote: >>> Chris Snook wrote: >>> >>>> What boards have we seen this on? It's quite possible this is: >>> I can reproduce on an Asus P5K with a Core 2 Duo E6600. >>> >>> lspci identifies the controller as: >>> 02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit >>> Ethernet Adapter (rev b0) >>> >>> dmesg notes the PCI-DMA mapping implementation: >>> PCI-DMA: Using software bounce buffering for IO (SWIOTLB) >>> >> I had a hunch this was on Intel. I'd rather just disable this when >> swiotlb is in use, unless we get more complaints. It's probably >> ultimately a BIOS quirk anyway. > > So far we have reports from both camps: > > Asus M2N8-VMX (AM2): 1 report of lockup > http://sourceforge.net/mailarchive/forum.php?thread_name=46780384.063603.26165%40m12-15.163.com&forum_name=atl1-devel > > Asus P5K (LGA775):2 reports of lockups > http://sourceforge.net/mailarchive/forum.php?thread_name=467E7E34.4010603%40gmail.com&forum_name=atl1-devel > http://lkml.org/lkml/2007/6/25/107 > > The common denominator in these reports is 4GB RAM. Although its possible this device doesn't really support 64-bit, it's more likely that this is a platform problem of some sort, or a driver bug of some sort. In the driver, maybe it has a problem when you -cross- a 4GB boundary, which is not uncommon. I don't follow you :| What kind "common" mistakes should we check for in the driver? Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On 5/18/07, Herbert Xu <[EMAIL PROTECTED]> wrote: On Tue, May 15, 2007 at 08:52:12PM +0200, Luca Tettamanti wrote: > > CONFIG_CRYPTO_ALGAPI=m Are you sure you're actually running 2.6.22-rc1? Due to a bug in the padlock patch present in 2.6.22-rc1 it shouldn't be possible to select ALGAPI as a module. Well, pretty sure. The OOPS says 2.6.22-rc1-libata-g705962cc-dirty, git agrees and I've done a full rebuild. The .config is generated using 'make oldconfig' using the 2.6.21 as baseline, maybe ALGAPI is coming from there? Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [RFC] ACPI based hwmon driver for ASUS
On 5/21/07, Rudolf Marek <[EMAIL PROTECTED]> wrote: ATK0110 ATK0110:00: atk_enumerate_fan: invalid fan count 3 (should be 5) ATK0110: probe of ATK0110:00 failed with error -22 Ok, the FAN package contains 5 items, but the enumerator only advertises the first 3. I guess that the other 2 (chipset fan and chassis2 fan) are not usable? Are the connectors for those two fans on your motherboard? Do you get any reading from them? Plus: your ACPI code uses the full "magic number" (first item in the package) to demux the reading, while my board masks the upper 2 bytes; I need to change the driver. Will send another iteration. Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] arm64: dts: allwinner: a64: Add lradc node
On May 20, 2019 1:07:42 PM GMT+02:00, Maxime Ripard
wrote:
>Hi!
>
>On Sat, May 18, 2019 at 07:09:30PM +0200, Luca Weiss wrote:
>> Add a node describing the KEYADC on the A64.
>>
>> Signed-off-by: Luca Weiss
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index 7734f70e1057..dc1bf8c1afb5 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -704,6 +704,13 @@
>> status = "disabled";
>> };
>>
>> +lradc: lradc@1c21800 {
>> +compatible = "allwinner,sun4i-a10-lradc-keys";
>> +reg = <0x01c21800 0x100>;
>> +interrupts = ;
>> +status = "disabled";
>> +};
>> +
>
>The controller is pretty different on the A64 compared to the A10. The
>A10 has two channels for example, while the A64 has only one.
>
>It looks like the one in the A83t though, so you can use that
>compatible instead.
>
>Maxime
>
>--
>Maxime Ripard, Bootlin
>Embedded Linux and Kernel engineering
>https://bootlin.com
Hi,
Looking at the patch for the A83t, the only difference is that it uses a 3/4
instead of a 2/3 voltage divider, nothing is changed with the channels. But I'm
also not sure which one (or a different one) is used from looking at the "A64
User Manual".
Thanks, Luca
Re: [PATCH] arm64: dts: allwinner: a64: Add lradc node
On May 21, 2019 3:09:55 PM GMT+02:00, Maxime Ripard
wrote:
>On Tue, May 21, 2019 at 08:43:45AM +0200, l...@z3ntu.xyz wrote:
>> On May 20, 2019 1:07:42 PM GMT+02:00, Maxime Ripard
> wrote:
>> >On Sat, May 18, 2019 at 07:09:30PM +0200, Luca Weiss wrote:
>> >> Add a node describing the KEYADC on the A64.
>> >>
>> >> Signed-off-by: Luca Weiss
>> >> ---
>> >> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 7 +++
>> >> 1 file changed, 7 insertions(+)
>> >>
>> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> index 7734f70e1057..dc1bf8c1afb5 100644
>> >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> >> @@ -704,6 +704,13 @@
>> >> status = "disabled";
>> >> };
>> >>
>> >> + lradc: lradc@1c21800 {
>> >> + compatible = "allwinner,sun4i-a10-lradc-keys";
>> >> + reg = <0x01c21800 0x100>;
>> >> + interrupts = ;
>> >> + status = "disabled";
>> >> + };
>> >> +
>> >
>> >The controller is pretty different on the A64 compared to the A10.
>The
>> >A10 has two channels for example, while the A64 has only one.
>> >
>> >It looks like the one in the A83t though, so you can use that
>> >compatible instead.
>>
>> Looking at the patch for the A83t, the only difference is that it
>> uses a 3/4 instead of a 2/3 voltage divider, nothing is changed with
>> the channels.
>
>I guess you can reuse the A83t compatible here then, and a more
>specific a64 compatible in case we ever need to fix this.
>
>> But I'm also not sure which one (or a different one)
>> is used from looking at the "A64 User Manual".
>
>I'm sorry, what are you referring to with "one" in that sentence?
>
>Maxime
>
>--
>Maxime Ripard, Bootlin
>Embedded Linux and Kernel engineering
>https://bootlin.com
Hi,
Sorry, I meant I didn't find anything in the A64 user manual whether a 3/4 or a
2/3 voltage divider (or one with different values) is used on the A64.
Luca
Re: [PATCH 2/3] drivers/media/video/sn9c102/sn9c102_core.c Fix Unlikely(x) == y
It's okay, thanks.
Reviewed-by: Luca Risolia <[EMAIL PROTECTED]>
---
On Saturday 16 February 2008 17:12:26 Roel Kluin wrote:
> The patch below was not yet tested. If it's incorrect, please comment.
> ---
> Fix Unlikely(x) == y
>
> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/media/video/sn9c102/sn9c102_core.c
> b/drivers/media/video/sn9c102/sn9c102_core.c index c40ba3a..66313b1 100644
> --- a/drivers/media/video/sn9c102/sn9c102_core.c
> +++ b/drivers/media/video/sn9c102/sn9c102_core.c
> @@ -528,7 +528,7 @@ sn9c102_find_sof_header(struct sn9c102_device* cam,
> void* mem, size_t len)
>
> /* Search for the SOF marker (fixed part) in the header */
> for (j = 0, b=cam->sof.bytesread; j+b < sizeof(marker); j++) {
> - if (unlikely(i+j) == len)
> + if (unlikely(i+j == len))
> return NULL;
> if (*(m+i+j) == marker[cam->sof.bytesread]) {
> cam->sof.header[cam->sof.bytesread] = *(m+i+j);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: Android: logger: module_exit implementation
Created the module_exit for the android logger so that
it can be loaded and unloaded as a module. Fixed
module_init and some other minor issues.
Signed-off-by: Luca Clementi
Cc: Greg Kroah-Hartman
Cc: Brian Swetland
---
drivers/staging/android/logger.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index 1d5ed47..050be01 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -676,4 +676,32 @@ static int __init logger_init(void)
out:
return ret;
}
-device_initcall(logger_init);
+
+static void __exit logger_exit(void)
+{
+ struct logger_log *current_log, *next_log;
+
+ list_for_each_entry_safe(current_log, next_log, &log_list, logs) {
+ /* we have to delete all the entry inside log_list */
+ ret = misc_deregister(¤t_log->misc);
+ if (unlikely(ret)) {
+ pr_err("failed to deregister misc device for log
'%s'!\n",
+ current_log->misc.name);
+ }
+ pr_info("removed loggger '%s'\n", current_log->misc.name);
+ vfree(current_log->buffer);
+ kfree(current_log->misc.name);
+ kfree(current_log);
+ }
+
+ return;
+}
+
+
+module_init(logger_init);
+module_exit(logger_exit);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Brian Swetland, ");
+MODULE_DESCRIPTION("Android Logger");
+
+
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: Android: logger: module_exit implementationg
On Fri, Nov 2, 2012 at 11:29 AM, Greg Kroah-Hartman
wrote:
> On Thu, Nov 01, 2012 at 11:15:52PM -0700, Luca Clementi wrote:
>> Created the module_exit for the android logger so that
>> it can be loaded and unloaded as a module. Fixed
>> module_init and some other minor issues.
>
> That's doing more than one thing here at once, care to break it up?
> Yeah, I know it seems funny for such a small patch, but it helps.
>
Sure, no problem.
> Also, now that you've added this, the logger driver still can't be built
> as a module, as the build system isn't changed to let that happen,
> right?
The Kconfig declares this as a module, although since there is not a
module_exit
it was possible to compile it as a module and load it but then it was
not possible
to rmmod it.
drivers/staging/android/Kconfig:
config ANDROID_LOGGER
tristate "Android log driver"
default n
So the alternative is to put the ANDROID_LOGGER to bool.
> Also, why do you want to build this as a module?
Since the original developer declared it as module I thought that was
the final goal,
but it was left unfinished only for time reason.
>> Signed-off-by: Luca Clementi
>> Cc: Greg Kroah-Hartman
>> Cc: Brian Swetland
>> ---
>> drivers/staging/android/logger.c | 30 +-
>> 1 file changed, 29 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/android/logger.c
>> b/drivers/staging/android/logger.c
>> index 1d5ed47..050be01 100644
>> --- a/drivers/staging/android/logger.c
>> +++ b/drivers/staging/android/logger.c
>> @@ -676,4 +676,32 @@ static int __init logger_init(void)
>> out:
>> return ret;
>> }
>> -device_initcall(logger_init);
>> +
>> +static void __exit logger_exit(void)
>> +{
>> + struct logger_log *current_log, *next_log;
>> +
>> + list_for_each_entry_safe(current_log, next_log, &log_list, logs) {
>> + /* we have to delete all the entry inside log_list */
>> + ret = misc_deregister(¤t_log->misc);
>> + if (unlikely(ret)) {
>> + pr_err("failed to deregister misc device for log
>> '%s'!\n",
>> + current_log->misc.name);
>> + }
>> + pr_info("removed loggger '%s'\n", current_log->misc.name);
>
> Is that message really needed?
I'll remove it.
>> + vfree(current_log->buffer);
>> + kfree(current_log->misc.name);
>> + kfree(current_log);
>> + }
>> +
>> + return;
>> +}
>> +
>> +
>> +module_init(logger_init);
>
> Is module_init() the same "level" as device_initcall()? Did you test
> this out in an Android system?
Honestly I haven't tested it on Android, but in include/linux/init.h there is:
#define module_init(x) __initcall(x);
...
#define __initcall(fn) device_initcall(fn)
Which lead me to think that there is not much difference between the two call.
>> +module_exit(logger_exit);
>> +MODULE_LICENSE("GPL");
>> +MODULE_AUTHOR("Brian Swetland, ");
>> +MODULE_DESCRIPTION("Android Logger");
>> +
>> +
>
> What's with the unneeded trailing empty lines?
>
I can fix them and change the author as per request of Brian.
Should I make the requested fixes or do you prefer to change the
Kconfig to a bool?
Thanks for the comment,
Luca
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
Hi, On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote: > On 10/01/2013 11:53 AM, Roger Quadros wrote: > > On 10/01/2013 12:49 PM, Roger Quadros wrote: > >> Hi Arend, > >> > >> On 10/01/2013 11:05 AM, Arend van Spriel wrote: > >>> On 07/19/2013 12:57 PM, Arend van Spriel wrote: > >>>> On 07/19/2013 12:49 PM, Roger Quadros wrote: > >>>>> On 07/19/2013 01:36 PM, Arend van Spriel wrote: > >>>>>> On 07/18/2013 10:59 AM, Tony Lindgren wrote: > >>>>>>> Then for the SDIO with device tree, take a look at the following > >>>>>>> patches: > >>>>>>> > >>>>>>> [PATCH 0/3] WLAN support for omap4 when booted with devicetree > >>>>>>> http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# > >>>>>> > >>>>>> I have been looking at the pandaboard patch in the series above and I > >>>>>> do have a question. Among other things the patch adds these dt entries. > >>>>>> > >>>>>> +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | > >>>>>> MODE0 */ > >>>>>> +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | > >>>>>> MODE0 */ > >>>>>> > >>>>>> If I look at the similar names in the deceased board-omap4panda.c: > >>>>>> > >>>>>> board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | > >>>>>> OMAP_PIN_INPUT_PULLUP), > >>>>>> board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | > >>>>>> OMAP_PIN_INPUT_PULLUP), > >>>>>> > >>>>>> and in mux44xx.h: > >>>>>> > >>>>>> mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 > >>>>>> mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a > >>>>>> > >>>>>> So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is > >>>>>> probably an explanation to it and it would help my understanding to > >>>>>> know where this difference comes from. Hope you can help me out here. > >>>>>> > >>>>> > >>>>> If you see omap4.dtsi, omap4_pmx_core starts at register address > >>>>> 0x4a100040. > >>>>> > >>>>> So, you need to subtract 0x40 from the offsets defined in mux44xx.h > >>>>> for pmx_core registers. > >>>> > >>>> That was what I was looking for. Thanks! > >>> > >>> Hi Roger, > >>> > >>> It has been a while, but I would like to pickup this thread. We have a > >>> couple of pandaboards used as test setup. These have an SDIO adapter > >>> hooked up to expansion connector A using MMC2. I have attached the patch > >>> file (just ignore platform_data stuff). Now on one board it works, but > >>> not for the other. I suspect a board issue so listing the two types that > >>> we use: > >>> > >>> PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works > >>> PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope > >>> > >>> Any hints for me. > >> > >> Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you > >> isolate > >> it from your external SDIO adapter? > > On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi > thing). > > > > > OK, just realized that the expansion connector uses different pads for > > MMC2. However, you still > > need to make sure that the other pins (connected to on board WLAN chip) are > > not muxed as MMC2. > > I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I > am not mistaken(?). Attached are the dmesg logs of the two boards. I sent 2 patch series to add DT support for the on-board WLAN, but they were not applied, since there were some comments that required changes. I really don't have the time to revisit them now that I'm not with TI anymore, so I'm hoping someone else will pick them up at some point. FWIW, my patches were working with PandaBoardES rev B1, which was also OMAP4460 ES1.1. It worked fine for me, *except* that sometimes for some unknown reason the SDIO MMC connected to WiLink didn't get probed (as it appears to be the case on your dmesg-4460.txt). Most weirdly, it seems that booting the board with a non-DT kernel and then booting back to the DT kernel seemed to help and the problem was gone for many reboots, until it happened again. I never figure out why this was happening, though. :( -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On Wed, 2013-10-02 at 12:20 +0200, Arend van Spriel wrote: > On 10/01/2013 01:29 PM, Luca Coelho wrote: > > Hi, > > > > On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote: > >> On 10/01/2013 11:53 AM, Roger Quadros wrote: > >>> On 10/01/2013 12:49 PM, Roger Quadros wrote: > >>>> Hi Arend, > >>>> > >>>> On 10/01/2013 11:05 AM, Arend van Spriel wrote: > >>>>> On 07/19/2013 12:57 PM, Arend van Spriel wrote: > >>>>>> On 07/19/2013 12:49 PM, Roger Quadros wrote: > >>>>>>> On 07/19/2013 01:36 PM, Arend van Spriel wrote: > >>>>>>>> On 07/18/2013 10:59 AM, Tony Lindgren wrote: > >>>>>>>>> Then for the SDIO with device tree, take a look at the following > >>>>>>>>> patches: > >>>>>>>>> > >>>>>>>>> [PATCH 0/3] WLAN support for omap4 when booted with devicetree > >>>>>>>>> http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# > >>>>>>>> > >>>>>>>> I have been looking at the pandaboard patch in the series above and I > >>>>>>>> do have a question. Among other things the patch adds these dt > >>>>>>>> entries. > >>>>>>>> > >>>>>>>> +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | > >>>>>>>> MODE0 */ > >>>>>>>> +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | > >>>>>>>> MODE0 */ > >>>>>>>> > >>>>>>>> If I look at the similar names in the deceased board-omap4panda.c: > >>>>>>>> > >>>>>>>> board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | > >>>>>>>> OMAP_PIN_INPUT_PULLUP), > >>>>>>>> board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | > >>>>>>>> OMAP_PIN_INPUT_PULLUP), > >>>>>>>> > >>>>>>>> and in mux44xx.h: > >>>>>>>> > >>>>>>>> mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 > >>>>>>>> mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a > >>>>>>>> > >>>>>>>> So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is > >>>>>>>> probably an explanation to it and it would help my understanding to > >>>>>>>> know where this difference comes from. Hope you can help me out here. > >>>>>>>> > >>>>>>> > >>>>>>> If you see omap4.dtsi, omap4_pmx_core starts at register address > >>>>>>> 0x4a100040. > >>>>>>> > >>>>>>> So, you need to subtract 0x40 from the offsets defined in mux44xx.h > >>>>>>> for pmx_core registers. > >>>>>> > >>>>>> That was what I was looking for. Thanks! > >>>>> > >>>>> Hi Roger, > >>>>> > >>>>> It has been a while, but I would like to pickup this thread. We have a > >>>>> couple of pandaboards used as test setup. These have an SDIO adapter > >>>>> hooked up to expansion connector A using MMC2. I have attached the > >>>>> patch file (just ignore platform_data stuff). Now on one board it > >>>>> works, but not for the other. I suspect a board issue so listing the > >>>>> two types that we use: > >>>>> > >>>>> PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works > >>>>> PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope > >>>>> > >>>>> Any hints for me. > >>>> > >>>> Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do > >>>> you isolate > >>>> it from your external SDIO adapter? > >> > >> On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi > >> thing). > >> > >>> > >>> OK, just realized that the expansion connector uses different pads for > >>> MMC2. However, you still > >>> need to make sure that the other pins (connected to on board WLAN chip) > >>> are not muxed as MMC2. > >> > >> I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I > >> am not mistaken(?). Attached are the dmesg logs of the two boards. > > > > I sent 2 patch series to add DT support for the on-board WLAN, but they > > were not applied, since there were some comments that required changes. > > I really don't have the time to revisit them now that I'm not with TI > > anymore, so I'm hoping someone else will pick them up at some point. > > I found this one in my email archive: > > [PATCH v2 0/4] ARM: dts: add WiLink support to panda and omap4-sdp > > Guess that is what you are referring to, right? Yes, that one and also this (which implements DT in the driver itself): [PATCH v4 0/8] wilink: add device tree support http://mid.gmane.org/1375189476-21557-1-git-send-email-coe...@ti.com -- Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] firmware: wl1251 firmware binary
Hi Felipe, On Wed, 2013-10-02 at 07:55 -0500, Felipe Balbi wrote: > Hi, > > here's a pull request for wl4 firmware. I'll send a patch for wl1251 > driver updating firmware load path. > > The following changes since commit b8ac7c7e27dcd13fa3c843aaf62457e9c57ea4db: > > linux-firmware: Add Brocade FC/FCOE Adapter firmware files (2013-09-30 > 04:53:32 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/linux-firmware.git > wilink4 > > for you to fetch changes up to d726804dbc8dad88587b6be17716714cd91ed86c: > > ti-connectivity: add wl1251 firmware and license (2013-10-02 06:55:39 -0500) > > > Felipe Balbi (1): > ti-connectivity: add wl1251 firmware and license > > LICENCE.wl1251 | 59 > + > WHENCE | 18 + > ti-connectivity/wl1251-fw.bin | Bin 0 -> 194180 bytes > ti-connectivity/wl1251-nvs.bin | Bin 0 -> 752 bytes > 4 files changed, 77 insertions(+) > create mode 100644 LICENCE.wl1251 > create mode 100644 ti-connectivity/wl1251-fw.bin > create mode 100644 ti-connectivity/wl1251-nvs.bin Since you didn't send v2 of the patch, you could have used the -p option with git request-pull so we could see the changes you made here... -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: wireless: wl1251: update firmware path
On Wed, 2013-10-02 at 08:00 -0500, Felipe Balbi wrote: > TI firmwares are located under ti-connectivity > directory. Update path to make sure driver can > find and load firmware blob. > > Signed-off-by: Felipe Balbi > --- Applied, thanks Felipe! -- Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] firmware: wl1251 firmware binary
On Fri, 2013-10-04 at 10:32 -0500, Felipe Balbi wrote:
> diff --git a/LICENCE.wl1251 b/LICENCE.wl1251
> new file mode 100644
> index 000..bd0f5f1
> --- /dev/null
> +++ b/LICENCE.wl1251
> @@ -0,0 +1,59 @@
> +Copyright (c) 2000 – 2013 Texas Instruments Incorporated
> +
> +All rights reserved not granted herein.
> +
> +Limited License.
> +
> +Texas Instruments Incorporated grants a world-wide, royalty-free,
> non-exclusive
> +license under copyrights and patents it now or hereafter owns or controls to
> +make, have made, use, import, offer to sell and sell ("Utilize") this
> software
> +subject to the terms herein. With respect to the foregoing patent license,
> +such license is granted solely to the extent that any such patent is
> necessary
> +to Utilize the software alone. The patent license shall not apply to any
> +combinations which include this software, other than combinations with
> devices
> +manufactured by or for TI (“TI Devices”). No hardware patent is licensed
> +hereunder.
> +
> +Redistributions must preserve existing copyright notices and reproduce this
> +license (including the above copyright notice and the disclaimer and (if
> +applicable) source code license limitations below) in the documentation
> and/or
> +other materials provided with the distribution
> +
> +Redistribution and use in binary form, without modification, are permitted
> +provided that the following conditions are met:
> +
> +*No reverse engineering, decompilation, or disassembly of this software
> + is permitted with respect to any software provided in binary form.
> +
> +*any redistribution and use are licensed by TI for use only with TI
> + Devices.
> +
> +*Nothing shall obligate TI to provide you with source code for the
> + software licensed and provided to you in object code.
> +
> +If software source code is provided to you, modification and redistribution
> of
> +the source code are permitted provided that the following conditions are met:
> +
> +*any redistribution and use of the source code, including any resulting
> + derivative works, are licensed by TI for use only with TI Devices.
> +
> +*any redistribution and use of any object code compiled from the source
> + code and any resulting derivative works, are licensed by TI for use
> + only with TI Devices.
> +
> +Neither the name of Texas Instruments Incorporated nor the names of its
> +suppliers may be used to endorse or promote products derived from this
> software
> +without specific prior written permission.
> +
> +DISCLAIMER.
> +
> +THIS SOFTWARE IS PROVIDED BY TI AND TI’S LICENSORS "AS IS" AND ANY EXPRESS OR
> +IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
> +EVENT SHALL TI AND TI’S LICENSORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
> OR
> +PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
> +LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
> NEGLIGENCE
> +OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
> +ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> diff --git a/WHENCE b/WHENCE
> index aac3ba9..3a35670 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -1712,6 +1712,24 @@ Licence: Redistributable. See
> LICENCE.tda7706-firmware.txt for details.
>
> --
>
> +Driver: wl1251 - Texas Instruments 802.11 WLAN driver for WiLink4 chips
> +
> +File: ti-connectivity/wl1251-fw.bin
> +Version: 4.0.4.3.7
> +
> +File: ti-connectivity/wl1251-nvs.bin
> +
> +Licence: See LICENCE.wl1251 for details.
> +
> +The published NVS files are for testing only. Every device needs to
> +have a unique NVS which is properly calibrated for best results.
> +
> +The driver expects to find the firmwares under a ti-connectivity
> subdirectory.
> +So if your system looks for firmwares in /lib/firmware, the firmwares for
> +wl12xx chips must be located in /lib/firmware/ti-connectivity/.
> +
> +--
> +
> Driver: wl12xx - Texas Instruments 802.11 WLAN driver for WiLink6/7 chips
>
> File: ti-connectivity/wl1271-fw.bin
> diff --git a/ti-connectivity/wl1251-fw.bin b/ti-connectivity/wl1251-fw.bin
> new file mode 100644
> index 000..f89c983
> Binary files /dev/null and b/ti-connectivity/wl1251-fw.bin differ
> diff --git a/
Re: [PATCH] ti-connectivity: add wl1251 firmware and license
Hi dude, Great, this is cool! Finally! :) A few comments... On Tue, 2013-09-24 at 09:44 -0500, Felipe Balbi wrote: > It's way overdue that we send these firmware > blobs upstream. Thanks for everybody involved > in getting this sorted out. > > Cc: Luciano Coelho > Cc: Pavel Machek > Signed-off-by: Felipe Balbi > --- The commit message could be a bit more descriptive rather than narrative? > ti-connectivity/license-wl1251.txt | 59 > + The license file should be in the root, together with the other licenses and called LICENCE.wl1251 (note the en-GB spelling). Also, this license is *very* similar to the one for WiLink6/7/8 (LICENCE.ti-connectivity), except for some very minor things and the formatting. Couldn't the same one be used, for the sake of simplicity and consistency? > ti-connectivity/wl1251-fw.bin | Bin 0 -> 194180 bytes > ti-connectivity/wl1251-nvs.bin | Bin 0 -> 752 bytes > 3 files changed, 59 insertions(+) > create mode 100644 ti-connectivity/license-wl1251.txt > create mode 100644 ti-connectivity/wl1251-fw.bin > create mode 100644 ti-connectivity/wl1251-nvs.bin When sending big binary blobs, it's generally better to send pull requests instead of patches. If you add the -p option when calling git pull-request, the text will include all the readable parts but will omit the binary stuff. Thank you very much for following up on this! -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ti-connectivity: add wl1251 firmware and license
On Wed, 2013-09-25 at 14:04 +0300, Luca Coelho wrote: > Hi dude, > > Great, this is cool! Finally! :) > > A few comments... > > > On Tue, 2013-09-24 at 09:44 -0500, Felipe Balbi wrote: > > It's way overdue that we send these firmware > > blobs upstream. Thanks for everybody involved > > in getting this sorted out. > > > > Cc: Luciano Coelho > > Cc: Pavel Machek > > Signed-off-by: Felipe Balbi > > --- > > The commit message could be a bit more descriptive rather than > narrative? > > > > ti-connectivity/license-wl1251.txt | 59 > > + > > The license file should be in the root, together with the other licenses > and called LICENCE.wl1251 (note the en-GB spelling). Also, this license > is *very* similar to the one for WiLink6/7/8 (LICENCE.ti-connectivity), > except for some very minor things and the formatting. Couldn't the same > one be used, for the sake of simplicity and consistency? > > > > ti-connectivity/wl1251-fw.bin | Bin 0 -> 194180 bytes > > ti-connectivity/wl1251-nvs.bin | Bin 0 -> 752 bytes > > 3 files changed, 59 insertions(+) > > create mode 100644 ti-connectivity/license-wl1251.txt > > create mode 100644 ti-connectivity/wl1251-fw.bin > > create mode 100644 ti-connectivity/wl1251-nvs.bin > > When sending big binary blobs, it's generally better to send pull > requests instead of patches. If you add the -p option when calling git > pull-request, the text will include all the readable parts but will omit > the binary stuff. > > Thank you very much for following up on this! Ah, and I forgot to say that you should update the WHENCE file accordingly too. Check the wl12xx and wl18xx drivers for examples. -- Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ti-connectivity: add wl1251 firmware and license
On Wed, 2013-09-25 at 08:23 -0500, Felipe Balbi wrote: > On Wed, Sep 25, 2013 at 02:07:58PM +0300, Luca Coelho wrote: > > On Wed, 2013-09-25 at 14:04 +0300, Luca Coelho wrote: > > > When sending big binary blobs, it's generally better to send pull > > > requests instead of patches. If you add the -p option when calling git > > > pull-request, the text will include all the readable parts but will omit > > > the binary stuff. > > > > > > Thank you very much for following up on this! > > > > Ah, and I forgot to say that you should update the WHENCE file > > accordingly too. Check the wl12xx and wl18xx drivers for examples. > > I'll send a pull request, but how about this ? I don't think we can > change the license. It seems like the other firmwares are using the > older license, I'd argue those should be changed to the new one, but > that's another discussion. Cool, in general it looks good! Though it would be nice to know if the same "new" license could be used for all the firmwares to avoid almost identical licenses. More comments below... > diff --git a/WHENCE b/WHENCE > index e66fea5..4e9e2ed 100644 > --- a/WHENCE > +++ b/WHENCE > @@ -1705,6 +1705,19 @@ Licence: Redistributable. See > LICENCE.tda7706-firmware.txt for details. > > -- > > +Driver: wl1251 - Texas Instruments 802.11 WLAN driver for WiLink4 chips > + > +File: ti-connectivity/wl1251-fw.bin > +File: ti-connectivity/wl1251-nvs.bin Don't you have the firmware version number to add here with "Version:" tags like the other ones? I think you can easily find the version by running strings on the binary and grepping for "Rev" (at least with the newer WiLinks, this works). > +Licence: See LICENCE.wl1251 for details. > + > +The driver expects to find the firmwares under a ti-connectivity > subdirectory. > +So if your system looks for firmwares in /lib/firmware, the firmwares for > +wl12xx chips must be located in /lib/firmware/ti-connectivity/. It's a bit stupid that this was never changed in wl1251, but it still expects the driver in the "root" firmwares directory (ie. in /lib/firmware/wl1251-fw.bin, not in /lib/firmware/ti-connectivity/wl1251-fw.bin). Maybe now is the right time to change the driver appropriately to keep consistency? ;) -- Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M
On 07/01/2013 03:07 PM, Luca Barbato wrote: > Hopefully I will carve some time next weekend to play the restricted > bisect game. Release 3.10 apparently doesn't show the problem, I guess problem solved for me =) lu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M
On 06/27/2013 06:47 PM, Matthew Thode wrote: > There is an early boot failure with linux-3.[9,10].??? when booting > using uefi on low memory systems. > > This seems like it might be hardware specific, I am running on a Lenovo > T520, running bios version 1.42, firmware rev 1.36. > Had the same problem with linux 3.10-rc1 and a stock mac book pro, I hadn't investigated much further though. lu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M
On 07/01/2013 06:30 AM, Matthew Thode wrote: > You had the problem where it was blank on boot (right after grub, no > kernel messages at all)? Sounds like this might not be limited to just > Lenovo then. no grub, efi-stub directly from the efi shell. > mjg59, is there anything I can do to help move this bug forward? I've > done all I can think of (even tried a serial expresscard slot for logging). If you feel like bisecting seems the only option =_= lu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M
On 07/01/2013 07:13 AM, Matthew Garrett wrote: > On Sun, Jun 30, 2013 at 11:30:59PM -0500, Matthew Thode wrote: > >> mjg59, is there anything I can do to help move this bug forward? I've >> done all I can think of (even tried a serial expresscard slot for logging). > > It does sound like a bug, but unfortunately unless it can be duplicated > on real hardware without restrictive mem= arguments it's likely to be > low on my priorities - there's still enough UEFI bugs that hit people in > default configurations that they tend to get priority, I'm afraid. > real hardware -> MacBookPro8,2 with efi-stub, loading directly from the efi shell w/out any memory restriction. I guess I should try to get more information for you and see if it isn't some configuration quirk. lu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M
On 07/01/2013 08:25 AM, Matthew Garrett wrote: > On Mon, Jul 01, 2013 at 07:22:32AM +0200, Luca Barbato wrote: > >> MacBookPro8,2 with efi-stub, loading directly from the efi shell w/out >> any memory restriction. > > How do you know this is the same issue? > I believe in duck bugs, if the range of broken commits looks the same, and the behaviour looks the same, probably the cause is the same, or at least I once can be investigated on real hardware and probably once fixed the other might be fixed as well. I have not deep knowledge of uefi/efi internals so I'll need some pointers to figure out exactly why it happens. Hopefully I will carve some time next weekend to play the restricted bisect game. lu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pl2303 works at 500kbps
My PL2303HX works at 500kbps after applying this patch.
I suppose that it could work at other non standard speeds since this fix
"correctly handle baudrates above 115200"
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/serial/pl2303.c?id=8d48fdf689fed2c73c493e5146d1463689246442
came after this one
"fix baud rate handling in case of unsupported values"
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/serial/pl2303.c?id=25b8286805e856c8c7fda127018e31032c918015
but I only can test it with 50.
Patch made against mainline but tested with 3.4.45
Please CC me since I'm not subscribed
Signed-off-by: Luca Olivetti
---
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 7151659..ca19b17 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -275,7 +275,7 @@ static void pl2303_set_termios(struct tty_struct *tty,
u8 control;
const int baud_sup[] = { 75, 150, 300, 600, 1200, 1800, 2400, 3600,
4800, 7200, 9600, 14400, 19200, 28800, 38400,
-57600, 115200, 230400, 460800, 614400,
+57600, 115200, 230400, 460800, 50, 614400,
921600, 1228800, 2457600, 300, 600 };
int baud_floor, baud_ceil;
int k;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: Android: logger: module_exit implementation
This patch creates the module_exit for the android logger
so that it can be loaded and unloaded as a module.
The android logger is already declared as a tristate in the
Kconfig but the module_exit function was missing.
device_initcall works also with modprobe since include/linux/init.h:
#define module_init(x) __initcall(x);
...
#define __initcall(fn) device_initcall(fn)
Tested against f4a75d2eb7b1e2206094b901be09adb31ba63681 Linux 3.7-rc6
Signed-off-by: Luca Clementi
---
drivers/staging/android/logger.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index 1d5ed47..dbc63cb 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -676,4 +676,25 @@ static int __init logger_init(void)
out:
return ret;
}
+
+static void __exit logger_exit(void)
+{
+ struct logger_log *current_log, *next_log;
+
+ list_for_each_entry_safe(current_log, next_log, &log_list, logs) {
+ /* we have to delete all the entry inside log_list */
+ misc_deregister(¤t_log->misc);
+ vfree(current_log->buffer);
+ kfree(current_log->misc.name);
+ list_del(¤t_log->logs);
+ kfree(current_log);
+ }
+}
+
+
device_initcall(logger_init);
+module_exit(logger_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Robert Love, ");
+MODULE_DESCRIPTION("Android Logger");
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list
Fuck! I hate these things early in the morning. what gets me extremely pissed in the whole business is that i don't believe that splitting the mailing list is the solution to LVM problems. Escpecially since we have a number of lusers of lwm at the time being. I believe sistina is mostly at fault there, not for the mailing list issue (i really don't believe people getting kicked out, while the moderation messages are probably due to mailman braindamage) but for political reasons (stop making it look as a sistina-only project, it pisses everyone) we have some serous problems here. an lvm in the kernel which is badly broken(tm) a better lvm (still buggy according to many kernel hackers, but better still), which does not get into the kernel for communication reasons. (Alan can you help? there is a lot of stuff that goes in -ac before going to mainstream) A development model where only sistina people have access to cvs. This is bad, has the only effect of pissing off people like Andreas which has been feeding patches and good ideas for many months now, besides it leads to people having their own lvm tree, so everybody is testing their development version, which has nothing to do with the version in the goddamned kernel. now what i propose is (some has already been said): lets's vote for which mailing list we want to keep (and everybody accept the result) open the goddam cvs to hackers that request access to it, you can use different branches and do code freezes with cvs, so it won't hurt releases schedules. try to ship the most evident bugfixes from cvs to linus, please all long-time kernel hakcers who got involved in this help do this. open up also the decision process (IOP 11 in beta5 and IOP 10 back in beta6 could not have happened if somebody eles knew about the IOP change.) Regards, L. (Sorry for the big CC list, but i dunno who is subscribed to what anymore) -- Luca Berra -- [EMAIL PROTECTED] Communication Media & Services S.r.l. /"\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.2.18pre21 - IP kernel level autoconfiguration
> It seem somewhere between 2.2.17 and the current 2.2.18 kernel, IP > kernel level autoconfiguration has been broken. Upon kernel loading > the Ethernet card is detected and loaded properly, but the bootp code > never seems to be executed and mounting the root partion via NFS then > fails from lack of IP configuration. > I haven't had any luck tracing down the root of this problem. > Anyone else experience this problem or have a patch to fix it? Hi! I've the same behavior here: server kernel : 2.2.17 dhcpd : 2.0b1pl29 client kernel : 2.2.18-21 client cmdline: root=/dev/nfs nfsroot=/foo/bar ip=bootp After some quick tests seem that if you want bootp you _need_ to compile the client's kernel with _only_ bootp, if you have also dhcp, it doesn't work :( Dhcp into kernel is COOL and I hope that someone is porting on 2.4 ;), doesn't seem that hard hope this help, luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre21 - IP kernel level autoconfiguration
Chip Schweiss wrote: > > The problem seems to be deeper than that. I first encountered the > problem with only bootp compiled in. In my configuration I am not able > to supply kernel parameters on the client which may be why you were > able to get bootp to execute. Seem that you have to specify the "ip=bootp" options now * : *off|none - don't do autoconfig at all (DEFAULT) *on|any - use any configured protocol *dhcp|bootp|rarp - use only the specified protocol *both - use both BOOTP and RARP (not DHCP) Anyway I'll do more investigation about my problem to get bootp work with dhcp compiled into kernel next week luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: 2.2.18pre21 - IP kernel level autoconfiguration
Luca Montecchiani wrote:
:
> Anyway I'll do more investigation about my problem to get bootp
> work with dhcp compiled into kernel next week
With the 2.2.18pre22 kernel and also pre21 last time I checked
if you compile the kernel with DHCP and BOOTP, it's impossible
to use bootp, you need to recompile the kernel without dhcp.
The problem (bug) is that dhcp code is _always_ executed also in
the case of bootp, breaking the procedure :(
I love to have dhcp and bootp compiled into kernel, so I can
chose my preferred protocol with the ip= option.
I don't like this _goto_ patch against 2.2.18pre22, but work :
--- ipconfig.c.old Mon Nov 20 17:01:16 2000
+++ ipconfig.c Mon Nov 20 17:34:01 2000
@@ -842,6 +842,8 @@
u32 server_id = INADDR_NONE;
int mt = 0;
+ if ( !(ic_proto_enabled & IC_USE_DHCP) ) goto nodhcp;
+
ext = &b->exten[4];
while (ext < end && *ext != 0xff) {
u8 *opt = ext++;
@@ -896,6 +898,7 @@
#endif /* IPCONFIG_DHCP */
+nodhcp:
ext = &b->exten[4];
while (ext < end && *ext != 0xff) {
u8 *opt = ext++;
ciao,
luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.4.0-test11-ac3 breaks raid autodetect (was Re: [BUG] raid5 link error? (was [PATCH] raid5 fix after xor.c cleanup))
On Mon, Nov 27, 2000 at 01:18:52PM +1100, Neil Brown wrote:
> > Sorry to tell you that I just tried linux-2.4.0-test11-ac3 (which has this
> > patch) and I couldn't boot because the kernel detects the raid1 devices
> > but kicks the shortly after. I had to back out this code.
>
> Thanks for this
>
> I have looked more deeply, and discovered the error of my ways.
also test11-ac4 contains the following patch which is broken and should
be reversed! (if xor.o is built as a module it will export the symbol
calibrate_xor_block_R??? and require calibrate_xor_block ?!?)
anyway the only piece of code that uses calibrate_xor_block is
drivers/md/xor.c itself, so why export?
Regards,
L.
--- drivers/md/xor.cSun Nov 26 21:35:14 2000
+++ drivers/md/xor.c.ac4.fooSun Nov 26 21:43:52 2000
@@ -98,7 +98,7 @@
speed / 1000, speed % 1000);
}
-static int
+int
calibrate_xor_block(void)
{
void *b1, *b2;
@@ -139,5 +139,6 @@
}
MD_EXPORT_SYMBOL(xor_block);
+MD_EXPORT_SYMBOL(calibrate_xor_block);
module_init(calibrate_xor_block);
--
Luca Berra -- [EMAIL PROTECTED]
Communication Media & Services S.r.l.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH?] Extended PTBL partition check for 2.4
Hi,
few ours ago I discover that my kernel 2.4.0-test8pre5 was unable to
correctly identify the geometry of my second ide HD (*), this is very
bad and fdisk come out with a lot of warnings, see:
Disk /dev/hdc: 16 heads, 63 sectors, 6296 cylinders
Units = cylinders of 1008 * 512 bytes
Device BootStart EndBlocks Id System
/dev/hdc1 1 2032 1024127+ 83 Linux
Partition 1 does not end on cylinder boundary:
phys=(253, 127, 63) should be (253, 15, 63)
/dev/hdc2 2033 2296133056 82 Linux swap
Partition 2 does not end on cylinder boundary:
phys=(286, 127, 63) should be (286, 15, 63)
/dev/hdc4 2297 6296 20160005 Extended
Partition 4 does not end on cylinder boundary:
phys=(786, 127, 63) should be (786, 15, 63)
/dev/hdc5 2297 2704205631+ 83 Linux
/dev/hdc6 2705 6296 1810367+ 83 Linux
This is how the kernel see the world:
hda: 26520480 sectors (13578 MB) w/1966KiB Cache, CHS=1650/255/63, (U)DMA
hdc: 6346368 sectors (3249 MB) w/96KiB Cache, CHS=6296/16/63, DMA
Partition check:
hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
hdc: hdc1 hdc2 hdc4 < hdc5 hdc6 >
Booting with 2.2.17 everything work fine, that kernel correctly
identify the [PTBL] nature of my hdc and apply all the necessary
conversion see:
hda: IBM-DJNA-371350, 12949MB w/1966kB Cache, CHS=1650/255/63
hdc: IBM-DAQA-33240, 3098MB w/96kB Cache, CHS=6296/16/63
Partition check:
hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
hdc: [PTBL] [787/128/63] hdc1 hdc2 hdc4 < hdc5 hdc6 >
fdisk is a lot happy now:
Disk /dev/hdc: 128 heads, 63 sectors, 787 cylinders
Units = cylinders of 8064 * 512 bytes
Device BootStart EndBlocks Id System
/dev/hdc1 1 254 1024127+ 83 Linux
/dev/hdc2 255 287133056 82 Linux swap
/dev/hdc4 288 787 20160005 Extended
/dev/hdc5 288 338205631+ 83 Linux
/dev/hdc6 339 787 1810367+ 83 Linux
Ok, to the code.
2.2.17/drivers/block/genhd.c :
for (i = 0; i < 4; i++) {
struct partition *q = &p[i];
if (NR_SECTS(q)
&& (q->sector & 63) == 1
&& (q->end_sector & 63) == 63) {
unsigned int heads = q->end_head + 1;
if (heads == 32 || heads == 64 ||
heads == 128 || heads == 240 ||
heads == 255) {
(void) ide_xlate_1024(dev, heads, " [PTBL]");
break;
}
}
2.4.0-pre8/fs/partitions/msdos.c :
for (i = 0; i < 4; i++) {
struct partition *q = &p[i];
if (NR_SECTS(q)) {
if ((q->sector & 63) == 1 &&
(q->end_sector & 63) == 63)
heads = q->end_head + 1;
break;
}
}
Debugging the code show that 2.4.0 always exit at the first
valid partition found, discarding the remaining ones and
to early to identify the PTBL nature of my hdc disk.
this is what 2.4.0-pre8 does:
i=0 NR=2048255 q->sector=2 q->end_sector=63 q->end_head=127
break
this is what 2.2.17 does:
i=0 NR=2048255 q->sector=2 q->end_sector=63 q->end_head=127
i=1 NR=266112 q->sector=1 q->end_sector=127 q->end_head=127 PTBL!
break
Follow the patch that works for me (tm):
--- msdos.c.ORI Wed Jul 19 08:29:16 2000
+++ msdos.c Wed Sep 6 23:46:29 2000
@@ -398,9 +398,10 @@
struct partition *q = &p[i];
if (NR_SECTS(q)) {
if ((q->sector & 63) == 1 &&
- (q->end_sector & 63) == 63)
+ (q->end_sector & 63) == 63) {
heads = q->end_head + 1;
- break;
+ break;
+ }
}
}
if (SYS_IND(p) == EZD_PARTITION) {
Seem that 2.4.0test8 follow the PTBL definition described
in the Large-Disk-HOWTO, only primary partition, 2.2.17 instead
extend the check all over the four partition.
(*) The hdc disk was autopartitioned by sfdisk over a 2.2.17
kernel
comments ?
luca
--
--
E-mail..: Luca Montecchiani <[EMAIL PROTECTED]>
W.W.W...: http://i.am/m.luca - http://luca.myip.org
Speakfreely.: sflwl -hlwl.fourmilab.ch luca@
I.C.Q...: 17655604
---=(Linux since 1995)=---
Non esiste vento favorevole per il marinaio che non sa dove andare
Seneca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH?] Extended PTBL partition check for 2.4
Andries Brouwer wrote: : Thanks for your exhaustive explanation as usual. > I think I prefer the current version over your patched version. > But will probably change my mind when many people complain. Why have different behavior ? Why have *fdisk or lilo trouble ? I still didn't see the gain. people++; luca -- -- E-mail..: Luca Montecchiani <[EMAIL PROTECTED]> W.W.W...: http://i.am/m.luca - http://luca.myip.org Speakfreely.: sflwl -hlwl.fourmilab.ch luca@ I.C.Q...: 17655604 ---=(Linux since 1995)=--- Non esiste vento favorevole per il marinaio che non sa dove andare Seneca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in test10 during module loading of 3c509
It seems the cleaning up of the network drivers has been a tad too
aggressive :) There is no init_etherdev() anymore in 3c509.c
The following patch seems to solve the problem.
(the code is taken from a working test10pre5)
Cheers,
lg
--- 3c509.c.test10-broken Wed Nov 1 17:12:08 2000
+++ 3c509.c Wed Nov 1 17:13:37 2000
@@ -434,6 +434,13 @@
/* Free the interrupt so that some other card can use it. */
outw(0x0f00, ioaddr + WN0_IRQ);
found:
+if (dev == NULL) {
+dev = init_etherdev(dev, sizeof(struct el3_private));
+if (dev == NULL) {
+release_region(ioaddr, EL3_IO_EXTENT);
+return -ENOMEM;
+}
+}
memcpy(dev->dev_addr, phys_addr, sizeof(phys_addr));
dev->base_addr = ioaddr;
dev->irq = irq;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test 10 breaks on alpha
The clock on some alpha systems might be at 1200 Hz... you've rather to use HZ: --- /usr/src/linux/include/asm-alpha/param.h.orig Wed Nov 1 12:31:56 2000 +++ /usr/src/linux/include/asm-alpha/param.h Wed Nov 1 12:33:22 2000 @@ -27,4 +27,8 @@ #define MAXHOSTNAMELEN 64 /* max length of hostname */ +#ifdef __KERNEL__ +# define CLOCKS_PER_SEC HZ +#endif + #endif /* _ASM_ALPHA_PARAM_H */ and, yes... this patch works, at least on a 500au I've got 2.4.0t10 running on. [BTW: the 500au is a Miata, hence the frequency is 1024 Hz] Cheers, lg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18 almost...
> did we lose ip=autoconf. I see dhcp and arp transmitting infinitely. I was > able to boot only after completely entering nfsroot= and ip= boot commands. > > 2.2.17 worked thusley. : I didn't try with 2.2.18 yet but looking at the source (ipconfig.c) seem that my patch wasn't accepted, you can give it a try : http://boudicca.tux.org/hypermail/linux-kernel/2000week48/0213.html hope this help, luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch-2.2.18] some trivial patch...
Hi Alan,
the first patch is a must for kernels that load scsi driver from initrd
;)
the second one allow "make install" to work also if lilo isn't
installed..
main.patch :
diff -ur linux-2.2.18.orig/init/main.c linux-2.2.18.tl/init/main.c
--- linux-2.2.18.orig/init/main.c Mon Dec 11 01:49:44 2000
+++ linux-2.2.18.tl/init/main.c Thu Dec 28 11:37:27 2000
@@ -485,7 +485,7 @@
{ "hdk", 0x3900 },
{ "hdl", 0x3940 },
#endif
-#ifdef CONFIG_BLK_DEV_SD
+#if defined(CONFIG_BLK_DEV_SD) || defined(CONFIG_BLK_DEV_SD_MODULE)
{ "sda", 0x0800 },
{ "sdb", 0x0810 },
{ "sdc", 0x0820 },
nolilo.patch :
diff -u -r kernel-2.2.18-orig/arch/i386/boot/install.sh
kernel-2.2.18-teamlinux/arch/i386/boot/install.sh
--- kernel-2.2.18-orig/arch/i386/boot/install.shTue Jan 3
12:57:26 1995
+++ kernel-2.2.18-teamlinux/arch/i386/boot/install.sh Tue Dec 19
16:21:24 2000
@@ -36,4 +36,10 @@
cat $2 > $4/vmlinuz
cp $3 $4/System.map
-if [ -x /sbin/lilo ]; then /sbin/lilo; else /etc/lilo/install; fi
+if [ -x /sbin/lilo ]; then
+ /sbin/lilo
+elif [ -x /etc/lilo/install ]; then
+ /etc/lilo/install
+fi
+
+# Grub rulez ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre11
Some problems here.. - Only 64 of 96 mbytes ram was found - Trident 4DWave DX show those messages: trident: drain_dac, dma timeout? I'll provide more info/testing on request, luca ver_linux: -- Linux luca.home.net 2.2.18pre11 #8 Wed Sep 27 22:27:35 CEST 2000 i586 unknown Kernel modules 2.3.14 Gnu C egcs-2.91.66 Binutils 2.9.5.0.16 Linux C Library2.1.2 Dynamic linker ldd (GNU libc) 2.1.2 Linux C++ Library 2.9.0 Procps 2.0.6 Mount 2.10m Net-tools 1.53 Kbd0.99 Sh-utils 1.16 Modules Loaded hisax isdn slhc .config: CONFIG_EXPERIMENTAL=y CONFIG_M586TSC=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_TSC=y CONFIG_1GB=y CONFIG_MTRR=y CONFIG_MODULES=y CONFIG_NET=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_QUIRKS=y CONFIG_PCI_OLD_PROC=y CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_APM=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_IDESCSI=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_BLK_DEV_ALI15X3=y CONFIG_BLK_DEV_LOOP=y CONFIG_PARIDE_PARPORT=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_SKB_LARGE=y CONFIG_SCSI=y CONFIG_CHR_DEV_SG=y CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_ISDN=m CONFIG_ISDN_PPP=y CONFIG_ISDN_PPP_VJ=y CONFIG_ISDN_MPP=y CONFIG_ISDN_DRV_HISAX=m CONFIG_HISAX_EURO=y CONFIG_HISAX_ELSA=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=y CONFIG_MOUSE=y CONFIG_PSMOUSE=y CONFIG_JOYSTICK=y CONFIG_JOY_PCI=y CONFIG_NVRAM=y CONFIG_RTC=y CONFIG_AGP=y CONFIG_AGP_ALI=y CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="cp437" CONFIG_NLS_CODEPAGE_850=y CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y CONFIG_SOUND=y CONFIG_SOUND_TRIDENT=y CONFIG_MAGIC_SYSRQ=y dmesg: -- Linux version 2.2.18pre11 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #8 Wed Sep 27 22:27:35 CEST 2000 Detected 451004 kHz processor. ide_setup: hdd=ide-scsi Console: colour VGA+ 80x25 Calibrating delay loop... 901.12 BogoMIPS Memory: 64260k/66496k available (912k kernel code, 412k reserved, 860k data, 52k init) Dentry hash table entries: 16384 (order 5, 128k) Buffer cache hash table entries: 65536 (order 6, 256k) Page cache hash table entries: 16384 (order 4, 64k) CPU: L1 I Cache: 32K L1 D Cache: 32K CPU: AMD-K6(tm) 3D processor stepping 0c Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED]) PCI: PCI BIOS revision 2.10 entry at 0xfb4e0 PCI: Using configuration type 1 PCI: Probing PCI hardware Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 28M agpgart: Detected Ali M1541 chipset agpgart: AGP aperture is 64M @ 0xd000 Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP TCP: Hash tables configured (ehash 65536 bhash 65536) Starting kswapd v 1.5 parport0: PC-style at 0x378 [SPP] Detected PS/2 Mouse Port. Serial driver version 4.27 with no serial options enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A pty: 256 Unix98 ptys configured lp0: using parport0 (polling). Real Time Clock Driver v1.09 Non-volatile memory driver v1.0 Trident 4DWave/SiS 7018/Ali 5451 PCI Audio, version 0.14.6a, 21:56:02 Sep 27 2000 trident: Trident 4DWave DX found at IO 0xec00, IRQ 9 ac97_codec: AC97 Audio codec, vendor id1: 0x8384, id2: 0x7605 (SigmaTel STAC9704) js: Joystick driver v1.2.15 (c) 1999 Vojtech Pavlik <[EMAIL PROTECTED]> js0: Analog 2-axis 4-button joystick on Trident 4DWave DX #0 loop: registered device at major 7 ALI15X3: IDE controller on PCI bus 00 dev 78 ALI15X3: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA *ALi IDE driver (1.0 beta3)* * Chip Revision is 20* * Maximum capability is - DMA * ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA hda: IBM-DJNA-371350, ATA DISK drive hdb: ASUS CD-S340, ATAPI CDROM drive hdc: Maxtor 84320D4, ATA DISK drive hdd: PCRW404, ATAPI CDROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 ALI15X3: MultiWord DMA enabled hda: IB
[PATCH] 2.2.x Isdn init function fix
Hi !
Init function for hisax driver cause a kernel hangup if the
idstring was omitted
"hisax=18,2" hang on boot
"hisax=18,2,HiSax" was fine
Kernel 2.4.x and modularized hisax was fine as well.
--- linux/drivers/isdn/hisax/config.c.orig Wed May 10 15:26:11 2000
+++ linux/drivers/isdn/hisax/config.c Thu Sep 28 22:48:44 2000
@@ -619,7 +619,7 @@
}
i++;
}
- if (strlen(str)) {
+ if (str) {
strcpy(HiSaxID, str);
HiSax_id = HiSaxID;
} else {
Grepping the whole kernel I also spot another possible place:
--- linux/drivers/isdn/icn/icn.c.orig Thu Sep 28 22:50:55 2000
+++ linux/drivers/isdn/icn/icn.cThu Sep 28 22:51:13 2000
@@ -1869,7 +1869,7 @@
portbase = ints[1];
if (ints[0] > 1)
membase = ints[2];
- if (strlen(str)) {
+ if (str) {
strcpy(sid, str);
icn_id = sid;
if ((p = strchr(sid, ','))) {
--
--
E-mail..: Luca Montecchiani <[EMAIL PROTECTED]>
W.W.W...: http://i.am/m.luca - http://luca.myip.org
Speakfreely.: sflwl -hlwl.fourmilab.ch luca@
I.C.Q...: 17655604
---=(Linux since 1995)=---
Non esiste vento favorevole per il marinaio che non sa dove andare
Seneca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[2.4.test9pre7] spontaneous reboot
Hi ! As I see recently on this list, I'm also experiencing spontaneous reboot here. This happen _twice_ with kernel 2.4.test9pre7 on my mostly idle and never overclocked K6 machine. It's so strange because this machine always run 2.4.x kernels with high load without any problems.. Unfortunately no syslog no oops just a silent reboot :( luca -- -- E-mail..: Luca Montecchiani <[EMAIL PROTECTED]> W.W.W...: http://i.am/m.luca - http://luca.myip.org Speakfreely.: sflwl -hlwl.fourmilab.ch luca@ I.C.Q...: 17655604 ---=(Linux since 1995)=--- Non esiste vento favorevole per il marinaio che non sa dove andare Seneca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[2.2.19pre17] init/main.c
Hi Alan,
On 28 Dec 2000 I've just sent a similar patch but I never got a reply ;)
http://boudicca.tux.org/hypermail/linux-kernel/2000week53/0264.html
The first part of the patch is a must for kernels that load scsi driver
from initrd
the second one is a must for kernel that load cciss block driver from
initrd
Without these changes there is no way to boot loading modules from
initrd :((
thanks,
luca
diff -ur linux-2.2.19-pre17/init/main.c
linux-2.2.19-pre17-tl/init/main.c
--- linux-2.2.19-pre17/init/main.c Wed Mar 28 13:55:53 2001
+++ linux-2.2.19-pre17-tl/init/main.c Wed Mar 28 13:02:49 2001
@@ -482,7 +482,7 @@
{ "hdk", 0x3900 },
{ "hdl", 0x3940 },
#endif
-#ifdef CONFIG_BLK_DEV_SD
+#if defined(CONFIG_BLK_DEV_SD) || defined(CONFIG_BLK_DEV_SD_MODULE)
{ "sda", 0x0800 },
{ "sdb", 0x0810 },
{ "sdc", 0x0820 },
@@ -536,6 +536,24 @@
{ "ida/c0d14p",0x48E0 },
{ "ida/c0d15p",0x48F0 },
#endif
+#if defined(CONFIG_BLK_CPQ_CISS_DA) ||
defined(CONFIG_BLK_CPQ_CISS_DA_MODULE)
+ { "cciss/c0d0p",0x6800 },
+ { "cciss/c0d1p",0x6810 },
+ { "cciss/c0d2p",0x6820 },
+ { "cciss/c0d3p",0x6830 },
+ { "cciss/c0d4p",0x6840 },
+ { "cciss/c0d5p",0x6850 },
+ { "cciss/c0d6p",0x6860 },
+ { "cciss/c0d7p",0x6870 },
+ { "cciss/c0d8p",0x6880 },
+ { "cciss/c0d9p",0x6890 },
+ { "cciss/c0d10p",0x68A0 },
+ { "cciss/c0d11p",0x68B0 },
+ { "cciss/c0d12p",0x68C0 },
+ { "cciss/c0d13p",0x68D0 },
+ { "cciss/c0d14p",0x68E0 },
+ { "cciss/c0d15p",0x68F0 },
+#endif
#ifdef CONFIG_ATARI_ACSI
{ "ada", 0x1c00 },
{ "adb", 0x1c10 },
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Support Timedia/Sunix/Exsys PCI card problem in Serial 5.0.5 / Kernel 2.4.xx
Hi!
I've found a bug in the serial driver 5.0.5, the problem is
that the Sunix pci 4port serial card wasn't correctly detected.
I'm using the serial 5.0.5 serial driver on a vanilla 2.2.19 kernel.
Searching the web I've found this changes that looks wrong :
http://www.linuxhq.com/kernel/v2.3/patch/patch-2.4.0-test7/linux_drivers_char_serial.c.html
here the obvious patch that made it work again here on 2.2.19 kernel.
Should be applied also on 2.4.x :
--- serial.c.oriFri Jun 8 16:12:16 2001
+++ serial.cFri Jun 8 16:12:30 2001
@@ -4178,7 +4178,7 @@
for (i=0; timedia_data[i].num; i++) {
ids = timedia_data[i].ids;
for (j=0; ids[j]; j++) {
- if (pci_get_subvendor(dev) == ids[j]) {
+ if (pci_get_subdevice(dev) == ids[j]) {
board->num_ports = timedia_data[i].num;
return 0;
}
ciao,
luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kexec and frame buffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric W. Biederman ha scritto: > So without doing passing --real-mode the vga= parameter currently > cannot work. The vga= parameter is processed by vga.S which > make BIOS calls and we bypass all of the BIOS calls. Actually that file is video.S > So you can try with the --real-mode option and you have > a chance of the code working. Or you can figure out which > information video.S passes to the kernel figure out how > to get that same information out of a running kernel > and then /sbin/kexec can be tweaked to pass the current > video mode. Changing frame buffer modes shouldn't work > but you should at least be able to preserve the existing > ones. I tried to pass --real-mode flag to kexec but my virtual machine doesn't like it. When I launch kexec -e, it tells me: "A strange behaviour occourred which crashed virtual machine". I'll dig source code ASAP to figure out this matter. Meanwhile I'm going to follow your advice to inspect video.S in order to track down something useful. Regards, - -- Luca -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvTG5czkDT3RfMB6AQJY8Qf9HucRMCCAvta/pAs1CakqwJs5bZo4uJUu 3tat7+24I57mDmj+2IGe7qLO9W9ctCyVJStHTMCpjYq0qF7TA9VZSsU3ip1h9/IG HnCzozUGpd3yrNsrs3v0fvinQ1z2UtrOY8lxCUISchI3Ho43KnPDoAV2mfT+eEcP pN/lUz6Z/Jb0YbNS9Z352bqs+JtuxHzX1pVD4uH4X+Dkua3kAde5C0bwP9K+O15A //qlXb4AJErv6I5+Q/RxCDAn4TtVJCcdoA9Sp84ZH8jnxiYkg2coijvwFHLLvPD/ bK49QyD5QHmsVC3x/pIefd3qPEOphbNPE7AlN86X8B4i8lI6jr2x3g== =YhUC -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kexec and frame buffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric W. Biederman ha scritto: > Anyway I believe you also want to look at include/linux/tty.h > at the screen_info structure. I believe that is where > all of that information is passed. I noticed. Maybe if we fill struct x86_linux_param_header with some values obtained from struct screen_info, we should be able to "score that mid-court prayer" ;) >>I tried to pass --real-mode flag to kexec but my virtual machine doesn't like >>it. When I launch kexec -e, it tells me: "A strange behaviour occourred which >>crashed virtual machine". > > > Cool. I haven't used that code in a long time but it is pretty > trivial code to switches to real mode so I don't really doubt it :) Added to my list-of-things-to-do-after-holydays :) Regards, - -- Luca -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvYmaszkDT3RfMB6AQLPMQf/W3HZbJj50rxI1LOHyw0hhcQZji+gU68R E88xmgbL1fuiQqdqD1vp3gG7uDf9jjE+TjNMQ1qgZr01xHUjV13Jq8e9Lu75S+RZ JgiYJxFKGY/ctl9oFgEraU9Qje1b18dTmYh5G4xfZLNjUFUM1uQowV6CSPLVRadv ucmzduDrqwRBQgN9vSrWPoLio8nbT5ZjxLjaY1z3P3EYXoBs9LLx1bjzLmR7/cVe MP3/BM61CLqflOG9G+ck9yD2RIYnLhvNHDBKt1X+oP+U/iSkzse3XEM/YVny6/3d zAYy8m66o2bPnj/vNcBbroxANTdiXJce8QWayk9a69c26DmjOLnYrQ== =iPn6 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Real-Time Preemption V0.7.53-02, fix redundant PREEMPT_RCU config option
This patch removes a redundant PREEMPT_RCU option from kernel/Kconfig.preempt.
Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]>
--- realtime-preempt-2.6.13-rc4-RT-V0.7.53-02.orig 2005-08-11
18:56:51.0
+
+++ realtime-preempt-2.6.13-rc4-RT-V0.7.53-02 2005-08-11
21:13:43.0 +
@@ -21571,18 +21571,6 @@ Index: linux/kernel/Kconfig.preempt
+
+Say N if you are unsure.
+
-+config PREEMPT_RCU
-+ bool "Preemptible RCU"
-+ default n
-+ depends on PREEMPT
-+ help
-+This option reduces the latency of the kernel by making certain
-+RCU sections preemptible. Normally RCU code is non-preemptible, if
-+this option is selected then read-only RCU sections become
-+preemptible. This helps latency, but may increase memory utilization.
-+
-+Say N if you are unsure.
-+
+config SPINLOCK_BKL
+ bool "Old-Style Big Kernel Lock"
+ depends on (PREEMPT || SMP) && !PREEMPT_RT
Regards,
--
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kexec and frame buffer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luca Falavigna ha scritto: > Eric W. Biederman ha scritto: > >>>Anyway I believe you also want to look at include/linux/tty.h >>>at the screen_info structure. I believe that is where >>>all of that information is passed. > > I noticed. Maybe if we fill struct x86_linux_param_header with some values > obtained from struct screen_info, we should be able to "score that mid-court > prayer" ;) > I tried to implement a new ioctl command in fb_ioctl() in order to retrieve and store screen_info variables into struct x86_linux_param_header, but I got the same result: no messages shown in console, as I supposed. After that I looked at video.S, especially an interesting label called "video": # This is the main entry point called by setup.S # %ds *must* be pointing to the bootsector video: pushw %ds # We use different segments pushw %ds # FS contains original DS popw%fs [...] #ifdef CONFIG_VIDEO_SELECT movw%fs:(0x01fa), %ax # User selected video mode cmpw$ASK_VGA, %ax # Bring up the menu jz vid2 [...] Video mode is stored (by bootloader, actually) at offset 0x01fa from a given boot sector, which should be located at physical address DEF_SETUPSEG (0x9020). Feel free to correct me if I'm wrong. If we could store current video mode before executing reboot_code_buffer, probably setup() function would take care of anything else. So we could implement a function (or an assembly stub) in machine_kexec which does this job. I think this is the best (and safest) solution. Regards, - -- Luca -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQvzwDczkDT3RfMB6AQJlQAf+INkCMjhmm18RPCMHXij7WmOL/4TCKTc8 fZCf+IzhsSUxwkfYmUbTfXtJ/xCxIyRh5gBGirB9n/s9NzOiYwmcQWMrn7DbWpWu YBVkTdz3W3Y0dA08baIYQ8u51gJvnVMuGJEFqsLxPx+gzHJOETEGkzhuyUuPk+J+ N4OkSyTGYt5zXZmyVzV7KZ8XLrfX3XvRLV3m2aey0Hz4jcf8sIozANokDRdG3MpN 7F0Z4yL1EnMI4oijHSDLeqbycAg8iYa49P45EO6+jzuRH2i2bnq8hOvBHa0+B01Q Gr0Ljd+DJ2jNVO4ecqbWC9oFxBFXsRN+ThAxsYEbWDGIrJdAa32mfA== =BztK -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][TRIVIAL] Real-Time Preemption V0.7.51-38: fix compile bug in drivers/block/paride/pseudo.h
This patch, built against kernel version 2.6.13-rc3, fixes a small bug in
drivers/block/paride/pseudo.h which prevents its related drivers from being
compiled successfully when RT patch (version 0.7.51-38) is compiled in.
This is due to the new definition of DEFINE_SPINLOCK macro, which does not
longer accept additional attributes.
Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]>
--- ./drivers/block/paride/pseudo.h.orig 2005-03-02 21:39:37.0 +
+++ ./drivers/block/paride/pseudo.h 2005-07-27 15:37:50.0 +
@@ -43,7 +43,7 @@
static int ps_tq_active = 0;
static int ps_nice = 0;
-static DEFINE_SPINLOCK(ps_spinlock __attribute__((unused)));
+static __attribute__((unused)) DEFINE_SPINLOCK(ps_spinlock);
static DECLARE_WORK(ps_tq, ps_tq_int, NULL);
Regards,
--
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Real-Time Preemption V0.7.52-07: rt_init_MUTEX_LOCKED declaration
This patch fixes broken rt_init_MUTEX_LOCKED declaration using rt_sema_init() macro. This way we fix a potential compile bug: rt_init_MUTEX_LOCKED calls there_is_no_init_MUTEX_LOCKED_for_RT_semaphores, which is not referenced. (e.g. drivers/char/watchdog/cpu5wdt.c: "cpu5wdt: Unknown symbol there_is_no_init_MUTEX_LOCKED_for_RT_semaphores") Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]> --- realtime-preempt-2.6.13-rc4-RT-V0.7.52-07.orig 2005-07-31 23:35:18.0 + +++ realtime-preempt-2.6.13-rc4-RT-V0.7.52-07 2005-08-01 15:59:31.0 + @@ -8342,16 +8342,6 @@ Index: linux/drivers/cpufreq/cpufreq.c === --- linux.orig/drivers/cpufreq/cpufreq.c +++ linux/drivers/cpufreq/cpufreq.c -@@ -605,7 +605,8 @@ static int cpufreq_add_dev (struct sys_d - policy->cpu = cpu; - policy->cpus = cpumask_of_cpu(cpu); - -- init_MUTEX_LOCKED(&policy->lock); -+ init_MUTEX(&policy->lock); -+ down(&policy->lock); - init_completion(&policy->kobj_unregister); - INIT_WORK(&policy->update, handle_update, (void *)(long)cpu); - @@ -614,6 +615,7 @@ static int cpufreq_add_dev (struct sys_d */ ret = cpufreq_driver->init(policy); @@ -14350,7 +14340,7 @@ Index: linux/include/linux/rt_lock.h === --- /dev/null +++ linux/include/linux/rt_lock.h -@@ -0,0 +1,391 @@ +@@ -0,0 +1,385 @@ +#ifndef __LINUX_RT_LOCK_H +#define __LINUX_RT_LOCK_H + @@ -14589,14 +14579,8 @@ Index: linux/include/linux/rt_lock.h +extern void FASTCALL(__init_MUTEX(struct semaphore *sem, char *name, char *file, int line)); +#define rt_init_MUTEX(sem) \ + __init_MUTEX(sem, #sem, __FILE__, __LINE__) -+ -+extern void there_is_no_init_MUTEX_LOCKED_for_RT_semaphores(void); -+ -+/* -+ * No locked initialization for RT semaphores -+ */ +#define rt_init_MUTEX_LOCKED(sem) \ -+ there_is_no_init_MUTEX_LOCKED_for_RT_semaphores() ++ rt_sema_init(sem, 0) +extern void FASTCALL(rt_down(struct semaphore *sem)); +extern int FASTCALL(rt_down_interruptible(struct semaphore *sem)); +extern int FASTCALL(rt_down_trylock(struct semaphore *sem)); Regards, -- Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Real-Time Preemption V0.7.52-07: rt_init_MUTEX_LOCKED declaration
> Ingo purposely put this in to crash
> the compile so that we know where this can be a problem right away.
And it works nice ;)
> The patch you wanted to send was:
>
> Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
>
> Index: linux_realtime_ernie/drivers/char/watchdog/cpu5wdt.c
> ===
> --- linux_realtime_ernie/drivers/char/watchdog/cpu5wdt.c(revision 265)
> +++ linux_realtime_ernie/drivers/char/watchdog/cpu5wdt.c(working copy)
> @@ -56,7 +56,7 @@
> /* some device data */
>
> static struct {
> - struct semaphore stop;
> + struct compat_semaphore stop;
> volatile int running;
> struct timer_list timer;
> volatile int queue;
Another solution could be this (as shown in drivers/cpufreq/cpufreq.c):
- init_MUTEX_LOCKED(&policy->lock);
+ init_MUTEX(&policy->lock);
+ down(&policy->lock);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
kexec and frame buffer
I made three experiments regarding kexec with frame buffer support (vesafb). For
each of them I gathered dmesg messages from original and relocated kernel, in
order to easily compare them later on. These tests were run on a virtual machine
in order to provide the same environment for each experiment.
Here are my tests and related results:
1) Frame buffer not enabled
Original kernel command line: root=/dev/hda1 ro
Relocated kernel command line: root=/dev/hda1 ro
Everything went well, as supposed to be. I was able to read boot messages and to
see login prompts.
2) Frame buffer enabled in the relocated kernel
Original kernel command line: root=/dev/hda1 ro
Relocated kernel command line: root=/dev/hda1 ro vga=791
This time I was able to read boot messages and so on, but I couldn't be able to
load vesafb in the relocated kernel. dmesg showed nothing about vesafb.
3) Frame buffer enabled in the original kernel
Original kernel command line: root=/dev/hda1 ro vga=791
Relocated kernel command line: root=/dev/hda1 ro {vga=791,}
This time I wasn't able to read boot messages in the relocated kernel, whether
vga parameter was set or not. I looked at dmesg in order to get some useful
informations:
Linux version 2.6.13-rc5 ([EMAIL PROTECTED]) (gcc version 3.3.4 (Debian
1:3.3.4-13)) #3 Wed Aug 3 13:39:11 UTC 2005
[...]
-Console: colour dummy device 80x25
+Console: colour VGA+ 80x25
[...]
-vesafb: framebuffer at 0xf000, mapped to 0xc288, using 3072k, total
16384k
-vesafb: mode is 1024x768x16, linelength=2048, pages=0
-vesafb: protected mode interface info at 00ff:44f0
-vesafb: scrolling: redraw
-vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
-mtrr: your processor doesn't support write-combining
-Console: switching to colour frame buffer device 128x48
-fb0: VESA VGA frame buffer device
[...]
It seems relocated kernel doesn't (or can't) load vesafb. Is frame buffer
supported in kexec or there is some work-in-progress?
Regards,
--
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Real-Time Preemption, fixed kexec kernel relocation oops
This patch, built against kernel version 2.6.13-rc7 (and not against -RT tree
patch, sorry), fixes a few local_irq_disable() calls which leads to an oops
during kernel relocation in kexec subsystem. Currently, only i386 implementation
of kexec is fixed.
Anyway, this patch does not fix a strange behaviour when using kexec with a -RT
kernel. Here is dmesg output:
Uncompressing Linux... OK, booting the kernel.
Unknown interrupt or fault at EIP 0203 0060 c011dfe3
Linux version 2.6.13-rc7-rt1 ([EMAIL PROTECTED]) (gcc version 3.3.4 (Debian
1:3.3.4-13)) #2 Fri Aug 26 16:55:12 UTC 2005
[...]
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
[...]
System is very slow and there are tons of "lost interrupt" messages.
Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]>
--- ./arch/i386/kernel/machine_kexec.c.orig 2005-08-28 22:03:52.0
+
+++ ./arch/i386/kernel/machine_kexec.c 2005-08-28 22:05:28.0 +
@@ -187,7 +187,7 @@ NORET_TYPE void machine_kexec(struct kim
relocate_new_kernel_t rnk;
/* Interrupts aren't acceptable while we reboot */
- local_irq_disable();
+ raw_local_irq_disable();
/* Compute some offsets */
reboot_code_buffer = page_to_pfn(image->control_code_page)
--- ./arch/i386/kernel/crash.c.orig 2005-08-28 22:04:08.0 +
+++ ./arch/i386/kernel/crash.c 2005-08-28 22:04:55.0 +
@@ -143,7 +143,7 @@ static int crash_nmi_callback(struct pt_
*/
if (cpu == crashing_cpu)
return 1;
- local_irq_disable();
+ raw_local_irq_disable();
if (!user_mode(regs)) {
crash_setup_regs(&fixed_regs, regs);
@@ -210,7 +210,7 @@ void machine_crash_shutdown(struct pt_re
* an SMP system.
*/
/* The kernel is broken so disable interrupts */
- local_irq_disable();
+ raw_local_irq_disable();
/* Make a note of crashing cpu. Will be used in NMI callback.*/
crashing_cpu = smp_processor_id();
Regards,
--
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Decreasing stime running confuses top (was: top displaying 9999% CPU usage)
Il Thu, Oct 04, 2007 at 01:32:44AM +0200, Frans Pop ha scritto: > On Wednesday 03 October 2007, you wrote: > > On Wed, Oct 03, 2007 at 09:27:41PM +0200, Frans Pop wrote: > > > On Wednesday 03 October 2007, you wrote: > > > > On Wed, 3 Oct 2007, Ilpo Järvinen wrote: > > > > > On Wed, 3 Oct 2007, Frans Pop wrote: > > > > > > The only change is in 2 consecutive columns: "2911 502" -> "2912 > > > > > > 500". Is processor usage calculated from those? Can someone > > > > > > explain how? > > > > > > > > > > The latter seems to be utime ...decreasing. No wonder if > > > > > arithmetics will give strange results (probably top is using > > > > > unsigned delta?)... > > > > > > > > Hmm, minor miscounting from my side, stime seems more appropriate... > > > > > > So, is it normal that stime decreases sometimes or a kernel bug? > > > /me expects the last... > > > > Let me guess... Dual core AMD64 ? > > Nope: Intel(R) Pentium(R) D CPU 3.20GHz I just notice the same thing here, with a Core2 Duo (which is supposed to have synced TSCs) and working HPET. > The following may well be relevant. > With 2.6.22 and early 2.6.23-rc kernels (rc3-rc6) I often had this in my > kernel log (see http://lkml.org/lkml/2007/9/16/45): > checking TSC synchronization [CPU#0 -> CPU#1]: >Measured 248 cycles TSC warp between CPUs, turning off TSC clock. >Marking TSC unstable due to check_tsc_sync_source failed I don't see this though, TSCs are always syncronized between the 2 cores. Luca -- Ligabue canta: "Tutti vogliono viaggiare in prim..." Io ci ho provato e dopo un chilometro ho fuso il motore e bruciato la frizione... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] V4L: w9968cf, remove bad usage of ERESTARTSYS
acked-by: Luca Risolia <[EMAIL PROTECTED]> On Monday 08 October 2007 14:40:13 Jiri Slaby wrote: > w9968cf, remove bad usage of ERESTARTSYS > > down_read_trylock can't be interrupted and so ERESTARTSYS would reach > userspace, which is not permitted. Change it to EAGAIN > > Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> > > --- > commit db38c559d37219c32b179ae005ca7e489336ec94 > tree f2d606165e6ef2daa6e1a2860f87521222eeecd2 > parent 6e42c2183befe136d85e6a8708ee4eabc543774b > author Jiri Slaby <[EMAIL PROTECTED]> Mon, 08 Oct 2007 14:14:03 +0200 > committer Jiri Slaby <[EMAIL PROTECTED]> Mon, 08 Oct 2007 14:14:03 +0200 > > drivers/media/video/w9968cf.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/video/w9968cf.c b/drivers/media/video/w9968cf.c > index 77599f2..5a1b5f5 100644 > --- a/drivers/media/video/w9968cf.c > +++ b/drivers/media/video/w9968cf.c > @@ -2679,7 +2679,7 @@ static int w9968cf_open(struct inode* inode, struct > file* filp) > > /* This the only safe way to prevent race conditions with disconnect */ > if (!down_read_trylock(&w9968cf_disconnect)) > - return -ERESTARTSYS; > + return -EAGAIN; > > cam = (struct w9968cf_device*)video_get_drvdata(video_devdata(filp)); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] V4L: zc0301, remove bad usage of ERESTARTSYS
acked-by: Luca Risolia <[EMAIL PROTECTED]> On Monday 08 October 2007 14:40:53 Jiri Slaby wrote: > zc0301, remove bad usage of ERESTARTSYS > > down_read_trylock can't be interrupted and so ERESTARTSYS would reach > userspace, which is not permitted. Change it to EAGAIN > > Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> > > --- > commit 235cf594bc65128250632a642f3e9d7e4df4975e > tree 0557746416827daeb4d829610fec2f0c9111a675 > parent db38c559d37219c32b179ae005ca7e489336ec94 > author Jiri Slaby <[EMAIL PROTECTED]> Mon, 08 Oct 2007 14:15:47 +0200 > committer Jiri Slaby <[EMAIL PROTECTED]> Mon, 08 Oct 2007 14:15:47 +0200 > > drivers/media/video/zc0301/zc0301_core.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/video/zc0301/zc0301_core.c > b/drivers/media/video/zc0301/zc0301_core.c index 35138c5..08a93c3 100644 > --- a/drivers/media/video/zc0301/zc0301_core.c > +++ b/drivers/media/video/zc0301/zc0301_core.c > @@ -655,7 +655,7 @@ static int zc0301_open(struct inode* inode, struct > file* filp) int err = 0; > > if (!down_read_trylock(&zc0301_dev_lock)) > - return -ERESTARTSYS; > + return -EAGAIN; > > cam = video_get_drvdata(video_devdata(filp)); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hitachi disk: spurious completions during NCQ
Hello, sometimes kernel complains about spurious completions on my new notebook: ata3.00: exception Emask 0x2 SAct 0x407fd SErr 0x0 action 0x2 frozen ata3.00: spurious completions during NCQ issue=0x0 SAct=0x407fd FIS=005040a1:0002 ata3.00: cmd 61/08:00:c7:5a:82/00:00:1b:00:00/40 tag 0 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:10:3f:5b:fa/00:00:18:00:00/40 tag 2 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:18:5f:5b:fa/00:00:18:00:00/40 tag 3 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/18:20:6f:5b:fa/00:00:18:00:00/40 tag 4 cdb 0x0 data 12288 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:28:e7:19:fd/00:00:18:00:00/40 tag 5 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:30:df:59:ae/00:00:1a:00:00/40 tag 6 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:38:3f:5a:ae/00:00:1a:00:00/40 tag 7 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/08:40:6f:62:ae/00:00:1a:00:00/40 tag 8 cdb 0x0 data 4096 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/28:48:d7:59:7e/00:00:1b:00:00/40 tag 9 cdb 0x0 data 20480 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/10:50:07:5b:82/00:00:1b:00:00/40 tag 10 cdb 0x0 data 8192 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3.00: cmd 61/30:90:f7:5a:fa/00:00:18:00:00/40 tag 18 cdb 0x0 data 24576 out res 50/00:10:07:5b:82/00:00:1b:00:00/40 Emask 0x2 (HSM violation) ata3: soft resetting port ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: configured for UDMA/133 ata3: EH complete sd 2:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) sd 2:0:0:0: [sda] Write Protect is off sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA (this is a very recent 2.6.23-git, SMP, x86_64) The disk is: ATA device, with non-removable media Model Number: Hitachi HTS542525K9SA00 Firmware Revision: BBFOC31P The controller is: 00:1f.2 SATA controller: Intel Corporation Mobile SATA AHCI Controller (rev 03) (prog-if 01 [AHCI 1.0]) Subsystem: ASUSTeK Computer Inc. Unknown device 14e7 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
EIP and VMA
Hi,
I am working on this piece of code (simplified):
void ip_vma(struct task_struct *task, struct pt_regs *regs)
{
struct mm_struct *mm;
struct vm_area_struct *vma;
if(task) {
mm = get_task_mm(task);
if(mm) {
vma = find_vma(mm, regs->eip);
if(vma) {
/* Some code */
}
else
printk("WARNING: No VMA\n");
mmput(mm);
}
}
}
I would like to get instruction pointer's VMA of a task. In order to do so, I
use find_vma function, using regs->eip as instruction pointer value.
Unfortunately I always get "WARNING: No VMA" message because find_vma isn't able
to find the right VMA regs->eip address belongs to.
Is regs->eip the right place where istruction pointer is located or I should
find that value elsewhere?
Thank you,
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
EIP and VMA
Hi,
I am working on this piece of code (simplified):
void ip_vma(struct task_struct *task, struct pt_regs *regs)
{
struct mm_struct *mm;
struct vm_area_struct *vma;
if(task) {
mm = get_task_mm(task);
if(mm) {
vma = find_vma(mm, regs->eip);
if(vma) {
/* Some code */
}
else
printk("WARNING: No VMA\n");
mmput(mm);
}
}
}
I would like to get instruction pointer's VMA of a task. In order to do so, I
use find_vma function, using regs->eip as instruction pointer value.
Unfortunately I always get "WARNING: No VMA" message because find_vma isn't able
to find the right VMA regs->eip address belongs to.
Is regs->eip the right place where istruction pointer is located or I should
find that value elsewhere?
Thank you,
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hello Pavel! On Mon 14 Feb 2005 22:11, Pavel Machek wrote: > Stefan provided me initial list of machines where S3 works (including > video). If you have machine that is not on the list, please send me a > diff. If you have eMachines... I'd like you to try playing with Sorry, but a diff of what? Of the list? > Table of known working systems: > > Model hack (or "how to do it") > -- IBM ThinkPad T42p (2373-GTG [1]) acpi_sleep=s3_bios (2) More info available upon request, but in general: - Debian unstable - vanilla kernel 2.6.10 - ACPI patch 20050125 - BlueZ patch -mh4 - IBM trackpoint patch [2] - radeonfb - radeon XFree86 4.3.0.dfsg.1-11 - all modules my laptop support installed (and loaded ;-) ) - I used a script that switch to vc1 and stop mysql (this is a known problem [3] [4]), then "echo -n [mem|disk] > /sys/power/state" I've a working S4 with the same configuration, too. But it seems I still suffer a problem about hwclock I already reported with another laptop [5] [6]. In this case, the command proposed seems not working anymore (I should test more deeply, just a question of time ;-) ). Anyway, this laptop works very well! I've also a docking station [7], I'll test with it ASAP. Thx, bye, Gismo / Luca [1] http://www5.pc.ibm.com/ch/products.nsf/$wwwPartNumLookup/_UC2GTSE?OpenDocument [2] http://people.clarkson.edu/~evanchsa/ [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=259745 [4] http://bugs.mysql.com/bug.php?id=4596 [5] http://sourceforge.net/mailarchive/message.php?msg_id=9844751 [6] http://sourceforge.net/mailarchive/message.php?msg_id=9864402 [7] http://www5.pc.ibm.com/ch/products.nsf/$wwwPartNumLookup/_74P6733?OpenDocument pgpkSj2De7ysa.pgp Description: PGP signature
Re: [ACPI] Re: Call for help: list of machines with working S3
Hello! On Fri 18 Feb 2005 21:49, Alistair John Strachan wrote: > I discovered that either the i2c_core.ko or i2c_i801.ko modules cause the > hang > on resume! If you stop the entire i2c subsystem from being loaded by hotplug > (note this is the BUS driver, not the sensors driver!), then resume works > perfectly! Presumably there's a bug in the resuming of this module. Well, on my IBM ThinkPad T42p (ATI FireGL T2 128MB), I can resume with both I2C modules loaded, so probably the problem is not specific to the I2C subsystem. > In other news, USB devices only work after I remove uhci_hcd and ehci_hcd and > reload them. I just tested two USB devices after S3 resuming without having removed the USB modules (uhci-hcb and ehci-hcd): - Logitech USB Wheel Mouse (046d:c00c, USB 1.x), it works with no problem on console, but not on X (this was caused by the fact that I've two corepointer on my XF86Config-4, in fact after having corrected this error and restarted X, the USB mouse works) - Mitsubishi Chemical 2.5" HD Case (05e3:0702, USB 2.0 [1], with a SAMSUNG MP0804H 80GB), it works with no problem :-D > The s3_bios workaround allows video to kind of work, but I can't use anything > other than vga=normal (vesafb results in corruption), and the screen is no > longer artificially resized to fill the LCD, it's native res and centered > (which sure is annoying). Again, IMHO the problem is specific to your machine: I use the radeonfb (with acpi_sleep=s3_bios) and the resume is ok (both in console and Debian XFree86-4.3.0.dfsg.1-11, radeon driver). Thx, bye, Gismo / Luca [1] http://www.qbik.ch/usb/devices/showdescr.php?id=3039 pgpFAuFgB8Bft.pgp Description: PGP signature
[RFC] [PATCH] Per-mountpoint read-only and noatime revisited
This patchset implements per-mountpoint readonly, noatime and
nodiratime flags.
This is the first release of the patch and I'm seeking feedback from
the VFS maintainer on whether it is acceptable in principle and which
modifications, if any, I should make (in addition to updating to the
latest bk).
The goals of this patches are the same goals of Herbert Poetzl's ones
(see
http://groups-beta.google.com/group/linux.kernel/browse_frm/thread/46f6ca7ffeac184f/dd31c0959a614cac
and
http://groups-beta.google.com/group/linux.kernel/browse_frm/thread/5d6e8bf49925a180/f2181c51e78b8d56),
but the implementation is very different, although originally based on
his one, and I believe that it addresses the arguments raised against
Poetzl's patches.
In particular, rather than adding extra checks, I modify all calls to
IS_RDONLY, IS_NOATIME and IS_NODIRATIME with ones to a new ..._MNT
macro that makes use of the new flags. All the function calls leading
to the IS_* macro call are changed to pass the struct vfsmount*
through.
Furthermore, this patch adds the new functionality as new mount flags,
rather than overloading the existing per-superblock flags, thus
maintaining backwards compatibility and not breaking remounts or
altering normal bind mount behavior.
On the other hand, unlike Poetzl's patch, my patch changes the
filesystem interface, and will break all out-of-tree filesystems and
modules using vfs_* functions.
In some places the new constant MNT_IGNORE is passed instead of a
struct vfsmount* (the constant is there for clarity and
greppability). All such places either lead to a permission() call
without the MAY_WRITE flag (thus not calling IS_RDONLY), have checks
before them, are per-superblock operations or are one of the issues
described in the next paragraph.
The known issues are:
- lack of support for XFS, due to my inability to figure out how to
implement it: XFS mounts will fully or partially ignore the new
per-mountpoints flags.
- autofs4 could be ignoring per-mountpoint noatime: this is unclear
but very minor
- NFS server should work but I'm not sure if the patch is fully
correct
The first patch adds the base code for the mount interface and macros
and the second patch modifies everything to use the new macros. The
util-linux patch adds userspace support.
In the first patch, I augment the per-superblock s_files list with
per-mountpoint mnt_files list and a s_mnts list of mountpoints for
each superblock; this is done to allow remounting mountpoints
read-only. Furthermore, the mount interfaces are changed to
accomodate the new options and new macros are defined.
In the second patch, the prototypes for fs operations setxattr,
permission and the xattr operation set are changed and core code along
with all filesystems are modified to support the new features.
The util-linux patch is very simple and just adds the flags.
Patches are against 2.6.10: I'll update them if they are considered
acceptable.
The first kernel patch and the util-linux patch follow inline, while
the second patch is gzipped and attached since it is about 120KB
uncompressed.
First patch:
diff --exclude-from=/home/lb/pers/input/exclude -urNdp
--exclude-from=/home/lb/pers/input/exclude-linux
/home/lb/gen/src/linux-2.6.10-pre-bme/fs/dquot.c ./fs/dquot.c
--- /home/lb/gen/src/linux-2.6.10-pre-bme/fs/dquot.c2004-12-24
22:35:14.0 +0100
+++ ./fs/dquot.c2005-01-27 16:29:58.0 +0100
@@ -659,11 +659,11 @@ static int dqinit_needed(struct inode *i
/* This routine is guarded by dqonoff_sem semaphore */
static void add_dquot_ref(struct super_block *sb, int type)
{
- struct list_head *p;
+ struct list_head *mp, *p;
restart:
file_list_lock();
- list_for_each(p, &sb->s_files) {
+ for_each_sfile(p, mp, sb) {
struct file *filp = list_entry(p, struct file, f_list);
struct inode *inode = filp->f_dentry->d_inode;
if (filp->f_mode & FMODE_WRITE && dqinit_needed(inode, type)) {
diff --exclude-from=/home/lb/pers/input/exclude -urNdp
--exclude-from=/home/lb/pers/input/exclude-linux
/home/lb/gen/src/linux-2.6.10-pre-bme/fs/file_table.c ./fs/file_table.c
--- /home/lb/gen/src/linux-2.6.10-pre-bme/fs/file_table.c 2004-12-24
22:33:50.0 +0100
+++ ./fs/file_table.c 2005-01-27 16:29:58.0 +0100
@@ -215,13 +215,12 @@ void file_kill(struct file *file)
}
}
-int fs_may_remount_ro(struct super_block *sb)
+int __list_may_remount_ro(struct list_head* list)
{
struct list_head *p;
/* Check that no files are currently opened for writing. */
- file_list_lock();
- list_for_each(p, &sb->s_files) {
+ list_for_each(p, list) {
struct file *file = list_entry(p, struct file, f_list);
struct inode *inode = file->f_dentry->d_inode;
@@ -233,6 +232,33 @@ int fs_may_remount_ro(struct super_block
if (S_ISREG(inode->i_mode) && (file->f_mode & FMODE_WRIT
Re: status of the USB w9968cf.c driver in kernel 2.6?
Scrive Adrian Bunk <[EMAIL PROTECTED]>: > I noticed the following regarding the drivers/usb/media/ov511.c driver: ^^^ > - it's not updated compared to upstream: Could you provide more details? > - there's no w9968cf-vpp module in the kernel sources w9968cf-vpp is an optional, gpl'ed module, which can not be included in the mainline kernel, as I explained in the documentation of the driver. Regards, Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: status of the USB w9968cf.c driver in kernel 2.6?
Scrive Adrian Bunk <[EMAIL PROTECTED]>: > On Tue, Mar 01, 2005 at 06:46:03PM +0100, Luca Risolia wrote: > > Scrive Adrian Bunk <[EMAIL PROTECTED]>: > > > > > I noticed the following regarding the drivers/usb/media/ov511.c driver: > > ^^^ > > > - it's not updated compared to upstream: > > > > Could you provide more details? > > Sorry, my fault. > I confused this with a different driver. > > > > - there's no w9968cf-vpp module in the kernel sources > > > > w9968cf-vpp is an optional, gpl'ed module, which can not be included in the > > > mainline kernel, as I explained in the documentation of the driver. > > Please keep in mind that official kernels do not include the second > module for performance purposes. > > What exactly does this mean? Frame decoding/decompression should be done in userspace, although you can still download and use a separate kernel module. > > Is it useful or not? Yes Regards, Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Some questions about VM flags
I was playing with mprotect and VM flags when I noticed two curious behaviours.
1)
This C program modifies data segments's flags:
#include
#include
/* Values shown by /proc//maps */
#define START 0x08049000
#define END 0x0804a000
int target;
int main(void)
{
printf("ADDRESS: %p\n", &target);
target = 1;
mprotect((void *)START, END - START, PROT_WRITE);
printf("%d\n", target);
return 0;
}
After the mprotect call, data segment's flags are
08049000-0804a000 -w-p 03:06 297330 /home/dktrkranz/vmflags_read
Shouldn't printf generate a segfault trying to read a variabile located in a
write-only area?
2)
This C program tries to execute a shellcode:
/* This shellcode calls write and exit. It's harmless ;) */
char shellcode[] =
"\x31\xc0\x31\xdb\x31\xd2\x53\x68\x7a\x0a\x00\x00\x68\x4b\x72"
"\x61\x6e\x68\x44\x6b\x74\x72\x89\xe1\xb2\x0a\xb0\x04\xcd\x80"
"\x31\xc0\x31\xdb\xb0\x01\xcd\x80";
int main(void)
{
void(*sc)(void);
sc = (void *)&shellcode;
sc();
return 0;
}
These are data segment's flags:
08049000-0804a000 rw-p 03:06 297330 /home/dktrkranz/vmflags_sc
Shellcode lies in this segment. It is executed even if VM_EXEC isn't set. I
think execution shouldn't be permitted if only VM_READ or VM_WRITE flags are
set. Buffer overflows/format string based exploits wouldn't be so popular if we
implemented this feaure. Please let me know your opinion.
Thank you,
Luca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] RCU in kernel/intermodule.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch, compiled against version 2.6.12-rc1, implements RCU mechanism in
intermodule functions.
Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]>
- --- ./kernel/intermodule.c.orig 2005-04-01 19:25:26.0 +
+++ ./kernel/intermodule.c 2005-04-02 02:46:22.0 +
@@ -3,7 +3,7 @@
/* Written by Keith Owens Oct 2000 */
#include
#include
- -#include
+#include
#include
#include
@@ -14,7 +14,6 @@
*/
static struct list_head ime_list = LIST_HEAD_INIT(ime_list);
- -static DEFINE_SPINLOCK(ime_lock);
static int kmalloc_failed;
struct inter_module_entry {
@@ -22,8 +21,17 @@ struct inter_module_entry {
const char *im_name;
struct module *owner;
const void *userdata;
+ struct rcu_head rcu;
};
+static void inter_module_free(struct rcu_head *rcu)
+{
+ struct inter_module_entry *ime;
+
+ ime = container_of(rcu, struct inter_module_entry, rcu);
+ kfree(ime);
+}
+
/**
* inter_module_register - register a new set of inter module data.
* @im_name: an arbitrary string to identify the data, must be unique
@@ -36,7 +44,6 @@ struct inter_module_entry {
*/
void inter_module_register(const char *im_name, struct module *owner, const
void *userdata)
{
- - struct list_head *tmp;
struct inter_module_entry *ime, *ime_new;
if (!(ime_new = kmalloc(sizeof(*ime), GFP_KERNEL))) {
@@ -52,19 +59,15 @@ void inter_module_register(const char *i
ime_new->owner = owner;
ime_new->userdata = userdata;
- - spin_lock(&ime_lock);
- - list_for_each(tmp, &ime_list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ list_for_each_entry(ime, &ime_list, list) {
if (strcmp(ime->im_name, im_name) == 0) {
- - spin_unlock(&ime_lock);
kfree(ime_new);
/* Program logic error, fatal */
printk(KERN_ERR "inter_module_register: duplicate
im_name '%s'", im_name);
BUG();
}
}
- - list_add(&(ime_new->list), &ime_list);
- - spin_unlock(&ime_lock);
+ list_add_rcu(&ime_new->list, &ime_list);
}
/**
@@ -77,20 +80,15 @@ void inter_module_register(const char *i
*/
void inter_module_unregister(const char *im_name)
{
- - struct list_head *tmp;
struct inter_module_entry *ime;
- - spin_lock(&ime_lock);
- - list_for_each(tmp, &ime_list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ list_for_each_entry(ime, &ime_list, list) {
if (strcmp(ime->im_name, im_name) == 0) {
- - list_del(&(ime->list));
- - spin_unlock(&ime_lock);
- - kfree(ime);
+ list_del_rcu(&(ime->list));
+ call_rcu(&ime->rcu, inter_module_free);
return;
}
}
- - spin_unlock(&ime_lock);
if (kmalloc_failed) {
printk(KERN_ERR
"inter_module_unregister: no entry for '%s', "
@@ -115,20 +113,18 @@ void inter_module_unregister(const char
*/
static const void *inter_module_get(const char *im_name)
{
- - struct list_head *tmp;
struct inter_module_entry *ime;
const void *result = NULL;
- - spin_lock(&ime_lock);
- - list_for_each(tmp, &ime_list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ rcu_read_lock();
+ list_for_each_entry_rcu(ime, &ime_list, list) {
if (strcmp(ime->im_name, im_name) == 0) {
if (try_module_get(ime->owner))
result = ime->userdata;
break;
}
}
- - spin_unlock(&ime_lock);
+ rcu_read_unlock();
return(result);
}
@@ -158,20 +154,18 @@ const void *inter_module_get_request(con
*/
void inter_module_put(const char *im_name)
{
- - struct list_head *tmp;
struct inter_module_entry *ime;
- - spin_lock(&ime_lock);
- - list_for_each(tmp, &ime_list) {
- - ime = list_entry(tmp, struct inter_module_entry, list);
+ rcu_read_lock();
+ list_for_each_entry(ime, &ime_list, list) {
if (strcmp(ime->im_name, im_name) == 0) {
if (ime->owner)
module_put(ime->owner);
- - spin_unlock(&ime_lock);
+ rcu_read_unlock();
return;
}
}
- - spin_unlock(&ime_lock);
+ rcu_read_unlock();
printk(KERN_ERR "inter_module_put: no entry
Re: [PATCH] Kprobes /proc entry
int i, err = 0;
@@ -140,6 +225,20 @@
for (i = 0; i < KPROBE_TABLE_SIZE; i++)
INIT_HLIST_HEAD(&kprobe_table[i]);
+ kprobes_dir = debugfs_create_dir("kprobes", NULL);
+ if(!kprobes_dir) {
+ printk("kprobes: could not create debugfs entry\n");
+ goto finish;
+ }
+ kprobes_list = debugfs_create_file("list", S_IRUGO, kprobes_dir,
+ NULL, &kprobes_fops);
+ if(!kprobes_list) {
+ printk("kprobes: could not create debugfs entry\n");
+ debugfs_remove(kprobes_dir);
+ goto finish;
+ }
+
+finish:
err = register_die_notifier(&kprobe_exceptions_nb);
return err;
}
Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]>
Regards,
Luca
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQEVAwUBQevumBZrwl7j21nOAQL46Af/apeTfTYuXvDdhWFsqWI7QBqpmYkj9+iu
S4A2EKsBUUlnlcZrpL08lqwMup2H8jt3zjmmCcPn2Oplr054aHIDIQveu5XMA+jJ
9w5EdDf3SZcPF+HEPmN9EV5n0BakVwGERM/8615jH804Y5IJtB8b79XMmU8wLI8x
M4JGa+kwboD260IbWRuxfRUVqJMMVL5Mibin0RFN4WCbJYfxPhDiCsH2HGNgrw1Y
m0uyuaUt4pynAVPpHJPAKPylwY/A9MC7/Zdfa2IIO118bNxKaFTMg0z+AN66jUwz
kRUzxoUfDv3kIhzkHwvyPX9hjsoSPof/xQZwxclz8p6Yz00KICdZRw==
=Ka0n
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [fuse-devel] Merging?
Il Wed, 12 Jan 2005 11:01:09 -0800, Andrew Morton <[EMAIL PROTECTED]> ha scritto: > Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > > Well, there doesn't seem to be a great rush to include FUSE in the > > kernel. Maybe they just don't realize what they are missing out on ;) > > heh. What userspace filesystems have thus-far been developed, and what are > people using them for? For my master laurea thesis I developed PackageFS that aims to transparently manage packages in several distros. There are also many other facilities: - View a directory-based tree of packages (with the files that each package owns) which can be nested by category, or by priority In the future - you will be able to add users to "packages" group to make them able to manage packages - you can mount the file system on a cluster to transparently manage several hosts You can find my thesis at http://packagefs.sourceforge.net I think FUSE is a very good idea (as good as the actual implementation is), IMHO it should be inserted in the mainline kernel. Thanks to Miklos and other developers. Luca -- Non ci toglieranno maila LIBERTA'!!! Luca Ferroni ICQ #317977679 www.cs.unibo.it/~fferroni/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Kprobes /proc entry
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greg KH ha scritto:
> Also, why not use the seqfile interface for this, to prevent overflowing
> the read buffer?
Great idea!
> Am I missing where you allocate the space for the data to be put into?
seq_read does the job now. It manages to allocate PAGE_SIZE bytes.
Assuming function, hook and module names occupy KSYM_NAME_LEN bytes each,
maximum length will be 424 bytes for each kprobe. I don't think it would be
useful to allocate more memory than PAGE_SIZE. Please, let me know your opinion.
- --- ./kernel/kprobes.c2005-01-19 11:03:03.0 +0100
+++ ./kernel/kprobes.c 2005-01-20 15:02:47.0 +0100
@@ -33,6 +33,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#include
#include
@@ -45,6 +49,13 @@
unsigned int kprobe_cpu = NR_CPUS;
static DEFINE_SPINLOCK(kprobe_lock);
+static char *ktype[] = {
+ "PRE",
+ "POST",
+ "FAULT",
+ "BREAK",
+};
+
/* Locks kprobe: irqs must be disabled */
void lock_kprobes(void)
{
@@ -131,15 +142,92 @@
unregister_kprobe(&jp->kp);
}
+static void kprobes_print(struct seq_file *seq, unsigned long addr,
+ unsigned long handler, int type)
+{
+ char *module, namebuf[KSYM_NAME_LEN+1];
+ const char *hook, *func;
+ unsigned long off, size;
+
+ func = kallsyms_lookup(addr, &size, &off, &module, namebuf);
+ seq_printf(seq, "%s\t0x%lx(%s+%#lx)\t", ktype[type], addr, func, off);
+ hook = kallsyms_lookup(handler, &size, &off, &module, namebuf);
+ seq_printf(seq, "0x%lx(%s)\t%s\n", handler, hook,
+ strlen(module) ? module : "[built-in]");
+}
+
+static int kprobes_show(struct seq_file *seq, void *unused)
+{
+ int i;
+ struct kprobe *k;
+ struct hlist_node *node;
+ unsigned long addr, handler;
+
+ spin_lock(&kprobe_lock);
+ for(i = 0; i < KPROBE_TABLE_SIZE; i++) {
+ hlist_for_each_entry(k, node, &kprobe_table[i], hlist) {
+ if(!k)
+ continue;
+ addr = (unsigned long)k->addr;
+ if(k->pre_handler) {
+ handler = (unsigned long)k->pre_handler;
+ kprobes_print(seq, addr, handler, PRE);
+ }
+ if(k->post_handler) {
+ handler = (unsigned long)k->post_handler;
+ kprobes_print(seq, addr, handler, POST);
+ }
+ if(k->fault_handler) {
+ handler = (unsigned long)k->fault_handler;
+ kprobes_print(seq, addr, handler, FAULT);
+ }
+ if(k->break_handler) {
+ handler = (unsigned long)k->break_handler;
+ kprobes_print(seq, addr, handler, BREAK);
+ }
+ }
+ }
+ spin_unlock(&kprobe_lock);
+ return 0;
+}
+
+static int kprobes_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, kprobes_show, NULL);
+}
+
+static struct file_operations kprobes_fops = {
+ .open = kprobes_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .owner = THIS_MODULE
+};
+
static int __init init_kprobes(void)
{
int i, err = 0;
+ struct dentry *kprobes_dir, *kprobes_list;
/* FIXME allocate the probe table, currently defined statically */
/* initialize all list heads */
for (i = 0; i < KPROBE_TABLE_SIZE; i++)
INIT_HLIST_HEAD(&kprobe_table[i]);
+ kprobes_dir = debugfs_create_dir("kprobes", NULL);
+ if(!kprobes_dir) {
+ printk("kprobes: could not create debugfs entry\n");
+ goto finish;
+ }
+ kprobes_list = debugfs_create_file("list", S_IRUGO, kprobes_dir,
+ NULL, &kprobes_fops);
+ if(!kprobes_list) {
+ printk("kprobes: could not create debugfs entry\n");
+ debugfs_remove(kprobes_dir);
+ goto finish;
+ }
+
+finish:
err = register_die_notifier(&kprobe_exceptions_nb);
return err;
}
- --- ./include/linux/kprobes.h 2005-01-03 20:40:51.0 +0100
+++ ./include/linux/kprobes.h 2005-01-20 13:59:27.0 +0100
@@ -82,6 +82,13 @@
kprobe_opcode_t *entry; /* probe handling code to jump to */
};
+enum kprobe_type {
+ PRE=0,
+ POST,
+ FAULT,
+ BREAK,
+};
+
#ifdef CONFIG_KPROBES
/
sitecom wl162
Add support to wireless usb key sitecom wl162
in ./drivers/net/wireless/zd1211rw/zd_usb.c
added srtuct { USB_DEVICE(0x0cde, 0x001a), .driver_info = DEVICE_ZD1211B },
I've to do it by myself every time i update kernel. Please add it.
Thank you
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc4: BAD regression
Il Wed, Aug 29, 2007 at 01:29:56AM +0200, Daniel Ritz ha scritto: > tried that one on my old toshiba tecra 8000 laptop, almost killing it. > the fan doesn't work any more...type 'make' and see the box dying. > luckily my CPU doesn't commit suicide...bisected it to that one: > > cd8c93a4e04dce8f00d1ef3a476aac8bd65ae40b is first bad commit I've just bisected down to the same commit. In my case the fan is locked at maximum speed and the system is *extremly* slow (some kind of throttling?). Alexey, I've seen the patch, I'll test it tomorrow and report back. Luca -- Tentare e` il primo passo verso il fallimento. Homer J. Simpson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] pata_ali not working on a 64 bit system
Il Fri, Jul 06, 2007 at 10:01:36PM +0200, Luca Tettamanti ha scritto: > Il Fri, Jul 06, 2007 at 06:44:02PM +0100, Alan Cox ha scritto: > > On Fri, 6 Jul 2007 19:36:05 +0200 > > Luca Tettamanti <[EMAIL PROTECTED]> wrote: > > > > > Hello, > > > I found out that pata_ali is not working with a 64 bit kernel, while a > > > 32 bit kernel on the same machine works fine. I'm running a very recent > > > kernel (872aad45, somewhere after 2.6.22-rc7). I found out that 2.6.21 works fine. I'll start bisecting unless someone has some clue about this issue. I'm quoting the rest of my mail for reference: > > > The problem is that as soon as the module is loaded I get a screaming > > > interrupt: > > > > Can you report this with a full dmesg to the ACPI maintainers as that is > > where the IRQ routing is presumably coming from. > > Ok, adding linux-acpi to CC. > > > Are you using ACPI on both cases ? > > By default it's enabled, but I've also tried with pci=noacpi without > success. That's why I reported the issue on linux-ide ;) > > To recap, with ACPI enabled: > > 32bit: pata_ali gets IRQ 19, works > 64bit: pata_ali gets IRQ 23, doesn't work, screaming interrupt 64bit 2.6.21 also gets IRQ 23, but no screaming interrupt. > > With pci=noacpi: > > 32bit: pata_ali gets IRQ 23, works > 64bit: pata_ali gets IRQ 23, doesn't work, screaming interrupt > > (as a side note: in this case pata_jmicron stops working...) > > When ACPI is enabled IRQ mapping differs between 32 and 64 bit: > > -ACPI: PCI Interrupt :05:02.1[A] -> GSI 23 (level, low) -> IRQ 19 > +ACPI: PCI Interrupt :05:02.1[A] -> GSI 23 (level, low) -> IRQ 23 > > while with pci=noacpi the IRQ mapping for both 32 and 64 bit is the > following: > > PCI: Probing PCI hardware > PCI quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO > PCI quirk: region 0480-04bf claimed by ICH6 GPIO > PCI: Firmware left :05:01.0 e100 interrupts enabled, disabling > PCI: Transparent bridge - :00:1e.0 > PCI: Using IRQ router PIIX/ICH [8086/2810] at :00:1f.0 > PCI->APIC IRQ transform: :00:01.0[A] -> IRQ 16 > PCI->APIC IRQ transform: :00:1a.0[A] -> IRQ 16 > PCI->APIC IRQ transform: :00:1a.1[B] -> IRQ 17 > PCI->APIC IRQ transform: :00:1a.7[C] -> IRQ 18 > PCI->APIC IRQ transform: :00:1b.0[A] -> IRQ 22 > PCI->APIC IRQ transform: :00:1c.0[A] -> IRQ 16 > PCI->APIC IRQ transform: :00:1c.3[D] -> IRQ 19 > PCI->APIC IRQ transform: :00:1c.4[A] -> IRQ 16 > PCI->APIC IRQ transform: :00:1d.0[A] -> IRQ 23 > PCI->APIC IRQ transform: :00:1d.1[B] -> IRQ 19 > PCI->APIC IRQ transform: :00:1d.2[C] -> IRQ 18 > PCI->APIC IRQ transform: :00:1d.7[A] -> IRQ 23 > PCI->APIC IRQ transform: :00:1f.2[B] -> IRQ 19 > PCI->APIC IRQ transform: :00:1f.3[C] -> IRQ 18 > PCI->APIC IRQ transform: :01:00.0[A] -> IRQ 16 > PCI->APIC IRQ transform: :03:00.0[A] -> IRQ 19 > PCI->APIC IRQ transform: :02:00.0[A] -> IRQ 16 > PCI->APIC IRQ transform: :02:00.1[B] -> IRQ 16 > PCI->APIC IRQ transform: :05:01.0[A] -> IRQ 22 > PCI->APIC IRQ transform: :05:02.0[A] -> IRQ 23 > PCI->APIC IRQ transform: :05:02.1[A] -> IRQ 23 > PCI->APIC IRQ transform: :05:03.0[A] -> IRQ 21 > > For reference the dmesg for 64 kernel with ACPI enabled is the > following: > > Linux version 2.6.22-rc7-64-g872aad45-dirty ([EMAIL PROTECTED]) (gcc version > 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #14 SMP PREEMPT Tue Jul 3 > 21:18:19 CEST 2007 > Command line: BOOT_IMAGE=linux-2.6.22-64 ro video=radeonfb:[EMAIL PROTECTED] > lapic apic=verbose root=/dev/mapper/mainVol-root console=tty0 > console=ttyS0,57600n8 break=modules > BIOS-provided physical RAM map: > BIOS-e820: - 0009c800 (usable) > BIOS-e820: 0009c800 - 000a (reserved) > BIOS-e820: 000e4000 - 0010 (reserved) > BIOS-e820: 0010 - 3ff9 (usable) > BIOS-e820: 3ff9 - 3ff9e000 (ACPI data) > BIOS-e820: 3ff9e000 - 3ffe (ACPI NVS) > BIOS-e820: 3ffe - 4000 (reserved) > BIOS-e820: fee0 - fee01000 (reserved) > BIOS-e820: ffb0 - 0001 (reserved) > end_pfn_map = 1048576 > DMI 2.4 present. > ACPI: RSDP 000FA980, 0024 (r2 ACPIAM) > ACPI: XSDT 3FF90100, 0054 (r1 KOZIRO FRONTIER 12000611 MSFT 97) > ACPI: FACP 3FF90290, 00F4 (r3 MSTEST OEMFACP 12000611 MSFT 97) >
Re: [PATCH 4/5] UML - Simplify helper stack handling
Il Wed, Jun 27, 2007 at 11:37:01PM -0700, Andrew Morton ha scritto: > > So I'm running the generic version of this on i386 with 8k stacks (below), > with a quick LTP run. > > Holy cow, either we use a _lot_ of stack or these numbers are off: > > vmm:/home/akpm> dmesg -s 100|grep 'bytes left' > khelper used greatest stack depth: 7176 bytes left > khelper used greatest stack depth: 7064 bytes left > khelper used greatest stack depth: 6840 bytes left > khelper used greatest stack depth: 6812 bytes left > hostname used greatest stack depth: 6636 bytes left > uname used greatest stack depth: 6592 bytes left > uname used greatest stack depth: 6284 bytes left > hotplug used greatest stack depth: 5568 bytes left > rpc.nfsd used greatest stack depth: 5136 bytes left > chown02 used greatest stack depth: 4956 bytes left > fchown01 used greatest stack depth: 4892 bytes left > > That's the sum of process stack and interrupt stack, but I doubt if this > little box is using much interrupt stack space. > > No wonder people are still getting stack overflows with 4k stacks... Hi Andrew, I was a bit worried about stack usage on my setup and google found your mail :P FYI: khelper used greatest stack depth: 3228 bytes left khelper used greatest stack depth: 3124 bytes left busybox used greatest stack depth: 2808 bytes left modprobe used greatest stack depth: 2744 bytes left busybox used greatest stack depth: 2644 bytes left modprobe used greatest stack depth: 1836 bytes left modprobe used greatest stack depth: 1176 bytes left java used greatest stack depth: 932 bytes left java used greatest stack depth: 540 bytes left I'm running git-current, with 4KiB stacks; filesystems are ext3 and XFS on LVM (on libata devices). Does it make sense to raise STACK_WARN to get a stack trace in do_IRQ? Or is 540 bytes still "safe" taking into account the separate IRQ stack? Luca -- 42 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] - SN: Add support for CPU disable
Hi,
I've a couple of comments on the patch:
John Keller <[EMAIL PROTECTED]> ha scritto:
> Index: linux-2.6/arch/ia64/sn/kernel/huberror.c
> ===
> --- linux-2.6.orig/arch/ia64/sn/kernel/huberror.c 2007-07-31
> 09:09:55.414522005 -0500
> +++ linux-2.6/arch/ia64/sn/kernel/huberror.c2007-07-31 09:38:14.634045360
> -0500
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include "xtalk/xwidgetdev.h"
> #include "xtalk/hubdev.h"
> #include
> @@ -185,11 +186,22 @@ void hubiio_crb_error_handler(struct hub
> */
> void hub_error_init(struct hubdev_info *hubdev_info)
> {
> +
>if (request_irq(SGI_II_ERROR, hub_eint_handler, IRQF_SHARED,
> - "SN_hub_error", (void *)hubdev_info))
> + "SN_hub_error", (void *)hubdev_info)) {
>printk("hub_error_init: Failed to request_irq for 0x%p\n",
>hubdev_info);
> - return;
> + return;
> + }
> +
> +#ifdef CONFIG_SMP
> + /*
> +* On systems which support CPU disabling (SHub2), all error
> interrupts
> +* are targetted at the boot CPU.
> +*/
> + if (is_shub2() && sn_prom_feature_available(PRF_CPU_DISABLE_SUPPORT))
> + set_irq_affinity_info(SGI_II_ERROR, 0, 0);
> +#endif
This snippet is repeated many times. You may want to use an inline
helper (defined as no-op for !CONFIG_SMP), something like this:
#ifdef CONFIG_SMP
static inline void migrate_error_int(void)
{
/*
* On systems which support CPU disabling (SHub2), all error interrupts
* are targetted at the boot CPU.
*/
if (is_shub2() && sn_prom_feature_available(PRF_CPU_DISABLE_SUPPORT))
set_irq_affinity_info(SGI_II_ERROR, 0, 0);
}
#else
static inline void migrate_error_int(void) { }
#endif
As as bonus you remove the #ifdef from the main code.
> --- linux-2.6.orig/arch/ia64/sn/kernel/sn2/sn2_smp.c2007-07-31
> 09:09:55.418522496 -0500
> +++ linux-2.6/arch/ia64/sn/kernel/sn2/sn2_smp.c 2007-07-31 09:38:14.782063615
> -0500
> @@ -40,6 +40,7 @@
> #include
> #include
> #include
> +#include
>
> DEFINE_PER_CPU(struct ptc_stats, ptcstats);
> DECLARE_PER_CPU(struct ptc_stats, ptcstats);
> @@ -429,6 +430,29 @@ void sn2_send_IPI(int cpuid, int vector,
>sn_send_IPI_phys(nasid, physid, vector, delivery_mode);
> }
>
> +#ifdef CONFIG_HOTPLUG_CPU
> +/**
> + * sn_cpu_disable_allowed - Determine if a CPU can be disabled.
> + * @cpu - CPU that is requested to be disabled.
> + *
> + * CPU disable is only allowed on SHub2 systems running with a PROM
> + * that supports CPU disable. It is not permitted to disable the boot
> processor.
> + */
> +bool sn_cpu_disable_allowed(int cpu)
> +{
> + if (is_shub2() && sn_prom_feature_available(PRF_CPU_DISABLE_SUPPORT))
> + if (cpu != 0)
> + return true;
> + else
> + printk("Disabling the boot processor is not
> allowed.\n");
> +
> + else
Hum, brackets around the inner if statement?
Luca
--
Let me make your mind, leave yourself behind
Be not afraid
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
