[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 2007-11-25 03:43:35.0 +0100
@@
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: patch reverting to 2.6.22 behavior 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/
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: 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: 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- TAbort- MAbort- SERR- PERR- 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/
[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/
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/
[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/
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: [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: [f1b68d02] kvm_dev_ioctl+0x113/0xf97
[kvm]
[b015c32a] 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: [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] [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: [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: [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: 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: [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.comforum_name=atl1-devel Asus P5K (LGA775):2 reports of lockups http://sourceforge.net/mailarchive/forum.php?thread_name=467E7E34.4010603%40gmail.comforum_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: [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: 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: 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/
[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,
_read, _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,
> > _read, _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,
_read, _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,
_read, _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: [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: (>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: [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: [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: [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: 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: 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: 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: [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: [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: [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_name=atl1-devel > > Asus P5K (LGA775):2 reports of lockups > http://sourceforge.net/mailarchive/forum.php?thread_name=467E7E34.4010603%40gmail.com_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: [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: [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: 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: [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/
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/
[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
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
[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/
[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/
[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/
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: 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: 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 * PROTO: *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/
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/
[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/
[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/
Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?
Il Sun, Apr 15, 2007 at 06:57:02PM -0600, Bjorn Helgaas ha scritto: On Sunday 15 April 2007 14:59, Luca Tettamanti wrote: On 4/15/07, Bjorn Helgaas [EMAIL PROTECTED] wrote: But I missed the details, such as the specific devices in question, which ports they use, how they are described in ACPI, which AML methods use those ports, and which non-ACPI drivers also use them. The original report was about the temperature sensors of K8 cpus. It happens that ACPI reads the sensors while the linux driver is using it and gets garbage (and shut down the system). The problem is more generic though, and applies to all hardware monitoring chips for which a driver exists. Yes, I saw that much, but that's not enough detail to craft a good solution. In the case of k8temp, the driver claims PCI devices with a certain vendor and device ID. PCI devices are mostly outside the scope of ACPI. There's a standard enumeration protocol, and a driver should be able to claim any device it recognizes without fear of conflict. I claim that an AML method that accesses a PCI device is defective because the AML can't know whether a native driver has claimed the device. k8temp seems a special case tough. Sometimes the firmware can hide PCI devices so the OS enumeration doesn't find them. In that case, AML might be able to safely use the PCI device, but the native driver wouldn't be able to claim the device, so there would be no conflict. (Linux sometimes uses quirks to unhide things like this, which could lead to a conflict of our own making.) I suspect that other sensor drivers may just probe for devices at known addresses hard-coded in the driver. Usually sensors are attached to SMBUS or available in ISA IO space. AFAIK they're not enumerated anywhere (at least I2C devices are not, you poke at various addresses and see if something responds - not sure about ISA). This is a problem because the ACPI model is that the OS learns about all built-in devices via the ACPI namespace. If it isn't in the namespace, it shouldn't exist as far as the OS is concerned. So we could easily have the situation where ACPI uses a sensor and does not expose it to the OS in the namespace. In that case, the firmware expectation is that the OS won't touch the device. If the OS pokes around at the magic addresses and happens to trip over the device, we just made ourselves a problem. It also sounds like the non-ACPI drivers provide much more functionality than ACPI exposes. I'd like to understand this, too, because an obvious way to solve the problem would be to drop the non-ACPI drivers. Problem is that ACPI may access the sensors anyway (e.g. via SMM). If ACPI accesses sensors but there is no native driver, there should be no conflict. Of course. But we do have native drivers ;-) Is this extra functionality available on Windows? If so, do we know whether Windows uses non-ACPI drivers or whether they have some smarter way to use ACPI? Usually ACPI exposes 1 or 2 temperature readings (CPU and motherboard), while the hw driver can also provide fans and voltages measurements. Vendors usually provides a monitoring utility for Win that also exposes these information. It's not known whether there's a way to avoid conflicting accesses between ACPI and the raw driver; it's possible that it's vendor-specific and not documented. I'd be surprised if Windows provided interfaces to coordinate between two drivers. My impression is that they really want to have a single owner for a piece of hardware. It would be interesting to figure out how these monitoring utilities work. Maybe the monitor and the AML both go through an embedded controller driver and coordinate that way? Hum, the utility I have here (Asus PC Probe) seems to use ACPI: Pro2.dll: [Ordinal/Name Pointer] Table [ 11] OCAPI_ACPI_OC_PresetList [ 12] OCAPI_ACPI_OC__MB_GetBoardName [ 23] OCAPI_CheckAiGear [ 0] OCAPI_CheckIntelPowerSaving [ 6] OCAPI_CheckWorkable [ 2] OCAPI_Close [ 9] OCAPI_EnableQFan [ 16] OCAPI_GENERAL_GetList [ 14] OCAPI_GetCpuVoltRange [ 13] OCAPI_GetCurrentCpuFrequency [ 15] OCAPI_GetFanStartTemp [ 3] OCAPI_GetHealthData [ 4] OCAPI_GetHwSensorData [ 22] OCAPI_GetMBIF [ 8] OCAPI_GetQFanInfo [ 5] OCAPI_HW_EnumerateOption [ 7] OCAPI_HideQFan [ 1] OCAPI_Initialization [ 19] OCAPI_NQFAN_GetData [ 21] OCAPI_NQFAN_GetList [ 20] OCAPI_NQFAN_SetData [ 17] OCAPI_QFAN_GetData [ 18] OCAPI_QFAN_SetData [ 10] OCAPI_SetQFanTarget [ 24] ___CPPdebugHook ASiO.dll: [Ordinal/Name Pointer] Table [ 1] ASIO_Close [ 9] ASIO_GetCpuID [ 3] ASIO_InPortB [ 5] ASIO_InPortD [ 7] ASIO_MapMem [ 0
Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?
On 4/17/07, Bjorn Helgaas [EMAIL PROTECTED] wrote: On Monday 16 April 2007 15:14, Luca Tettamanti wrote: Problem is that ACPI methods are not documented at all (how am I supposed to know that G6T6 is the reading of the 12V rail?) while the datasheet of hw monitoring chips (w83627ehf in my case) are public (more or less). Yes, I see that it's attractive to use a single w83627ehf.c driver. For an ACPI driver, we'd have to build a list of PNP IDs, and possibly information about which methods read which information. That's certainly more work. On the other hand, the ACPI driver would avoid the synchronization issues that started this whole thread. That's a pretty compelling advantage. Furthermore, sensor driver exposes all the reading of the chip (e.g. in the DSDT I can't find the VSB or battery voltage). Maybe Asus didn't hook up those readings on the board. I would guess that PC Probe doesn't expose the VSB or battery voltage either. PC Probe does not. But the lines are wired and the readings (from Linux) are sensible. I'm sure you've seen these: http://lists.lm-sensors.org/pipermail/lm-sensors/2005-October/014050.html http://www.lm-sensors.org/wiki/AsusFormulaHacking Actually I haven't, I've happily ignored ACPI until now ;-) My DSDT doesn't look too bad, I may give it a try... 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: [BUG? -rc7] SMP: Just one CPU activated: P4 3GHz HT
Miguel Ojeda [EMAIL PROTECTED] ha scritto: On 4/22/07, oliver pinter [EMAIL PROTECTED] wrote: I have CC the kernel Did you? and the result is: your'e config : failed smp your'e config + power managment : ok Interesting, can anyone tell me why does not SMP work without Power Managment? Should it be that way? Probably the two siblings are enumerated only in ACPI tables. If you disable ACPI the kernel won't be aware of the second core. Luca -- Su cio` di cui non si puo` parlare e` bene tacere. Ludwig Wittgenstein - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Could the k8temp driver be interfering with ACPI?
Il Wed, Apr 18, 2007 at 01:50:29AM +0200, Luca Tettamanti ha scritto:
I'm sure you've seen these:
http://lists.lm-sensors.org/pipermail/lm-sensors/2005-October/014050.html
http://www.lm-sensors.org/wiki/AsusFormulaHacking
Actually I haven't, I've happily ignored ACPI until now ;-) My DSDT
doesn't look too bad, I may give it a try...
It wasn't hard :) Temperature reading works fine. AML code is still a
bit obscure though: the reading are enumerated in two different
sections:
* TSIF, FSIF, VSIF: they have read/write methods, easy to understand (I'm
using these right now)
* SITM/GITM and GGPR for enumeration: more settings are available and in
part they overlap the others. The methods are very strange, for e.g.
temperature GITM (which calls GIT6) returns a hard-coded magic value;
other methods (e.g. CPU frequency, Q-FAN settings) write a random
number somewhere in the system memory and return an obscure magic
value... very cool :)
I'm posting the proof-of-concept driver. A few notes:
- only temperature reading is implemented: I just got my MS degree so
I've been drun^Wbusy
- sysfs files are still RO
- coding style: yes, I know... will cleanup
- There's a gazillion of debugging printk's :)
- I've extended the hwmon sysfs interface, with a new temp%d_name;
ACPI knows how the sensor is wired
- You'll need the following patch (against current Linus' git):
diff --git a/drivers/acpi/namespace/nsutils.c b/drivers/acpi/namespace/nsutils.c
index 90fd059..97e1139 100644
--- a/drivers/acpi/namespace/nsutils.c
+++ b/drivers/acpi/namespace/nsutils.c
@@ -700,6 +700,7 @@ struct acpi_namespace_node
*acpi_ns_map_handle_to_node(acpi_handle handle)
return (ACPI_CAST_PTR(struct acpi_namespace_node, handle));
}
+EXPORT_SYMBOL(acpi_ns_map_handle_to_node);
/***
*
@@ -736,6 +737,7 @@ acpi_handle acpi_ns_convert_entry_to_handle(struct
acpi_namespace_node *node)
return ((acpi_handle) Node);
--*/
}
+EXPORT_SYMBOL(acpi_ns_convert_entry_to_handle);
/***
*
@@ -875,6 +877,7 @@ acpi_ns_get_node(struct acpi_namespace_node *prefix_node,
ACPI_FREE(internal_path);
return_ACPI_STATUS(status);
}
+EXPORT_SYMBOL(acpi_ns_get_node);
/***
*
Now the driver:
/*
* Copyright (C) 2007 Luca Tettamanti [EMAIL PROTECTED]
* Distribute under GPLv2.
*/
#include linux/module.h
#include linux/kernel.h
#include linux/hwmon.h
#include acpi/acpi.h
#include acpi/acnamesp.h
#include acpi/acpi_drivers.h
#include acpi/acpi_bus.h
#define ATK_HID ATK0110
#define ATK_DRV atk-hwmon
#define ASOC _SB.PCI0.SBRG.ASOC
struct atk_data {
struct class_device *class_dev;
acpi_handle atk_handle;
struct acpi_device *device;
acpi_handle rtmp_handle;
} atk_data;
typedef ssize_t (*sysfs_show_func)(struct device *dev, struct device_attribute
*attr, char *buf);
typedef ssize_t (*sysfs_store_func)(struct device *dev, struct device_attribute
*attr,
const char *buf, size_t count);
static void atk_init_attribute(struct device_attribute *attr, char *name,
mode_t mode,
sysfs_show_func show, sysfs_store_func store)
{
attr-attr.name = name;
attr-attr.mode = mode;
attr-show = show;
attr-store = store;
}
#define ATTR_NAME_SIZE 32
struct atk_temp_input {
struct device_attribute dev_attr;
/* id is used for the ACPI ID of the temp */
int id;
char attr_name[ATTR_NAME_SIZE];
};
struct atk_temp_input_list {
int count;
struct atk_temp_input temp_input[];
};
#define to_atk_temp_input(attr) \
container_of(attr, struct atk_temp_input, dev_attr)
static ssize_t atk_temp_input_show(struct device *dev, struct device_attribute
*attr, char *buf) {
struct atk_temp_input *a = to_atk_temp_input(attr);
union acpi_object temp;
struct acpi_buffer ret;
struct acpi_object_list params;
union acpi_object id;
acpi_status status;
ssize_t count;
id.type = ACPI_TYPE_INTEGER;
id.integer.value = a-id;
params.count = 1;
params.pointer = id;
ret.length = sizeof(temp);
ret.pointer = temp;
status = acpi_evaluate_object(atk_data.rtmp_handle, NULL, params,
ret);
if (status != AE_OK) {
printk(acpi_evaluate_object: %s\n,
acpi_format_exception(status));
return -EIO;
}
if (temp.type != ACPI_TYPE_INTEGER) {
printk(not an integer (%d)\n, temp.type);
return -EIO;
}
/* ACPI returns centidegree */
count = sprintf(buf, %llu\n, temp.integer.value * 10);
return
Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
Sorry for the delay.
Il Thu, Feb 08, 2007 at 01:19:08AM +0100, Giuseppe Bilotta ha scritto:
On 2/8/07, Luca Tettamanti [EMAIL PROTECTED] wrote:
Il Tue, Feb 06, 2007 at 09:22:00PM +, James Simmons ha scritto:
There is no stand alone nvidia card i2c driver. Its the issue of sharing
device interfaces with the same hardware problem again!!!
Nah, nvidiafb registers the I2C busses, you can drive them with whatever
you want through the devices exported by I2C core.
The fact the none of them work makes me think that the EDID is coming
from the BIOS, we do VBE calls in real mode during early kernel setup.
So what am I supposed to do to dump it, since neither i2cdump neither
get-edid seem to work?
Good question :)
The following patch fixes a real bug in SCL control and add a few debug
info. Can you try it?
diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
index 8454adf..ca8bd7e 100644
--- a/drivers/video/nvidia/nv_i2c.c
+++ b/drivers/video/nvidia/nv_i2c.c
@@ -25,6 +25,12 @@
#include ../edid.h
+#define DDC_SDA_READ_MASK (1 3)
+#define DDC_SCL_READ_MASK (1 2)
+#define DDC_SDA_WRITE_MASK (1 4)
+#define DDC_SCL_WRITE_MASK (1 5)
+
+
static void nvidia_gpio_setscl(void *data, int state)
{
struct nvidia_i2c_chan *chan = data;
@@ -35,9 +41,9 @@ static void nvidia_gpio_setscl(void *data, int state)
val = VGA_RD08(par-PCIO, 0x3d5) 0xf0;
if (state)
- val |= 0x20;
+ val |= DDC_SDA_WRITE_MASK;
else
- val = ~0x20;
+ val = ~DDC_SDA_WRITE_MASK;
VGA_WR08(par-PCIO, 0x3d4, chan-ddc_base + 1);
VGA_WR08(par-PCIO, 0x3d5, val | 0x1);
@@ -53,9 +59,9 @@ static void nvidia_gpio_setsda(void *data, int state)
val = VGA_RD08(par-PCIO, 0x3d5) 0xf0;
if (state)
- val |= 0x10;
+ val |= DDC_SDA_WRITE_MASK;
else
- val = ~0x10;
+ val = ~DDC_SDA_WRITE_MASK;
VGA_WR08(par-PCIO, 0x3d4, chan-ddc_base + 1);
VGA_WR08(par-PCIO, 0x3d5, val | 0x1);
@@ -68,11 +74,9 @@ static int nvidia_gpio_getscl(void *data)
u32 val = 0;
VGA_WR08(par-PCIO, 0x3d4, chan-ddc_base);
- if (VGA_RD08(par-PCIO, 0x3d5) 0x04)
+ if (VGA_RD08(par-PCIO, 0x3d5) DDC_SCL_READ_MASK)
val = 1;
- val = VGA_RD08(par-PCIO, 0x3d5);
-
return val;
}
@@ -83,7 +87,7 @@ static int nvidia_gpio_getsda(void *data)
u32 val = 0;
VGA_WR08(par-PCIO, 0x3d4, chan-ddc_base);
- if (VGA_RD08(par-PCIO, 0x3d5) 0x08)
+ if (VGA_RD08(par-PCIO, 0x3d5) DDC_SDA_READ_MASK)
val = 1;
return val;
@@ -188,7 +192,7 @@ static u8 *nvidia_do_probe_i2c_edid(struct nvidia_i2c_chan
*chan)
if (i2c_transfer(chan-adapter, msgs, 2) == 2)
return buf;
- dev_dbg(chan-par-pci_dev-dev, Unable to read EDID block.\n);
+ dev_warn(chan-par-pci_dev-dev, Unable to read EDID block.\n);
kfree(buf);
return NULL;
}
@@ -208,7 +212,10 @@ int nvidia_probe_i2c_connector(struct fb_info *info, int
conn, u8 **out_edid)
if (!edid conn == 1) {
/* try to get from firmware */
- const u8 *e = fb_firmware_edid(info-device);
+ const u8 *e;
+ printk(I2C probe failed for connector %d, falling back to
firmware\n, conn);
+
+ e = fb_firmware_edid(info-device);
if (e != NULL)
edid = kmemdup(e, EDID_LENGTH, GFP_KERNEL);
Luca
--
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/
Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
Il Tue, Feb 13, 2007 at 10:25:41AM +0100, Giuseppe Bilotta ha scritto: On 2/11/07, Luca Tettamanti [EMAIL PROTECTED] wrote: Sorry for the delay. Ditto! It also seemed that my kernel compiling sk1llz had gone AWL, I couldn't get the newly compiled kernel to run, until I realized the initrd.img was mislinked. Anyway. Your patch has an immediately visible effect of reducing snow: it seems that now that you fixed the access bug the EDID is properly /not/ used. dmesg | grep nvidiafb now claims the following: nvidiafb: Device ID: 10de0112 nvidiafb :01:00.0: Unable to read EDID block. nvidiafb :01:00.0: Unable to read EDID block. nvidiafb :01:00.0: Unable to read EDID block. (it actually gave the I2C probe failed ... message on console, but it's not appearing in the dmesg, obviously, since it's a simple printk) nvidiafb :01:00.0: Unable to read EDID block. nvidiafb :01:00.0: Unable to read EDID block. nvidiafb :01:00.0: Unable to read EDID block. nvidiafb: CRTC 1 is currently programmed for DFP nvidiafb: Using DFP on CRTC 1 nvidiafb: Panel size is 1600 x 1200 nvidiafb: Panel is TMDS nvidiafb: MTRR set to ON nvidiafb: Flat panel dithering disabled nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE000) Ok, now I'm confused O_o The patch should be correct, but I fail to see how EDID reading succeded before. So the EDID still seems to be totally inaccessible (which means I can't really tell why/when/where it's b0rked). Finally, as I mentioned, console still has a little snow. It's barely perceptible in common console usage because the monitor is mostly black, but can get annoying with fullscreen apps à la mc. Maybe the snow was caused by the driver hammering the I2C bus. Just guessing... Can you send me X.org log? Luca -- Alcuni pensano che io sia una persona orribile, ma non e` vero. Ho il cuore di un ragazzino - in un vaso sulla scrivania. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: strange keyboard lag after suspend testing
Adding Thomas Gleixner to CC Pavel Machek [EMAIL PROTECTED] ha scritto: Hi! I was testing suspend in 2.6.21-rc4 a lot, and now... machine feels like someone added 50..100msec delay somewhere in keyboard handling. Mouse does not seem affected. /proc/interrupts seem to increase as they should, for both keyboard and mouse. Can someone reproduce it? Any ideas how to debug it? Probably just asking the obvious: it's not a trivial failed to re-configure repeat rate upon resume (which one could rule out by running kbdrate again) but a lag in some interrupt handler or somewhere else deeper, right? No, it is not keyboard rate. Keyboard lags during normal typing, sometimes letters come in groups of two or so... I might start looking at embedded controller changes and switches. If ACPI misbehaves that could starve keyboard controller... But you said Mouse _seems_ okay, but I'm not sure if I'd notice lag there. that mouse is OK... Hmm, what happens if you load evbug and type while watching syslog. Do you observe the same delays? Hmm, seems that it only happens in X... so maybe it is some strange scheduling artefact? Hmm, something is wrong here: On console, I get expected 4-5 ticks a second. In x in gnome-terminal, I get this: It gets weirder: I killed some tasks and now: (on unloaded system running X, notice that top latency was ~1sec at 33:09). [EMAIL PROTECTED]:~# while true ; do echo -n . ; sleep .2; date; done .Tue Mar 20 17:33:07 CET 2007 .Tue Mar 20 17:33:07 CET 2007 .Tue Mar 20 17:33:08 CET 2007 .Tue Mar 20 17:33:08 CET 2007 .Tue Mar 20 17:33:08 CET 2007 .Tue Mar 20 17:33:08 CET 2007 .Tue Mar 20 17:33:09 CET 2007 .Tue Mar 20 17:33:10 CET 2007 .Tue Mar 20 17:33:10 CET 2007 .Tue Mar 20 17:33:10 CET 2007 .Tue Mar 20 17:33:10 CET 2007 .Tue Mar 20 17:33:10 CET 2007 .Tue Mar 20 17:33:11 CET 2007 .Tue Mar 20 17:33:11 CET 2007 .Tue Mar 20 17:33:11 CET 2007 .Tue Mar 20 17:33:12 CET 2007 .Tue Mar 20 17:33:12 CET 2007 As soon as I load the cpu up with while1, machine starts to behave. When I turn on bluetooth (USB), ACPI can no longer use C3, and machine starts to behave. Hmm? When the CPU is in C3 the TSC and LAPIC (IIRC) are stopped, sounds like the problem is here. Maybe after resume kernel fails to fall back to a safe clocksource. Luca -- Inquietudine sintetica Solo, davanti all'ignoto Tienimi stretto a te - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Can't select Video mode selection support and VGA 8x16 font
Hi. I0m trying to compile the kernel 2.6.20.7 and I have to select these features: - Video mode selection support - VGA 8x16 font but I can't select them because they are unselectable (they appear with --- in the left). I checked their requirements but all requirements seem to be active. Why I can't active them? Somebody could help me, please? Thank you very much! Bye, Luca. _ Scarica Messenger 8.1 e chiama gratis in tutto il mondo! http://get.live.com/it-it/messenger/features - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] Could the k8temp driver be interfering with ACPI?
On 4/15/07, Bjorn Helgaas [EMAIL PROTECTED] wrote: On Sunday 15 April 2007 03:41, Jean Delvare wrote: On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote: Of course, there are always BIOS defects. But if we could make a case that a BIOS that doesn't declare the resources used by the AML is defective, we could add quirks to reserve the undeclared resources. Only realistic if the list of systems needing a quirk is small. Do you think that would be the case? I don't know. I confess that I don't clearly understand the problem yet. It sounds like the sensor drivers want to talk to hardware that ACPI methods might also use. Exactly. But I missed the details, such as the specific devices in question, which ports they use, how they are described in ACPI, which AML methods use those ports, and which non-ACPI drivers also use them. The original report was about the temperature sensors of K8 cpus. It happens that ACPI reads the sensors while the linux driver is using it and gets garbage (and shut down the system). The problem is more generic though, and applies to all hardware monitoring chips for which a driver exists. It also sounds like the non-ACPI drivers provide much more functionality than ACPI exposes. I'd like to understand this, too, because an obvious way to solve the problem would be to drop the non-ACPI drivers. Problem is that ACPI may access the sensors anyway (e.g. via SMM). Is this extra functionality available on Windows? If so, do we know whether Windows uses non-ACPI drivers or whether they have some smarter way to use ACPI? Usually ACPI exposes 1 or 2 temperature readings (CPU and motherboard), while the hw driver can also provide fans and voltages measurements. Vendors usually provides a monitoring utility for Win that also exposes these information. It's not known whether there's a way to avoid conflicting accesses between ACPI and the raw driver; it's possible that it's vendor-specific and not documented. 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] Could the k8temp driver be interfering with ACPI?
On 2/20/07, Matthew Garrett [EMAIL PROTECTED] wrote: On Sun, Feb 18, 2007 at 06:38:05PM +0100, Jean Delvare wrote: ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI doesn't conflict with only k8temp, but with virtually all hardware monitoring drivers, all I2C/SMBus drivers, and probably other types of drivers too. We just can't restrict or blacklist all these drivers because ACPI misbehaves. No, the simple fact of the matter is that if you're running on an ACPI platform you need to change some of your assumptions. ACPI owns the hardware. The OS doesn't. To an extent this has always been true on laptops and servers /anyway/ - the BIOS is free to have a wide variety of SMM insanity that invalidates basic assumptions like If I hold this lock, nothing can interrupt me between this write and this read. That's simply not true. So this isn't about fixing ACPI. It's about trying to find a mechanism that allows ACPI and raw hardware drivers to coexist, which is made somewhat harder by it not being a situation that the platform designers have considered in the slightest. Motherboard vendors usually provide tools for $(TheOtherOS) that can read from all thermal / fan / voltage / whatever sensors, so I guess it's possible to make the ACPI driver and the raw one play nice with each other[1]. Luca [1] Unless their solution is poke at the hardware and hope that ACPI doesn't blow up, that is. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]
Dec 2004 usb usb7: configuration #1 chosen from 1 choice hub 7-0:1.0: USB hub found hub 7-0:1.0: 6 ports detected ACPI: PCI Interrupt :05:03.0[A] - GSI 21 (level, low) - IRQ 22 ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[22] MMIO=[ff7ef800-ff7e] Max Packet=[2048] IR/IT contexts=[4/8] Adding 787176k swap on /dev/hdd2. Priority:9 extents:1 across:787176k EXT3 FS on dm-0, internal journal ieee1394: Host added: ID:BUS[0-00:1023] GUID[0011d8e56e6e] NET: Registered protocol family 10 processor_perflib-0563 [00] processor_get_psd : Invalid _PSD data processor_perflib-0563 [00] processor_get_psd : Invalid _PSD data Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). kjournald starting. Commit interval 5 seconds EXT3 FS on dm-2, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on dm-3, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on dm-1, internal journal EXT3-fs: mounted filesystem with ordered data mode. e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex CBQ: class 00010001 has bad quantum==0, repaired. u32 classifier input device check on Actions configured input: Power Button (FF) as /class/input/input2 ACPI: Power Button (FF) [PWRF] input: Power Button (CM) as /class/input/input3 ACPI: Power Button (CM) [PWRB] fuse init (API version 7.8) [drm] Initialized drm 1.1.0 20060810 [drm] Initialized radeon 1.25.0 20060524 on minor 0 [drm] Setting GART location based on new memory map [drm] Loading R300 Microcode [drm] writeback test succeeded in 1 usecs Luca -- La vita potrebbe non avere alcun significato. Oppure, ancora peggio, potrebbe averne uno che disapprovo. -- Ashleigh Brilliant - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]
On 2/22/07, Thomas Gleixner [EMAIL PROTECTED] wrote: On Thu, 2007-02-22 at 00:04 +0100, Luca Tettamanti wrote: Hi Thomas, I'm testing NO_HZ on my machines. On the laptop I see that the timer interrupt counter is incremented (though slower than HZ). This machine is running UP kernel. On my desktop I see this: CPU0 CPU1 0:114 0 IO-APIC-edge timer 1: 1624 10771 IO-APIC-edge i8042 6: 3 0 IO-APIC-edge floppy 7: 0 0 IO-APIC-edge parport0 9: 0 0 IO-APIC-fasteoi acpi 12: 40111 184047 IO-APIC-edge i8042 16: 75624 998858 IO-APIC-fasteoi [EMAIL PROTECTED]::01:00.0, uhci_hcd:usb1 17: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 18:711 5487 IO-APIC-fasteoi ide1, libata, ehci_hcd:usb7, uhci_hcd:usb3 19:617 2254 IO-APIC-fasteoi libata, uhci_hcd:usb2 20: 0 0 IO-APIC-fasteoi ehci_hcd:usb6, uhci_hcd:usb5 21:2483869 0 IO-APIC-fasteoi eth0 22: 2 0 IO-APIC-fasteoi ohci1394 218: 28872 360643 PCI-MSI-edge HDA Intel 219: 32932 138196 PCI-MSI-edge libata NMI: 0 0 LOC:27611912827539 ERR: 0 MIS: 0 Interrupt 0 is stuck at 114 (the number is consistent across reboots). I don't experience any problem, time is running fine. Still it's strange that the timer is doing nothing; maybe something other than the PIT is used for time keeping? Yes, we switch away from PIT and use the local APIC timer. (LOC) Ok, thanks for the clarification. 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: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info
Il Thu, Feb 22, 2007 at 09:01:52AM +0100, Giuseppe Bilotta ha scritto: On 2/22/07, Antonino A. Daplas [EMAIL PROTECTED] wrote: On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote: As mentioned in another post in this thread, I can't get any info out of the i2c busses, because even when I have them available (i.e. after loading nvidiafb) I get all around (on all three of them). Suggestions on how to get the information welcome. Is this the same monitor you posted here? http://marc.theaimsgroup.com/?l=linux-kernelm=112807065616218w=2 If yes, we already have the manufacturer and model code. The main problem is that the EDID of this display has no sync range (H: 75-75kHz and V: 60-60Hz). Extending Hsync from 30-75kHz as a fix to the EDID block shouldn't be too hard. Yes, that's it! Jeepers, I can't believe that even re-reading the past LKML posts (even those!) I couldn't find the EDID info and how we had gotten them. I guess I need stronger glasses. Wonder why Luca's proposed patch makes the EDID undetectable, now, and why can't it be retrieved at a later time via i2c. Timeouts too small? Still scratching my head :| Tony, this is the patch (modulo cosmetic stuff) that I sent to Giuseppe. I believe it's correct (I cross checked with X.org driver): diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c index b858897..7e64341 100644 --- a/drivers/video/nvidia/nv_i2c.c +++ b/drivers/video/nvidia/nv_i2c.c @@ -70,8 +70,6 @@ static int nvidia_gpio_getscl(void *data) if (VGA_RD08(par-PCIO, 0x3d5) 0x04) val = 1; - val = VGA_RD08(par-PCIO, 0x3d5); - return val; } Luca -- Non sempre quello che viene dopo e` progresso. Alessandro Manzoni - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG][2.6.21] af_key: kernel BUG at net/core/skbuff.c:93
.config is attached. Luca -- L'abilita` politica e` l'abilita` di prevedere quello che accadra` domani, la prossima settimana, il prossimo mese e l'anno prossimo. E di essere cosi` abili, piu` tardi, da spiegare perche' non e` accaduto. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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][2.6.21] af_key: kernel BUG at net/core/skbuff.c:93
Il Mon, Feb 26, 2007 at 11:08:41PM +0100, Luca Tettamanti ha scritto: .config is attached. This time for real... This one is with INET_AH and INET_ESP enabled. Disabling them triggers the bug. Luca -- Se non puoi convincerli, confondili. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc1 # Mon Feb 26 23:12:17 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Processor type and features # CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MCORE2=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_NR_CPUS=2 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_VMSPLIT_3G is not set CONFIG_VMSPLIT_3G_OPT=y # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xB000 CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y
Re: [BUG][2.6.21] af_key: kernel BUG at net/core/skbuff.c:93
On 2/27/07, Jarek Poplawski [EMAIL PROTECTED] wrote: On 26-02-2007 23:08, Luca Tettamanti wrote: Hello, I'm running 2.6.21 (current git, at 9654640d0af). kernel blows up at startup, when running setkey. Kernel 2.6.20 runs fine. A couple of words ... [ cut here ] kernel BUG at /home/kronos/src/linux-2.6.git/net/core/skbuff.c:93! invalid opcode: [#1] Hi! Could you repeat this with: CONFIG_4KSTACKS=n ? Actually I cannot repeat after a make clean, with either stack configurations. The original kernel still consistently dies in the same point though. Must have been a mis-compilation :( Sorry for the noise. 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] pata_jmicron: remove spurious #endif
Hello,
commit 438ac6d5e3f8106a6bd1a5682c508d660294a85d causes a build failure:
CC drivers/ata/pata_jmicron.o
/home/kronos/src/linux-2.6.git/drivers/ata/pata_jmicron.c:247:2: error:
#endif without #if
make[3]: *** [drivers/ata/pata_jmicron.o] Error 1
Remove a spurious #endif in pata_jmicron driver.
Signed-Off-By: Luca Tettamanti [EMAIL PROTECTED]
---
drivers/ata/pata_jmicron.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/ata/pata_jmicron.c b/drivers/ata/pata_jmicron.c
index 033319e..43763c9 100644
--- a/drivers/ata/pata_jmicron.c
+++ b/drivers/ata/pata_jmicron.c
@@ -244,7 +244,6 @@ static void __exit jmicron_exit(void)
{
pci_unregister_driver(jmicron_pci_driver);
}
-#endif
module_init(jmicron_init);
module_exit(jmicron_exit);
Luca
--
You and me baby ain't nothin' but mammals
So let's do it like they do on the Discovery Channel
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
