[patch 10/10] arch/i386/crypto/aes.c: fix sparse warnings
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/arch/i386/crypto/aes.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN arch/i386/crypto/aes.c~sparse-arch_i386_crypto_aes
arch/i386/crypto/aes.c
--- kj/arch/i386/crypto/aes.c~sparse-arch_i386_crypto_aes 2005-03-18
20:05:21.0 +0100
+++ kj-domen/arch/i386/crypto/aes.c 2005-03-18 20:05:21.0 +0100
@@ -59,7 +59,7 @@ struct aes_ctx {
};
#define WPOLY 0x011b
-#define u32_in(x) le32_to_cpu(*(const u32 *)(x))
+#define u32_in(x) le32_to_cpup((const __le32 *)(x))
#define bytes2word(b0, b1, b2, b3) \
(((u32)(b3) 24) | ((u32)(b2) 16) | ((u32)(b1) 8) | (b0))
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 09/10] arch/i386/mm/fault.c: fix sparse warnings
Signed-off-by: Domen Puncer [EMAIL PROTECTED] --- kj-domen/arch/i386/mm/fault.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN arch/i386/mm/fault.c~sparse-arch_i386_mm_fault arch/i386/mm/fault.c --- kj/arch/i386/mm/fault.c~sparse-arch_i386_mm_fault 2005-03-18 20:05:20.0 +0100 +++ kj-domen/arch/i386/mm/fault.c 2005-03-18 20:05:20.0 +0100 @@ -146,7 +146,7 @@ static int __is_prefetch(struct pt_regs if (instr limit) break; - if (__get_user(opcode, (unsigned char *) instr)) + if (__get_user(opcode, (unsigned char __user *) instr)) break; instr_hi = opcode 0xf0; @@ -173,7 +173,7 @@ static int __is_prefetch(struct pt_regs scan_more = 0; if (instr limit) break; - if (__get_user(opcode, (unsigned char *) instr)) + if (__get_user(opcode, (unsigned char __user *) instr)) break; prefetch = (instr_lo == 0xF) (opcode == 0x0D || opcode == 0x18); _ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] drivers/block/sx8.c: Use the DMA_{64, 32}BIT_MASK constants
Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h when calling
pci_set_dma_mask() or pci_set_consistent_dma_mask()
These patches include dma-mapping.h explicitly because it caused errors
on some architectures otherwise.
See http://marc.theaimsgroup.com/?t=10800199301r=1w=2 for details
Signed-off-by: Tobias Klauser [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/drivers/block/sx8.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff -puN drivers/block/sx8.c~dma_mask-drivers_block_sx8 drivers/block/sx8.c
--- kj/drivers/block/sx8.c~dma_mask-drivers_block_sx8 2005-03-18
20:05:46.0 +0100
+++ kj-domen/drivers/block/sx8.c2005-03-18 20:05:46.0 +0100
@@ -26,6 +26,7 @@
#include linux/delay.h
#include linux/time.h
#include linux/hdreg.h
+#include linux/dma-mapping.h
#include asm/io.h
#include asm/semaphore.h
#include asm/uaccess.h
@@ -1582,9 +1583,9 @@ static int carm_init_one (struct pci_dev
goto err_out;
#if IF_64BIT_DMA_IS_POSSIBLE /* g... */
- rc = pci_set_dma_mask(pdev, 0xULL);
+ rc = pci_set_dma_mask(pdev, DMA_64BIT_MASK);
if (!rc) {
- rc = pci_set_consistent_dma_mask(pdev, 0xULL);
+ rc = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
if (rc) {
printk(KERN_ERR DRV_NAME (%s): consistent DMA mask
failure\n,
pci_name(pdev));
@@ -1593,7 +1594,7 @@ static int carm_init_one (struct pci_dev
pci_dac = 1;
} else {
#endif
- rc = pci_set_dma_mask(pdev, 0xULL);
+ rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
if (rc) {
printk(KERN_ERR DRV_NAME (%s): DMA mask failure\n,
pci_name(pdev));
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] printk : drivers/char/watchdog/wdt285.c
printk() calls should include appropriate KERN_* constant. Signed-off-by: Christophe Lucas [EMAIL PROTECTED] Signed-off-by: Domen Puncer [EMAIL PROTECTED] --- kj-domen/drivers/char/watchdog/wdt285.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/char/watchdog/wdt285.c~printk-drivers_char_watchdog_wdt285 drivers/char/watchdog/wdt285.c --- kj/drivers/char/watchdog/wdt285.c~printk-drivers_char_watchdog_wdt285 2005-03-18 20:05:42.0 +0100 +++ kj-domen/drivers/char/watchdog/wdt285.c 2005-03-18 20:05:42.0 +0100 @@ -204,11 +204,11 @@ static int __init footbridge_watchdog_in if (retval 0) return retval; - printk(Footbridge Watchdog Timer: 0.01, timer margin: %d sec\n, + printk(KERN_INFO Footbridge Watchdog Timer: 0.01, timer margin: %d sec\n, soft_margin); if (machine_is_cats()) - printk(Warning: Watchdog reset may not work on this machine.\n); + printk(KERN_WARNING Warning: Watchdog reset may not work on this machine.\n); return 0; } _ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/4] crypto/sha256.c: fix sparse warnings
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/crypto/sha256.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN crypto/sha256.c~sparse-crypto_sha256 crypto/sha256.c
--- kj/crypto/sha256.c~sparse-crypto_sha256 2005-03-18 20:05:34.0
+0100
+++ kj-domen/crypto/sha256.c2005-03-18 20:05:34.0 +0100
@@ -58,7 +58,7 @@ static inline u32 Maj(u32 x, u32 y, u32
static inline void LOAD_OP(int I, u32 *W, const u8 *input)
{
- W[I] = __be32_to_cpu( ((u32*)(input))[I] );
+ W[I] = __be32_to_cpu( ((__be32*)(input))[I] );
}
static inline void BLEND_OP(int I, u32 *W)
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kernel BUG at rmap:482
Dear All,
I have seen discussion about this in recent months on the list, and
unfortunately I am experiencing the same problem myself now on a new
machine. I have run memtest86 for some hours and there seems to be no
problem. The machine has 1GB DDR PC3200 RAM/AMD Athlon(tm) 64 Processor
3500+/ASUS A8V motherboard/120GB Seagate SATA HDD. If you have a patch
you would like me to try I am willing to have a go, this is a new
machine which I waiting to deploy, so there is no production data on it
at all yet. I can reproduce the problem fairly regularly, just set the
machine to compile something big like glibc, and I get it within an hour
usually...
Thanks a lot!
Regards,
Kernel: Linux newlog 2.6.11.4 #1 Sat Mar 19 15:10:16 CET 2005 x86_64 AMD
Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux
Report in log:
Kernel BUG at rmap:482
invalid operand: [1]
CPU 0
Modules linked in: usb_storage ohci_hcd uhci_hcd ehci_hcd
Pid: 16405, comm: sh Not tainted 2.6.11.4
RIP: 0010:[80162e25] 80162e25{page_remove_rmap+37}
RSP: 0018:810035fa3de0 EFLAGS: 00010296
RAX: ff00 RBX: 6000 RCX: 804af3a0
RDX: RSI: 0001 RDI: 810001a7a928
RBP: 81003622f030 R08: 810001a7a928 R09: 810035fa3f00
R10: 81003196d7b8 R11: 81003196d7a8 R12: 00041000
R13: 0020 R14: R15: 0060
FS: 2aff36d0() GS:804eeb00()
knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 006367d8 CR3: 2ecb8000 CR4: 06e0
Process sh (pid: 16405, threadinfo 810035fa2000, task
81003f3cf680)
Stack: 8015bc86 0001 810001a7a928
00640fff
405eb000 00641000 810035223018
810035222000
8015f21c 81002ecb8000
Call Trace:8015bc86{unmap_vmas+1542}
8015fe51{do_munmap+465}
80160b6f{sys_brk+143} 8010e1fa{system_call
+126}
Code: 0f 0b 95 5e 39 80 ff ff ff ff e2 01 48 c7 c6 ff ff ff ff bf
RIP 80162e25{page_remove_rmap+37} RSP 810035fa3de0
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/Patch 0/12] ACPI based root bridge hot-add
On Fri, 18 Mar 2005 13:38:57 -0800, Rajesh Shah wrote: Here is a series of patches to support ACPI hot-add of a root bridge hierarchy. The added hierarchy may contain other p2p bridges and end/leaf I/O devices too. The root bridge itself is assumed to have been assigned resource ranges, but the p2p bridges and end devices are not required to be initialized by firmware. Most of the code changes are to make the existing code flows suitable for such a hierarchy of bridges devices. This code supports hot-add on ia64 only for now.It does not yet support I/O APIC hot-add, which is needed to make this fully functional. The patches are against 2.6.11-mm4 (plus the patch needed for ia64 to boot). I've tested to make sure this does not break end/leaf device hotplug on the hotplug capable ia64 box I have. Thanks, Rajesh Does this mean that when it will be ported for i386, I will be able to really use my Docking Station ? Does it rescan the DSDT to find new additions to ACPI devices ? I have an IBM docking station with a PCI bus inside and some other devices, and when I hot plug my IBM ThinkPad T41 in it, it does not recognize those devices. Only if I boot in dock they are usable. And the DSDT is different if I boot in dock or not. So I wander if this patch would help me to hot plug my T41 in the dock and all devices will be recognized. (when the patch will be for i386 too) Thx, Paul - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 4/4] security/selinux/ss/conditional.c: fix sparse warnings
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/security/selinux/ss/conditional.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff -puN
security/selinux/ss/conditional.c~sparse-security_selinux_ss_conditional
security/selinux/ss/conditional.c
--- kj/security/selinux/ss/conditional.c~sparse-security_selinux_ss_conditional
2005-03-18 20:05:33.0 +0100
+++ kj-domen/security/selinux/ss/conditional.c 2005-03-18 20:05:33.0
+0100
@@ -219,7 +219,8 @@ int cond_read_bool(struct policydb *p, s
{
char *key = NULL;
struct cond_bool_datum *booldatum;
- u32 buf[3], len;
+ __le32 buf[3];
+ u32 len;
int rc;
booldatum = kmalloc(sizeof(struct cond_bool_datum), GFP_KERNEL);
@@ -263,7 +264,8 @@ static int cond_read_av_list(struct poli
struct avtab_datum datum;
struct avtab_node *node_ptr;
int rc;
- u32 buf[1], i, len;
+ __le32 buf[1];
+ u32 i, len;
u8 found;
*ret_list = NULL;
@@ -369,7 +371,8 @@ static int expr_isvalid(struct policydb
static int cond_read_node(struct policydb *p, struct cond_node *node, void *fp)
{
- u32 buf[2], len, i;
+ __le32 buf[2];
+ u32 len, i;
int rc;
struct cond_expr *expr = NULL, *last = NULL;
@@ -427,7 +430,8 @@ err:
int cond_read_list(struct policydb *p, void *fp)
{
struct cond_node *node, *last = NULL;
- u32 buf[1], i, len;
+ __le32 buf[1];
+ u32 i, len;
int rc;
rc = next_entry(buf, fp, sizeof buf);
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/4] security/selinux/ss/policydb.c: fix sparse warnings
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/security/selinux/ss/policydb.c | 35 ++--
1 files changed, 20 insertions(+), 15 deletions(-)
diff -puN security/selinux/ss/policydb.c~sparse-security_selinux_ss_policydb
security/selinux/ss/policydb.c
--- kj/security/selinux/ss/policydb.c~sparse-security_selinux_ss_policydb
2005-03-18 20:05:25.0 +0100
+++ kj-domen/security/selinux/ss/policydb.c 2005-03-18 20:05:25.0
+0100
@@ -780,7 +780,7 @@ static int context_read_and_validate(str
struct policydb *p,
void *fp)
{
- u32 buf[3];
+ __le32 buf[3];
int rc;
rc = next_entry(buf, fp, sizeof buf);
@@ -820,7 +820,8 @@ static int perm_read(struct policydb *p,
char *key = NULL;
struct perm_datum *perdatum;
int rc;
- u32 buf[2], len;
+ __le32 buf[2];
+ u32 len;
perdatum = kmalloc(sizeof(*perdatum), GFP_KERNEL);
if (!perdatum) {
@@ -860,7 +861,8 @@ static int common_read(struct policydb *
{
char *key = NULL;
struct common_datum *comdatum;
- u32 buf[4], len, nel;
+ __le32 buf[4];
+ u32 len, nel;
int i, rc;
comdatum = kmalloc(sizeof(*comdatum), GFP_KERNEL);
@@ -1092,7 +1094,8 @@ static int role_read(struct policydb *p,
char *key = NULL;
struct role_datum *role;
int rc;
- u32 buf[2], len;
+ __le32 buf[2];
+ u32 len;
role = kmalloc(sizeof(*role), GFP_KERNEL);
if (!role) {
@@ -1152,7 +1155,8 @@ static int type_read(struct policydb *p,
char *key = NULL;
struct type_datum *typdatum;
int rc;
- u32 buf[3], len;
+ __le32 buf[3];
+ u32 len;
typdatum = kmalloc(sizeof(*typdatum),GFP_KERNEL);
if (!typdatum) {
@@ -1224,7 +1228,8 @@ static int user_read(struct policydb *p,
char *key = NULL;
struct user_datum *usrdatum;
int rc;
- u32 buf[2], len;
+ __le32 buf[2];
+ u32 len;
usrdatum = kmalloc(sizeof(*usrdatum), GFP_KERNEL);
if (!usrdatum) {
@@ -1392,7 +1397,8 @@ int policydb_read(struct policydb *p, vo
struct ocontext *l, *c, *newc;
struct genfs *genfs_p, *genfs, *newgenfs;
int i, j, rc;
- u32 buf[8], len, len2, config, nprim, nel, nel2;
+ __le32 buf[8];
+ u32 len, len2, config, nprim, nel, nel2;
char *policydb_str;
struct policydb_compat_info *info;
struct range_trans *rt, *lrt;
@@ -1408,17 +1414,14 @@ int policydb_read(struct policydb *p, vo
if (rc 0)
goto bad;
- for (i = 0; i 2; i++)
- buf[i] = le32_to_cpu(buf[i]);
-
- if (buf[0] != POLICYDB_MAGIC) {
+ if (buf[0] != cpu_to_le32(POLICYDB_MAGIC)) {
printk(KERN_ERR security: policydb magic number 0x%x does
not match expected magic number 0x%x\n,
- buf[0], POLICYDB_MAGIC);
+ le32_to_cpu(buf[0]), POLICYDB_MAGIC);
goto bad;
}
- len = buf[1];
+ len = le32_to_cpu(buf[1]);
if (len != strlen(POLICYDB_STRING)) {
printk(KERN_ERR security: policydb string length %d does not
match expected length %Zu\n,
@@ -1494,9 +1497,11 @@ int policydb_read(struct policydb *p, vo
goto bad;
}
- if (buf[2] != info-sym_num || buf[3] != info-ocon_num) {
+ if (le32_to_cpu(buf[2]) != info-sym_num ||
+ le32_to_cpu(buf[3]) != info-ocon_num) {
printk(KERN_ERR security: policydb table sizes (%d,%d) do
- not match mine (%d,%d)\n, buf[2], buf[3],
+ not match mine (%d,%d)\n,
+ le32_to_cpu(buf[2]), le32_to_cpu(buf[3]),
info-sym_num, info-ocon_num);
goto bad;
}
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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/4] security/selinux/ss/ebitmap.c: fix sparse warnings
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/security/selinux/ss/ebitmap.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff -puN security/selinux/ss/ebitmap.c~sparse-security_selinux_ss_ebitmap
security/selinux/ss/ebitmap.c
--- kj/security/selinux/ss/ebitmap.c~sparse-security_selinux_ss_ebitmap
2005-03-18 20:05:32.0 +0100
+++ kj-domen/security/selinux/ss/ebitmap.c 2005-03-18 20:05:32.0
+0100
@@ -239,8 +239,9 @@ int ebitmap_read(struct ebitmap *e, void
{
int rc;
struct ebitmap_node *n, *l;
- u32 buf[3], mapsize, count, i;
- u64 map;
+ __le32 buf[3];
+ u32 mapsize, count, i;
+ __le64 map;
ebitmap_init(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/
2.6.11-mm4: drivers/scsi/arcmsr/arcmsr.c: enormous stack usage
On Wed, Mar 16, 2005 at 04:06:54AM -0800, Andrew Morton wrote:
...
Changes since 2.6.11-mm3:
...
+areca-raid-linux-scsi-driver.patch
Updated version of this driver.
...
-- snip --
...
static int arcmsr_iop_ioctlcmd(PACB pACB, int ioctl_cmd, void *arg)
{
...
uint8_t tmpQbuffer[1032];
...
uint8_t tmpuserbuffer[1032];
...
}
...
-- snip --
1kB allocations from the stack aren't a good idea considering that you
might have only a 4kB stack altogether.
Running make checkstack after compiling the kernel helps you finding
such problems.
cu
Adrian
--
Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 3/4] security/selinux/ss/avtab.c: fix sparse warnings
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
kj-domen/security/selinux/ss/avtab.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -puN security/selinux/ss/avtab.c~sparse-security_selinux_ss_avtab
security/selinux/ss/avtab.c
--- kj/security/selinux/ss/avtab.c~sparse-security_selinux_ss_avtab
2005-03-18 20:05:32.0 +0100
+++ kj-domen/security/selinux/ss/avtab.c2005-03-18 20:05:32.0
+0100
@@ -303,7 +303,7 @@ void avtab_hash_eval(struct avtab *h, ch
int avtab_read_item(void *fp, struct avtab_datum *avdatum, struct avtab_key
*avkey)
{
- u32 buf[7];
+ __le32 buf[7];
u32 items, items2;
int rc;
@@ -370,7 +370,7 @@ int avtab_read(struct avtab *a, void *fp
int rc;
struct avtab_key avkey;
struct avtab_datum avdatum;
- u32 buf[1];
+ __le32 buf[1];
u32 nel, i;
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.12-rc1 IDE noboot
When switching from 2.6.11 to 2.6.12-rc1, I get a 'cannot open root device' fatal error at end of kernel boot process. Root device is 'hda1'. Hardware content of the box: 8086Intel Corporation 334082855PM 0 Host-Hub Interface Bridge 8086Intel Corporation 334182855PM 0 AGP Bridge 8086Intel Corporation 24C282801DB/DBL/DBM B USB UHCI Controller #1 8086Intel Corporation 24C482801DB/DBL/DBM B USB UHCI Controller #2 8086Intel Corporation 24C782801DB/DBL/DBM B USB UHCI Controller #3 8086Intel Corporation 24CD82801DB/DBL/DBM B USB EHCI Controller 8086Intel Corporation 244882801BAM/CAM/DBM0 Hub Interface to PCI Bridge 8086Intel Corporation 24CC82801DBM0 LPC Interface Bridge 8086Intel Corporation 24CA82801DBMB IDE Controller (UltraATA/100) 8086Intel Corporation 24C582801DB/DBL/DBM B AC97 Audio Controller 8086Intel Corporation 24C682801DB/DBM B AC97 Modem Controller 10DENVIDIA Corporation 0324NV31B NVIDIA NV31GL 14E4Broadcom Corporation165DBCM5705MB Broadcom NetXtreme Gigabit Ethernet 104CTexas Instruments AC477510/4510 B Cardbus 104CTexas Instruments AC4AB 104CTexas Instruments 802BB 104CTexas Instruments 82044610, 4515, 4610FM 0 TI UltraMedia Firmware Loader Device 8086Intel Corporation 4220MPCI3B B Intel 2200 mPCI 3B - RoW 2.6.11 kernel report: 4Linux version 2.6.11 ([EMAIL PROTECTED]) (gcc version 3.3 (Debian)) #1 Sun Mar 6 12:00:57 CET 2005 6BIOS-provided physical RAM map: 4 BIOS-e820: - 0009f000 (usable) 4 BIOS-e820: 0009f000 - 000a (reserved) 4 BIOS-e820: 0010 - 3ffae000 (usable) 4 BIOS-e820: 3ffae000 - 4000 (reserved) 4 BIOS-e820: feda - fee0 (reserved) 4 BIOS-e820: ffb0 - 0001 (reserved) 4Warning only 896MB will be used. 4Use a HIGHMEM enabled kernel. 5896MB LOWMEM available. 7On node 0 totalpages: 229376 7 DMA zone: 4096 pages, LIFO batch:1 7 Normal zone: 225280 pages, LIFO batch:16 7 HighMem zone: 0 pages, LIFO batch:1 6DMI 2.3 present. 7ACPI: RSDP (v000 DELL ) @ 0x000fdf00 7ACPI: RSDT (v001 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff 7ACPI: FADT (v001 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff0400 7ACPI: ASF! (v016 DELLCPi R 0x27d40903 ASL 0x0061) @ 0x3fff0800 7ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 MSFT 0x010e) @ 0x 4Allocating PCI resources starting at 4000 (gap: 4000:beda) 4Built 1 zonelists 4Kernel command line: BOOT_IMAGE=recover ro root=301 4Local APIC disabled by BIOS -- you can enable it with lapic 7mapped APIC to d000 (01703000) 6Initializing CPU#0 4PID hash table entries: 4096 (order: 12, 65536 bytes) 4Detected 1998.546 MHz processor. 6Using tsc for high-res timesource 4Console: colour VGA+ 80x25 4Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) 4Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) 6Memory: 906620k/917504k available (1598k kernel code, 10432k reserved, 518k data, 140k init, 0k highmem) 4Checking if this processor honours the WP bit even in supervisor mode... Ok. 7Calibrating delay loop... 3956.73 BogoMIPS (lpj=1978368) 4Mount-cache hash table entries: 512 (order: 0, 4096 bytes) 7CPU: After generic identify, caps: afe9f9bf 0180 7CPU: After vendor identify, caps: afe9f9bf 0180 6CPU: L1 I cache: 32K, L1 D cache: 32K 6CPU: L2 cache: 2048K 7CPU: After all inits, caps: afe9f9bf 0040 0180 6Intel machine check architecture supported. 6Intel machine check reporting enabled on CPU#0. 4CPU: Intel(R) Pentium(R) M processor 2.00GHz stepping 06 6Enabling fast FPU save and restore... done. 6Enabling unmasked SIMD FPU exception support... done. 6Checking 'hlt' instruction... OK. 4ACPI: setting ELCR to 0200 (from 0800) 6NET: Registered protocol family 16 6PCI: PCI BIOS revision 2.10 entry at 0xfc96e, last bus=2 6PCI: Using configuration type 1 6mtrr: v2.0 (20020519) 6ACPI: Subsystem revision 20050211 6ACPI: Interpreter enabled 6ACPI: Using PIC for interrupt routing 6ACPI: PCI Root Bridge [PCI0] (00:00) 4PCI: Probing PCI hardware (bus 00) 6PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 6PCI: Transparent bridge - :00:1e.0 7ACPI: PCI Interrupt Routing
Re: [PATCH 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation
On Sat, Mar 19, 2005 at 07:09:45AM +0100, Arjan van de Ven wrote: On Fri, 2005-03-18 at 15:23 -0600, Matt Domsch wrote: For review and comment. On x86_64 systems with no IOMMU and with 4GB RAM (in fact, whenever there are any pages mapped above 4GB), pci_alloc_consistent() falls back to using ZONE_DMA for all allocations, even if the device's dma_mask could have supported using memory from other zones. Problems can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume all of ZONE_DMA, leaving none left for pci_alloc_consistent() use. scsi_malloc no longer uses ZONE_DMA nowadays In 2.4.x it does. scsi_resize_dma_pool() has: __get_free_pages(GFP_ATOMIC | GFP_DMA, 0); scsi_init_minimal_dma_pool() has similar. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
e1000||ICH5-ATA BUG in 2.6.12-rc1 triggered by ill behaved CD-ROM drive
Here's the story again but shorter: (- netdev: (solved) Re: Fw: 2.6.11-mm2 weird ethernet RTTs ) It seems after some reboot my CD-ROM drive went nuts and hogged up my IDE-Controller (ICH5) which in turn either generated a lot of interrupts or did not properly respond to em. Half of the time i tried booting the machine with the CD-ROM drive attached to ide1 and the HD at ide0 i experienced heavy disk timeouts due to DMA timeouts (°1) and the other half of the time the following kernel BUG was triggered. Removing the CD-ROM resolved all those problems. (typos probable - no camera was handy ;-() Configuring network interfaces ... --- cut here --- kernel BUG at include/linux/netdevice.h:860! invalid operand: [#1] PREEMPT SMP Modules linked in: ide_cd cdrom ... (left out some here) ... commoncap e1000 3c59x mii CPU: 0 EIP: 0060: [e005159b] Not tainted VLI EFLAGS: 00010046 (2.6.12-rc1) EIP is at e1000_clean+0xcb/0xe0 [e1000] eax: 0017 ebx: 0287 ecx: edx: e81e6000 esi: edi: de67e800 ebp: 0040 esp: c042efb0 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c042e000 task=c0360c00) Stack: de67ea40 de67e904 de67e800 c13f5fa0 c13f5f80 c02adedf fffbbf83 012c 0001 c03ec198 c0427bc0 c0123fc6 000a c03f4f88 0046 c03f4000 0047a007 c010552a Call Trace: [c02adedf] net_rx_action+0x7f/0x110 [c0123fc6] __do_softirq+0xb6/0xd0 [c010552a] do_softirq+0x4a/0x60 [c01240a9] irq_exit+0x39/0x40 [c010541d] do_IRQ+0x4d/0x70 [c0103ade] common_interrupt+0x1a/0x20 [c0101053] default_idle+0x23/0x30 [c03f58df] start_kernel+0x15f/0x180 [c03f5350] unknown_bootoption+0x0/0x1e0 Code: c0 84 c0 74 1a 8b 82 24 02 00 00 b9 9d 00 00 00 89 88 d0 00 00 00 8b 82 24 02 00 00 8b 40 08 31 d2 82 c4 08 89 d0 5b 5e 5f 5d c3 0f 0b 5c 03 35 c6 05 e0 eb 91 8d 74 26 00 8d bc 27 00 00 00 00 0 Kernel panic - not syncing: Fatal exception in interrupt e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex --- The End --- Kernel-config and lspci -vvv attached. °1: Mar 18 14:47:53 giscard kernel: irq 177: nobody cared! Mar 18 14:47:53 giscard kernel: [__report_bad_irq+36/144] __report_bad_irq+0x24/0x90 Mar 18 14:47:53 giscard kernel: [note_interrupt+97/144] note_interrupt+0x61/0x90 Mar 18 14:47:53 giscard kernel: [__do_IRQ+284/288] __do_IRQ+0x11c/0x120 Mar 18 14:47:53 giscard kernel: [do_IRQ+70/112] do_IRQ+0x46/0x70 Mar 18 14:47:53 giscard kernel: === Mar 18 14:47:53 giscard kernel: [common_interrupt+26/32] common_interrupt+0x1a/0x20 Mar 18 14:47:53 giscard kernel: [default_idle+35/48] default_idle+0x23/0x30 Mar 18 14:47:53 giscard kernel: [cpu_idle+95/112] cpu_idle+0x5f/0x70 Mar 18 14:47:53 giscard kernel: [start_kernel+351/384] start_kernel+0x15f/0x180 Mar 18 14:47:53 giscard kernel: [unknown_bootoption+0/448] unknown_bootoption+0x0/0x1c0 Mar 18 14:47:53 giscard kernel: handlers: Mar 18 14:47:53 giscard kernel: [ide_intr+0/336] (ide_intr+0x0/0x150) Mar 18 14:47:53 giscard kernel: [ide_intr+0/336] (ide_intr+0x0/0x150) Mar 18 14:47:53 giscard kernel: [usb_hcd_irq+0/96] (usb_hcd_irq+0x0/0x60) Mar 18 14:47:53 giscard kernel: [pg0+532648896/1069179904] (e1000_intr+0x0/0x110 [e1000]) Mar 18 14:47:53 giscard kernel: Disabling IRQ #177 Mar 18 14:47:53 giscard kernel: hda: dma_timer_expiry: dma status == 0x24 Mar 18 14:47:53 giscard kernel: hda: DMA interrupt recovery Mar 18 14:47:53 giscard kernel: hda: lost interrupt Stefan -- Reality is a poor substitute for my dreams. - anonymous :00:00.0 Host bridge: Intel Corp. 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 80a5 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Region 0: Memory at fe80 (32-bit, prefetchable) [size=4M] Capabilities: [e4] #09 [0106] :00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics Device (rev 02) (prog-if 00 [VGA]) Subsystem: Asustek Computer, Inc.: Unknown device 80a5 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin A routed to IRQ 169 Region 0: Memory at f000 (32-bit, prefetchable) [size=128M] Region 1: Memory at fe78 (32-bit, non-prefetchable) [size=512K] Region 2: I/O ports at efe0 [size=8] Capabilities: [d0] Power Management version 1 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- :00:03.0 PCI bridge: Intel Corp. 82865G/PE/P PCI to CSA Bridge (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+
[PATCH] swsusp: do not leak memory if there's an error during suspend
Hi,
The following patch prevents swsusp from leaking memory if there's an error
during suspend (eg when device_power_down() returns non-zero).
Greets,
Rafael
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
--- linux-2.6.12-rc1-a/kernel/power/swsusp.c2005-03-19 11:51:02.0
+0100
+++ linux-2.6.12-rc1-b/kernel/power/swsusp.c2005-03-19 15:16:56.0
+0100
@@ -894,10 +894,12 @@ int swsusp_suspend(void)
*/
if ((error = device_power_down(PMSG_FREEZE))) {
local_irq_enable();
+ swsusp_free();
return error;
}
save_processor_state();
- error = swsusp_arch_suspend();
+ if ((error = swsusp_arch_suspend()))
+ swsusp_free();
/* Restore control flow magically appears here */
restore_processor_state();
BUG_ON (nr_copy_pages_check != nr_copy_pages);
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll Alice's Adventures in Wonderland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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.11.2][RFC] printk with antisp am-feature
Issue:
On some conditions, the dmesg is spammed with repeated warnings about the
same issue which is neither critical nor going to be fixed. This may
result in losing the boot messages or missing other important messages.
Examples are:
nfs warning: mount version older than kernel
(my mount is newer than documented to be required)
atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.
(I'm using a keyboard switch and a IBM PS/2 keyboard)
program smartd is using a deprecated SCSI ioctl, please convert it to SG_IO
(I'll use the latest version as soon as I need to)
Rate-limiting these messages is won't help, since it would still allow
these messages to (slowly or in a burst) spam the log.
Printing these messages only once after booting might result in missing
important messages, especially on long-running systems (e.g. if my
keyboard really breaks after I have used the keyboard switch).
Suggested solution:
Instead, I decided to use a global flag with a semi-random magic number,
which will indicate the last printk being supposed to be limited, and to
reset this flag on each normal printk. By doing this, dmesg will not be
spammed, but the latest issue is displayed last.
(I suggest using the first value from cksum file.c as the magic number
unless there are thousands of printks to convert.)
The magic number depends on the CPU being able to read and write a
complete int at once *or* being lucky not to have a magic value that can
be constructed by combining some other magic numbers and printking with
exactly that magic number while the update happens. I can convert the
variable to an atomic type if it is a concern, but that would increase the
chances of a clash due to the 24 bit limit.
The patch increases the size of vmlinux by 141 bytes.
--
The programmer's National Anthem is '' diff -uprN linux-2.6.11/drivers/block/scsi_ioctl.c
linux-2.6.11.new/drivers/block/scsi_ioctl.c
--- linux-2.6.11/drivers/block/scsi_ioctl.c 2005-03-03 15:41:28.0
+0100
+++ linux-2.6.11.new/drivers/block/scsi_ioctl.c 2005-03-18 22:08:35.0
+0100
@@ -547,7 +547,7 @@ int scsi_cmd_ioctl(struct file *file, st
* old junk scsi send command ioctl
*/
case SCSI_IOCTL_SEND_COMMAND:
- printk(KERN_WARNING program %s is using a deprecated
SCSI ioctl, please convert it to SG_IO\n, current-comm);
+ printk_nospam(2296159591, KERN_WARNING program %s is
using a deprecated SCSI ioctl, please convert it to SG_IO\n, current-comm);
err = -EINVAL;
if (!arg)
break;
diff -uprN linux-2.6.11/drivers/input/keyboard/atkbd.c
linux-2.6.11.new/drivers/input/keyboard/atkbd.c
--- linux-2.6.11/drivers/input/keyboard/atkbd.c 2005-03-03 15:41:33.0
+0100
+++ linux-2.6.11.new/drivers/input/keyboard/atkbd.c 2005-03-18
22:45:42.0 +0100
@@ -320,7 +320,7 @@ static irqreturn_t atkbd_interrupt(struc
atkbd_report_key(atkbd-dev, regs, KEY_HANJA, 3);
goto out;
case ATKBD_RET_ERR:
- printk(KERN_DEBUG atkbd.c: Keyboard on %s reports too
many keys pressed.\n, serio-phys);
+ printk_nospam(2260620158, KERN_DEBUG atkbd.c: Keyboard
on %s reports too many keys pressed.\n, serio-phys);
goto out;
}
diff -uprN linux-2.6.11/fs/nfs/inode.c linux-2.6.11.new/fs/nfs/inode.c
--- linux-2.6.11/fs/nfs/inode.c 2005-03-03 15:41:59.0 +0100
+++ linux-2.6.11.new/fs/nfs/inode.c 2005-03-18 22:48:09.0 +0100
@@ -1386,7 +1386,7 @@ static struct super_block *nfs_get_sb(st
init_nfsv4_state(server);
if (data-version != NFS_MOUNT_VERSION) {
- printk(nfs warning: mount version %s than kernel\n,
+ printk_nospam(1377481036, nfs warning: mount version %s than
kernel\n,
data-version NFS_MOUNT_VERSION ? older : newer);
if (data-version 2)
data-namlen = 0;
diff -uprN linux-2.6.11/include/linux/kernel.h
linux-2.6.11.new/include/linux/kernel.h
--- linux-2.6.11/include/linux/kernel.h 2005-03-03 15:42:13.0 +0100
+++ linux-2.6.11.new/include/linux/kernel.h 2005-03-18 22:06:42.0
+0100
@@ -104,6 +104,10 @@ extern int session_of_pgrp(int pgrp);
asmlinkage int vprintk(const char *fmt, va_list args);
asmlinkage int printk(const char * fmt, ...)
__attribute__ ((format (printf, 1, 2)));
+asmlinkage int printk_nospam(int magic, const char * fmt, ...)
+ __attribute__ ((format (printf, 2, 3)));
+/* use a random value for the magic, e.g. the first value from
+ cksum on the file you're editing */
unsigned long int_sqrt(unsigned long);
diff -uprN linux-2.6.11/kernel/printk.c linux-2.6.11.new/kernel/printk.c
--- linux-2.6.11/kernel/printk.c2005-03-18
Re: BKCVS broken ?
It should be fixed now, I'm running a full tree compare to validate that. -- --- Larry McVoylm at bitmover.com http://www.bitkeeper.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] small partitions/msdos cleanups
This patch makes the following changes to the msdos partition code: - remove CONFIG_NEC98_PARTITION leftovers - make parse_bsd static This patch was already ACK'ed by Andries Brouwer. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- @Andrew: I've removed the accidental double slashes from the pathnames that worked fine with GNU patch but might have confused your scripts. This patch was already sent on: - 11 Mar 2005 - 25 Feb 2005 - 1 Feb 2005 - 7 Jan 2005 - 14 Dec 2004 - 7 Dec 2004 - 30 Oct 2004 diffstat output: fs/partitions/Makefile |1 - fs/partitions/check.c |3 --- fs/partitions/check.h |4 fs/partitions/msdos.c |4 ++-- 4 files changed, 2 insertions(+), 10 deletions(-) --- linux-2.6.10-rc1-mm2-full/fs/partitions/Makefile.old2004-10-30 14:42:03.0 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/partitions/Makefile2004-10-30 14:42:13.0 +0200 @@ -17,4 +17,3 @@ obj-$(CONFIG_ULTRIX_PARTITION) += ultrix.o obj-$(CONFIG_IBM_PARTITION) += ibm.o obj-$(CONFIG_EFI_PARTITION) += efi.o -obj-$(CONFIG_NEC98_PARTITION) += nec98.o msdos.o --- linux-2.6.10-rc1-mm2-full/fs/partitions/check.h.old 2004-10-30 14:40:20.0 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/partitions/check.h 2004-10-30 14:40:41.0 +0200 @@ -30,7 +30,3 @@ extern int warn_no_part; -extern void parse_bsd(struct parsed_partitions *state, - struct block_device *bdev, u32 offset, u32 size, - int origin, char *flavour, int max_partitions); - --- linux-2.6.10-rc1-mm2-full/fs/partitions/check.c.old 2004-10-30 14:41:32.0 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/partitions/check.c 2004-10-30 14:41:43.0 +0200 @@ -76,9 +76,6 @@ #ifdef CONFIG_LDM_PARTITION ldm_partition, /* this must come before msdos */ #endif -#ifdef CONFIG_NEC98_PARTITION - nec98_partition,/* must be come before `msdos_partition' */ -#endif #ifdef CONFIG_MSDOS_PARTITION msdos_partition, #endif --- linux-2.6.10-rc1-mm2-full/fs/partitions/msdos.c.old 2004-10-30 14:38:38.0 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/partitions/msdos.c 2004-10-30 14:41:57.0 +0200 @@ -202,12 +202,12 @@ #endif } -#if defined(CONFIG_BSD_DISKLABEL) || defined(CONFIG_NEC98_PARTITION) +#if defined(CONFIG_BSD_DISKLABEL) /* * Create devices for BSD partitions listed in a disklabel, under a * dos-like partition. See parse_extended() for more information. */ -void +static void parse_bsd(struct parsed_partitions *state, struct block_device *bdev, u32 offset, u32 size, int origin, char *flavour, int max_partitions) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bcm203x broadcom dongle firmware upload fails...
hi, I don't see why, it used to work reliably at some point but now it does not. It even won't work without hotplug and then manually typing: echo 1 /sys/class/firmware/2-1/loading cat /lib/firmware/BCM2033-FW.bin /sys/class/firmware/2-1/data echo 0 /sys/class/firmware/2-1/loading usb 2-1: new full speed USB device using ohci_hcd and address 2 Bluetooth: Broadcom Blutonium firmware driver ver 1.0 bcm203x_probe: Mini driver request failed bcm203x: probe of 2-1:1.0 failed with error -5 usbcore: registered new driver bcm203x It does not work with kernel 2.6.10/11 any ideas ? Soeren -- Sometimes, there's a moment as you're waking, when you become aware of the real world around you, but you're still dreaming. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel BUG at rmap:482
On Sat, 19 Mar 2005, hib2743 wrote:
I have seen discussion about this in recent months on the list, and
unfortunately I am experiencing the same problem myself now on a new
machine. I have run memtest86 for some hours and there seems to be no
problem. The machine has 1GB DDR PC3200 RAM/AMD Athlon(tm) 64 Processor
3500+/ASUS A8V motherboard/120GB Seagate SATA HDD. If you have a patch
you would like me to try I am willing to have a go, this is a new
machine which I waiting to deploy, so there is no production data on it
at all yet. I can reproduce the problem fairly regularly, just set the
machine to compile something big like glibc, and I get it within an hour
usually...
That's the first sighting I've heard of on x86_64: I've only tried the
patch on i386, but it should be good for x86_64 too. Please do give it
a try, and report back (probably better just to me) what Bad rmap and
Bad page state messages you then find. As a side-effect, it should
allow you to go on running (showing more messages) for longer.
Thanks,
Hugh
--- 2.6.11/include/linux/rmap.h 2004-12-24 21:36:18.0 +
+++ linux/include/linux/rmap.h 2005-02-24 20:52:17.0 +
@@ -72,7 +72,7 @@ void __anon_vma_link(struct vm_area_stru
*/
void page_add_anon_rmap(struct page *, struct vm_area_struct *, unsigned long);
void page_add_file_rmap(struct page *);
-void page_remove_rmap(struct page *);
+void page_remove_rmap(struct page *, struct vm_area_struct *, unsigned long);
/**
* page_dup_rmap - duplicate pte mapping to a page
--- 2.6.11/mm/fremap.c 2005-02-24 20:11:11.0 +
+++ linux/mm/fremap.c 2005-02-24 20:52:17.0 +
@@ -37,7 +37,7 @@ static inline void zap_pte(struct mm_str
if (!PageReserved(page)) {
if (pte_dirty(pte))
set_page_dirty(page);
- page_remove_rmap(page);
+ page_remove_rmap(page, vma, addr);
page_cache_release(page);
mm-rss--;
}
--- 2.6.11/mm/memory.c 2005-02-24 20:11:11.0 +
+++ linux/mm/memory.c 2005-02-24 20:52:17.0 +
@@ -452,6 +452,7 @@ next_pgd:
}
static void zap_pte_range(struct mmu_gather *tlb,
+ struct vm_area_struct *vma,
pmd_t *pmd, unsigned long address,
unsigned long size, struct zap_details *details)
{
@@ -517,7 +518,7 @@ static void zap_pte_range(struct mmu_gat
else if (pte_young(pte))
mark_page_accessed(page);
tlb-freed++;
- page_remove_rmap(page);
+ page_remove_rmap(page, vma, address+offset);
tlb_remove_page(tlb, page);
continue;
}
@@ -535,6 +536,7 @@ static void zap_pte_range(struct mmu_gat
}
static void zap_pmd_range(struct mmu_gather *tlb,
+ struct vm_area_struct *vma,
pud_t *pud, unsigned long address,
unsigned long size, struct zap_details *details)
{
@@ -553,13 +555,14 @@ static void zap_pmd_range(struct mmu_gat
if (end ((address + PUD_SIZE) PUD_MASK))
end = ((address + PUD_SIZE) PUD_MASK);
do {
- zap_pte_range(tlb, pmd, address, end - address, details);
+ zap_pte_range(tlb, vma, pmd, address, end - address, details);
address = (address + PMD_SIZE) PMD_MASK;
pmd++;
} while (address (address end));
}
static void zap_pud_range(struct mmu_gather *tlb,
+ struct vm_area_struct *vma,
pgd_t * pgd, unsigned long address,
unsigned long end, struct zap_details *details)
{
@@ -574,7 +577,7 @@ static void zap_pud_range(struct mmu_gat
}
pud = pud_offset(pgd, address);
do {
- zap_pmd_range(tlb, pud, address, end - address, details);
+ zap_pmd_range(tlb, vma, pud, address, end - address, details);
address = (address + PUD_SIZE) PUD_MASK;
pud++;
} while (address (address end));
@@ -595,7 +598,7 @@ static void unmap_page_range(struct mmu_
next = (address + PGDIR_SIZE) PGDIR_MASK;
if (next = address || next end)
next = end;
- zap_pud_range(tlb, pgd, address, next, details);
+ zap_pud_range(tlb, vma, pgd, address, next, details);
address = next;
pgd++;
}
@@ -1343,7 +1346,7 @@ static int do_wp_page(struct mm_struct *
acct_update_integrals();
update_mem_hiwater();
} else
- page_remove_rmap(old_page);
+ page_remove_rmap(old_page, vma,
Re: Linux 2.4.30-rc1
Hi Marcelo, 2.4.30-rc1 works fine here on athlon-SMP and sparc64-smp. BTW, the athlon uses the e1000 driver (which has been updated since 2.4.29) with no trouble at all. I'll post a 2.4.29-hf5 in a few hours, just the time to put the thing online, it already builds on the same machines. Cheers, Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel panic - r8169 on 2.6.11-rc1-mm1
Every time i try to use eth1 which is r8169, i get a kernel panic, but
on the actual use of it, not the configuring it.
e.g.
laptop ~ # ifconfig eth1 up 192.168.1.1
laptop ~ # ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
Oops: [#1]
Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq_oss
seq_midi_event snd_seq snd_seq_device irtty_sir sir_dev irda pcspkr
snd_intel8x0 snd_ac97_codec snd_pcm snd_timer
snd snd_page_alloc wlan_wep fglrx sis_agp psmouse r8169 ath_pci
ath_rate_onoe wlan ath_hal
CPU:0
EIP:0060:[d15481e5] Tainted: P VLI
EFLAGS: 00010206(2.6.11-rc1-mm1)
EIP is at rtl8169_start_xmit+0x55/0x2b0 [r8169]
eax: 003f ebx: cf236140 ecx: cc9c6000 edx:
esi: cf236240 edi: cfd9b280 ebp: cfd9b280 esp: c0685e00
ds: 007bes: 007bss: 0068
Process swapper (pid: 0, threadinfo=c0684000 task=c05b6ba0)
Stack: c0107e50 cf236140 cf935080 cfd9b280 d14da000 cc9c6000
8000 cf236140 cf935080 cf236000 cfd9b280 c049141e cfd9b280 cf236000
cf236000 cfd9b280 cf236140 c048387f cf236000 cf935080
0Kernel panic - not syncing: Fatal exception in interrupt
I never had time to write down the whole stack trace (and there was no
core file created)
This driver used to work in a previous kernel version (but it did get
IRQ #x nobody cared messages, usually when there was some sort of a
disconnection of my ethernet cable for whatever reason). This is
always reproducable.
uname -a:
Linux laptop 2.6.11-rc1-mm1 #2 SMP Sun Jan 16 22:36:26 GMT 2005 i686
Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux
I would try a newer kernel, but the command line options for
specifying the framebuffer settings seems to have changed in the
latest kernel and i haven't had enough time to work out how to specify
it.
--
Cameron Harris
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new hp diva console port
On Fri, Mar 18, 2005 at 09:30:22AM -0700, Alex Williamson wrote: The patch below adds IDs and setup for a new PCI Diva console port. This device provides a single UART described by PCI Bar 1. ID already submitted to pciids.sf.net. Please apply. Thanks, Applied, thanks. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Scheduling changes in -mm tree
I don't think these are doing much for performance. Or at least *something* in your tree isn't ... Kernbench: ElapsedSystem User CPU elm3b67 2.6.11 50.24146.60 1117.61 2516.67 elm3b67 2.6.11-mm1 52.27141.14 1099.91 2374.33 elm3b67 2.6.11-mm2 51.88142.41 1104.85 2403.67 elm3b67 2.6.11-mm4 51.23145.04 1100.70 2431.00 (elm3b67 is a 16x x440 ia32 NUMA system + HT) Is there an easy way to just test those sched changes alone? M. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.4.30-rc1] updated gcc-4.0 patches
Here is a new set of patches to allow gcc-4.0 (20050312)
to compile the 2.4.30-rc1 kernel. Changes since the previous
version of the patch set are:
- Replaced -ffreestanding with -fno-builtin-sprintf.
freestanding was used to prevent gcc from transforming some
sprintf() calls to calls to strcpy(), but no-builtin-sprintf
solves that problem w/o the other problems of freestanding.
(Thanks to Mikael Starvik for the -fno-builtin-sprintf hint.)
- Removed the abs()-related workarounds I had before because
of -ffreestanding.
- Fixed typo in linux/compiler.h's #ifdef around the
__attribute_const__ definition. (Found by Mikael Starvik.)
Tested on i386, ppc32, and x86-64. The only known problem is
that the X server segfaults during PCI probing on x86-64. I'm
currently debugging that.
In addition to this core patch there is a big pile of compile
fixes to drivers etc that haven't been runtime tested. That patch
is too large for sending to LKML, so it's downloadable as
http://www.csd.uu.se/~mikpe/linux/patches/2.4/patch-more-gcc4-fixes-v1-2.4.30-rc1.
/Mikael
diff -rupN linux-2.4.30-rc1/Makefile linux-2.4.30-rc1.gcc4-fixes-v9/Makefile
--- linux-2.4.30-rc1/Makefile 2005-03-19 11:27:37.0 +0100
+++ linux-2.4.30-rc1.gcc4-fixes-v9/Makefile 2005-03-19 11:37:32.0
+0100
@@ -93,11 +93,17 @@ CPPFLAGS := -D__KERNEL__ -I$(HPATH)
CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
-fno-strict-aliasing -fno-common
+CFLAGS += -fno-builtin-sprintf
ifndef CONFIG_FRAME_POINTER
CFLAGS += -fomit-frame-pointer
endif
AFLAGS := -D__ASSEMBLY__ $(CPPFLAGS)
+check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null /dev/null
21; then echo $(1); else echo $(2); fi)
+
+# disable pointer signedness warnings in gcc 4.0
+CFLAGS += $(call check_gcc,-Wno-pointer-sign,)
+
#
# ROOT_DEV specifies the default root-device when making the image.
# This can be either FLOPPY, CURRENT, /dev/ or empty, in which case
diff -rupN linux-2.4.30-rc1/arch/i386/Makefile
linux-2.4.30-rc1.gcc4-fixes-v9/arch/i386/Makefile
--- linux-2.4.30-rc1/arch/i386/Makefile 2004-11-17 18:36:41.0 +0100
+++ linux-2.4.30-rc1.gcc4-fixes-v9/arch/i386/Makefile 2005-03-19
11:37:32.0 +0100
@@ -23,8 +23,6 @@ LINKFLAGS =-T $(TOPDIR)/arch/i386/vmlinu
CFLAGS += -pipe
-check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null /dev/null
21; then echo $(1); else echo $(2); fi)
-
# prevent gcc from keeping the stack 16 byte aligned
CFLAGS += $(call check_gcc,-mpreferred-stack-boundary=2,)
diff -rupN linux-2.4.30-rc1/arch/mips/Makefile
linux-2.4.30-rc1.gcc4-fixes-v9/arch/mips/Makefile
--- linux-2.4.30-rc1/arch/mips/Makefile 2005-01-19 18:00:52.0 +0100
+++ linux-2.4.30-rc1.gcc4-fixes-v9/arch/mips/Makefile 2005-03-19
11:37:32.0 +0100
@@ -30,8 +30,6 @@ endif
MAKEBOOT = $(MAKE) -C arch/$(ARCH)/boot
-check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null /dev/null
21; then echo $(1); else echo $(2); fi)
-
#
#
# GCC uses -G 0 -mabicalls -fpic as default. We don't want PIC in the kernel
diff -rupN linux-2.4.30-rc1/arch/mips64/Makefile
linux-2.4.30-rc1.gcc4-fixes-v9/arch/mips64/Makefile
--- linux-2.4.30-rc1/arch/mips64/Makefile 2005-01-19 18:00:52.0
+0100
+++ linux-2.4.30-rc1.gcc4-fixes-v9/arch/mips64/Makefile 2005-03-19
11:37:32.0 +0100
@@ -26,7 +26,6 @@ ifdef CONFIG_CROSSCOMPILE
CROSS_COMPILE = $(tool-prefix)
endif
-check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null /dev/null
21; then echo $(1); else echo $(2); fi)
check_gas = $(shell if $(CC) $(1) -Wa,-Z -c -o /dev/null -xassembler /dev/null
/dev/null 21; then echo $(1); else echo $(2); fi)
#
diff -rupN linux-2.4.30-rc1/arch/ppc/kernel/open_pic_defs.h
linux-2.4.30-rc1.gcc4-fixes-v9/arch/ppc/kernel/open_pic_defs.h
--- linux-2.4.30-rc1/arch/ppc/kernel/open_pic_defs.h2003-06-14
13:30:19.0 +0200
+++ linux-2.4.30-rc1.gcc4-fixes-v9/arch/ppc/kernel/open_pic_defs.h
2005-03-19 11:37:32.0 +0100
@@ -172,9 +172,6 @@ struct OpenPIC {
OpenPIC_Processor Processor[OPENPIC_MAX_PROCESSORS];
};
-extern volatile struct OpenPIC *OpenPIC;
-
-
/*
* Current Task Priority Register
*/
diff -rupN linux-2.4.30-rc1/arch/ppc/kernel/time.c
linux-2.4.30-rc1.gcc4-fixes-v9/arch/ppc/kernel/time.c
--- linux-2.4.30-rc1/arch/ppc/kernel/time.c 2003-08-25 20:07:42.0
+0200
+++ linux-2.4.30-rc1.gcc4-fixes-v9/arch/ppc/kernel/time.c 2005-03-19
11:37:32.0 +0100
@@ -84,7 +84,7 @@ unsigned tb_last_stamp;
extern unsigned long wall_jiffies;
-static long time_offset;
+static long ppc_time_offset;
spinlock_t rtc_lock = SPIN_LOCK_UNLOCKED;
@@ -187,7 +187,7 @@ int timer_interrupt(struct pt_regs * reg
xtime.tv_sec - last_rtc_update = 659
abs(xtime.tv_usec - (100-100/HZ)) 50/HZ
jiffies - wall_jiffies == 1) {
-
Re: Real-Time Preemption and RCU
* Manfred Spraul [EMAIL PROTECTED] wrote: Ingo Molnar wrote: read_lock(rwlock); ... read_lock(rwlock); are still legal. (it's also done quite often.) How do you handle the write_lock_irq()/read_lock locks? E.g. the tasklist_lock or the fasync_lock. which precise locking situation do you mean? Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix agp_backend usage in drm_agp_init (was: 2.6.11-mm3 - DRM/i915 broken)
On Friday, March 18, 2005 7:48 pm, Jesse Barnes wrote: On Friday, March 18, 2005 7:40 pm, Jesse Barnes wrote: What does your patch look like? Markus might like to try it out as he narrowed his problem down to something AGP related recently too: http://bugme.osdl.org/show_bug.cgi?id=4337 duh, ignore me. At least Markus can give it a try. Oh well, Brice's patch didn't work for Marcus (symptoms were different anyway so it was a long shot). I really have to find an AGP machine with a single pipe to test this stuff on... Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Real-Time Preemption and RCU
* Herbert Xu [EMAIL PROTECTED] wrote: Ingo Molnar [EMAIL PROTECTED] wrote: i really have no intention to allow multiple readers for rt-mutexes. We got away with that so far, and i'd like to keep it so. Imagine 100 threads all blocked in the same critical section (holding the read-lock) when a highprio writer thread comes around: instant 100x latency to let all of them roll forward. The only sane solution is to not allow excessive concurrency. (That limits SMP scalability, but there's no other choice i can see.) What about allowing only as many concurrent readers as there are CPUs? since a reader may be preempted by a higher prio task, there is no linear relationship between CPU utilization and the number of readers allowed. You could easily end up having all the nr_cpus readers preempted on one CPU. It gets pretty messy. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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][MMC][1/6] Secure Digital (SD) support : protocol
On Sun, Mar 06, 2005 at 02:37:01AM +0100, Pierre Ossman wrote: Protocol definitions. The basic commands needed for the later patches. The R1_APP_CMD seems to be misdefined in protocol.h so this patch changes it. Applied, thanks. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation
On Sat, 2005-03-19 at 08:16 -0600, Matt Domsch wrote: On Sat, Mar 19, 2005 at 07:09:45AM +0100, Arjan van de Ven wrote: On Fri, 2005-03-18 at 15:23 -0600, Matt Domsch wrote: For review and comment. On x86_64 systems with no IOMMU and with 4GB RAM (in fact, whenever there are any pages mapped above 4GB), pci_alloc_consistent() falls back to using ZONE_DMA for all allocations, even if the device's dma_mask could have supported using memory from other zones. Problems can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume all of ZONE_DMA, leaving none left for pci_alloc_consistent() use. scsi_malloc no longer uses ZONE_DMA nowadays In 2.4.x it does. scsi_resize_dma_pool() has: __get_free_pages(GFP_ATOMIC | GFP_DMA, 0); scsi_init_minimal_dma_pool() has similar. oh you want to do major changes to the 2.4 tree... sounds like a bad idea to change such vm behavior.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][0/7] cifs: file.c cleanups in incremental bits
Jesper Juhl wrote: Here 's a version of my fs/cifs/file.c cleanup patch split into seven chunks for easier review. Please use these incremental patches instead of the big one I send you earlier since I've made a few changes compared to that. For your convenience the patches are also available online at : http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_file-cleanups-3-whitespace-changes.patch http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_file-cleanups-3-kfree-changes.patch http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_file-cleanups-3-cifs_init_private.patch http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_file-cleanups-3-cifs_open_inode_helper.patch http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_file-cleanups-3-cifs_convert_flags.patch http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_file-cleanups-3-cifs_get_disposition.patch http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_file-cleanups-3-condense_if_else.patch (listed in the order they apply) I have reviewed and applied the first two, and also reviewed the get_disposition patch (which is also fine). I will review the others this weekend. Good work - thanks. I still haven't managed to get hold of/setup a cifs server to test these against, so they are still only compile tested. I did some testing of this against Samba server last night. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-2.4.29-hf5
Hi all, Here's the fifth hotfix for linux-2.4.29 : http://linux.exosec.net/kernel/2.4-hf/ NOTE: This update fixes a remote security issue on PPP servers which is also fixed in 2.4.30-rc1 (thanks to Paul Mackerras). I've appended the changelog from 2.4.29-hf4 below, and the incremental diff (very small). I'd like to thank particularly Grant Coady, who has compiled a lot of -hf kernels on several of his machines and maintains a build report on his page linked below. Those interested can check his site for more information : http://scatter.mine.nu/linux-2.4-hotfix/ When Marcelo starts 2.4.30-bk, I'll start a 2.4.30-hf and still maintain 2.4.29-hf in parallel (at least as long as I'll see downloads of this version in the server's logs). Of course, given the small number of changes between 2.4.29 and 2.4.30-rc1, everyone is encouraged to upgrade to 2.4.30 ASAP and stick to mainline as much as possible. Regards, Willy -- Changelog From 2.4.29-hf4 to 2.4.29-hf5 (semi-automated) --- '+' = added ; '-' = removed Note: This update fixes a remote security issue on PPP servers. + ppp-server-remote-dos-1 (Paul Mackerras) Remote Linux DoS on ppp servers (CAN-2005-0384) + x86_64-fix-x87-tag-word-emulation-1 (Roland McGrath) Fix x87 fnsave Tag Word emulation when using FXSR (SSE). The fxsave instruction does not save the x87 tag word (only the empty bits), and we re-created the old-style x87 tags incorrectly. The registers are saved in stack order in the save area, but the tag word bits are in hardware order, and we need to get the right register state. Both x86 and x86-64 needed this fix. + possible-pty-line-discipline-race-1 (Linus Torvalds) [PATCH] Workaround possible pty line discipline race. It's in no way correct, in that the race hasn't actually gone away by this patch, but the patch makes it unimportant. We may end up calling a stale line discipline, which is still very wrong, but it so happens that we don't much care in practice. I think that in a 2.4.x tree there are some theoretical SMP races with module unloading etc (which the 2.6.x code doesn't have because module unload stops the other CPU's - maybe that part got backported to 2.4.x?), but quite frankly, I suspect that even in 2.4.x they are entirely theoretical and impossible to actually hit. And again, in theory some line discipline might do something strange in it's chars_in_buffer routine that would be problematic. In practice that's just not the case: the chars_in_buffer() routine might return a bogus _value_ for a stale line discipline thing, but none of them seem to follow any pointers that might have become invalid (and in fact, most ldiscs don't even have that function). + softdog-does-not-reboot-on-close-1 (Jacques Basson) There is a bug in the softdog.c (v 0.05) in the 2.4 kernel series (certainly in 2.4.29 and there are no references to it in the latest Changelog) that won't reboot the machine if /dev/watchdog is closed unexpectedly and nowayout is not set. - scsi-tapes-allow-lseek-1(Marcelo Tosatti) + scsi-tapes-allow-lseek-2(Marcelo Tosatti) Fixed lseek on OSST tapes too. + write-throttling-ignore-free-highmem-1 (Andrea Arcangeli) I got reports of stalls with heavy writes on 2.4. There was a mistake in nr_free_buffer_pages. That function is definitely meant _not_ to take highmem into account (dirty cache cannot spread over highmem in 2.4 [even when on top of fs]). For unknown reasons it was actually taking highmem into account. The code was obviously meant to not take into account see the GFP_USER and zonelist, except it wasn't using the zonelist. That is a severe problem because there will be no write throttling at all, and no bdflush wakeup either. This is a noop for all systems 800M (1G shouldn't be noticeable either). This is why most people can't notice. + get_user_pages-no-pg_reserved-1(Andrea Arcangeli) get_user_pages() shall not grab PG_reserved pages. + sparc32-fix-parallel-build-1(crn:netunix.com) [SPARC32]: Fix build dependencies for vmlinux.o This helps make parallel builds work properly. -- diff -urN linux-2.4.29-hf4/Makefile linux-2.4.29-hf5/Makefile --- linux-2.4.29-hf4/Makefile 2005-03-19 17:50:48.0 +0100 +++ linux-2.4.29-hf5/Makefile 2005-03-19 17:47:41.0 +0100 @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 29 -EXTRAVERSION = -hf4 +EXTRAVERSION = -hf5 KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) diff -urN linux-2.4.29-hf4/arch/i386/kernel/i387.c linux-2.4.29-hf5/arch/i386/kernel/i387.c --- linux-2.4.29-hf4/arch/i386/kernel/i387.c2003-08-25 13:44:39.0
Re: Kernel panic - r8169 on 2.6.11-rc1-mm1
Cameron Harris [EMAIL PROTECTED] : [r8169 crash] Linux laptop 2.6.11-rc1-mm1 #2 SMP Sun Jan 16 22:36:26 GMT 2005 i686 ^^ [...] I would try a newer kernel, but the command line options for specifying the framebuffer settings seems to have changed in the latest kernel and i haven't had enough time to work out how to specify it. If you can not upgrade the kernel, I can not do anything for you since several fixes went in after 2.6.11-rc1-mm1. Regarding your r8169 issue, I suggest: 1) download linux kernel 2.6.12-rc1 2) apply on top of it: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.11/r8169/patches/r8169-570.patch 3) avoid the proprietary tainting module Please Cc: netdev@oss.sgi.com for issues related to network drivers. -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bitrotting serial drivers
Hi, m32r_sio Maintainer: Hirokazu Takata Please clean up the m32r_sio driver, removing whatever bits of code aren't absolutely necessary. Specifically, I'd like to see the following addressed: - the usage of SERIAL_IO_HUB6 (this driver doesn't support hub6 cards) - SERIAL_IO_* should be UPIO_* - __register_m32r_sio, register_m32r_sio, unregister_m32r_sio, m32r_sio_get_irq_map (this driver doesn't support PCMCIA cards, all of which are based on 8250-compatible devices.) - early_serial_setup (should we really have the function name duplicated across different hardware drivers?) au1x00_uart --- Maintainer: unknown (akpm - any ideas?) This is a complete clone of 8250.c, which includes all the 8250-specific structure names. Specifically, I'd like to see the following addressed: - Please clean this up to use au1x00-specific names. - this driver is lagging behind with fixes that the other drivers are getting. Is au1x00_uart actually maintained? - the usage of UPIO_HUB6 (this driver doesn't support hub6 cards) - __register_serial, register_serial, unregister_serial (this driver doesn't support PCMCIA cards, all of which are based on 8250-compatible devices.) - early_serial_setup (should we really have the function name duplicated across different hardware drivers?) The main reason is I wish to kill off uart_register_port and uart_unregister_port, but these drivers are using it. Thanks. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] timers: description
Hello. These patches are updated version of 'del_timer_sync: proof of concept' 2 patches. 1/5: unchanded. 2/5: del_timer_sync() simplified. It is not neccessary to unlock and retry if __TIMER_PENDING has changed, it is only neccessary if timer's base == (timer-_base ~1) has changed. Also, comments are updated. 3/5: The reworked del_timer_sync() can't work unless timers are serialized wrt to itself. They are not. I missed the fact that __mod_timer() can change timer's base while the timer is running. 4/5: remove memory barrier in __run_timers() and del_timer(). 5/5: kill ugly __get_base(), it was temporal. The del_singleshot_timer_sync function now unneeded, but it looks like additional test for del_timer_sync(), so it will be removed later. Btw, add_timer_on() is racy against __mod_timer(), is it worth fixing? Oleg. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] timers: prepare for del_timer_sync() changes
There are problems with del_timer_sync().
1. Scalability. All cpus are scanned to determine if the timer is
running on that cpu.
2. It is racy. The timer can be fired again after del_timer_sync
have checked all cpus and before it will recheck timer_pending().
This patch adds 'pending flag' to timer_list. This flag is encoded
in the least significant bit of timer-base. This way we do not
waste the space and can read/write base+pending atomically.
__run_timers(), del_timer() do not set -base = NULL anymore, they
only clear pending flag, so that del_timer_sync can wait while
timer-base-running_timer == timer.
It works only if recurring timer do not use add_timer_on().
The following patch renames -base to -_base. Now this field is
used directly only in __get_base/__set_base helpers.
No changes in kernel/timer.o.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 2.6.12-rc1/include/linux/timer.h~1_BASE 2005-03-19 14:54:58.0
+0300
+++ 2.6.12-rc1/include/linux/timer.h2005-03-19 15:05:46.0 +0300
@@ -18,16 +18,21 @@ struct timer_list {
void (*function)(unsigned long);
unsigned long data;
- struct tvec_t_base_s *base;
+ struct tvec_t_base_s *_base;
};
+static inline int __timer_pending(struct tvec_t_base_s *base)
+{
+ return base != NULL;
+}
+
#define TIMER_MAGIC0x4b87ad6e
#define TIMER_INITIALIZER(_function, _expires, _data) {\
.function = (_function),\
.expires = (_expires), \
.data = (_data),\
- .base = NULL, \
+ ._base = NULL, \
.magic = TIMER_MAGIC, \
.lock = SPIN_LOCK_UNLOCKED, \
}
@@ -41,7 +46,7 @@ struct timer_list {
*/
static inline void init_timer(struct timer_list * timer)
{
- timer-base = NULL;
+ timer-_base = NULL;
timer-magic = TIMER_MAGIC;
spin_lock_init(timer-lock);
}
@@ -58,7 +63,7 @@ static inline void init_timer(struct tim
*/
static inline int timer_pending(const struct timer_list * timer)
{
- return timer-base != NULL;
+ return __timer_pending(timer-_base);
}
extern void add_timer_on(struct timer_list *timer, int cpu);
--- 2.6.12-rc1/kernel/timer.c~1_BASE2005-03-19 14:55:17.0 +0300
+++ 2.6.12-rc1/kernel/timer.c 2005-03-19 15:05:46.0 +0300
@@ -86,6 +86,20 @@ static inline void set_running_timer(tve
#endif
}
+static inline tvec_base_t *__get_base(struct timer_list *timer)
+{
+ return timer-_base;
+}
+
+static inline void __set_base(struct timer_list *timer,
+ tvec_base_t *base, int pending)
+{
+ if (pending)
+ timer-_base = base;
+ else
+ timer-_base = NULL;
+}
+
/* Fake initialization */
static DEFINE_PER_CPU(tvec_base_t, tvec_bases) = { SPIN_LOCK_UNLOCKED };
@@ -169,7 +183,7 @@ int __mod_timer(struct timer_list *timer
spin_lock_irqsave(timer-lock, flags);
new_base = __get_cpu_var(tvec_bases);
repeat:
- old_base = timer-base;
+ old_base = __get_base(timer);
/*
* Prevent deadlocks via ordering by old_base new_base.
@@ -186,14 +200,14 @@ repeat:
* The timer base might have been cancelled while we were
* trying to take the lock(s):
*/
- if (timer-base != old_base) {
+ if (__get_base(timer) != old_base) {
spin_unlock(new_base-lock);
spin_unlock(old_base-lock);
goto repeat;
}
} else {
spin_lock(new_base-lock);
- if (timer-base != old_base) {
+ if (__get_base(timer) != old_base) {
spin_unlock(new_base-lock);
goto repeat;
}
@@ -209,7 +223,7 @@ repeat:
}
timer-expires = expires;
internal_add_timer(new_base, timer);
- timer-base = new_base;
+ __set_base(timer, new_base, 1);
if (old_base (new_base != old_base))
spin_unlock(old_base-lock);
@@ -239,7 +253,7 @@ void add_timer_on(struct timer_list *tim
spin_lock_irqsave(base-lock, flags);
internal_add_timer(base, timer);
- timer-base = base;
+ __set_base(timer, base, 1);
spin_unlock_irqrestore(base-lock, flags);
}
@@ -301,18 +315,18 @@ int del_timer(struct timer_list *timer)
check_timer(timer);
repeat:
- base = timer-base;
+ base = __get_base(timer);
if (!base)
return 0;
spin_lock_irqsave(base-lock, flags);
- if (base != timer-base) {
+ if (base != __get_base(timer)) {
[PATCH 5/5] timers: cleanup, kill __get_base()
__get_base() was added to reduce the changes in
previous patches. This patch removes it.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 2.6.12-rc1/kernel/timer.c~5_CLEAN 2005-03-19 22:28:34.0 +0300
+++ 2.6.12-rc1/kernel/timer.c 2005-03-19 23:34:23.0 +0300
@@ -86,16 +86,6 @@ static inline void set_running_timer(tve
#endif
}
-static inline tvec_base_t *__get_base(struct timer_list *timer)
-{
- tvec_base_t *base = timer-_base;
-
- if (__timer_pending(base))
- return (void*)base - __TIMER_PENDING;
- else
- return NULL;
-}
-
static inline void __set_base(struct timer_list *timer,
tvec_base_t *base, int pending)
{
@@ -323,16 +313,18 @@ EXPORT_SYMBOL(mod_timer);
int del_timer(struct timer_list *timer)
{
unsigned long flags;
- tvec_base_t *base;
+ tvec_base_t *_base, *base;
check_timer(timer);
repeat:
- base = __get_base(timer);
- if (!base)
+ _base = timer-_base;
+ if (!__timer_pending(_base))
return 0;
+
+ base = (void*)_base - __TIMER_PENDING;
spin_lock_irqsave(base-lock, flags);
- if (base != __get_base(timer)) {
+ if (_base != timer-_base) {
spin_unlock_irqrestore(base-lock, flags);
goto repeat;
}
@@ -445,7 +437,7 @@ static int cascade(tvec_base_t *base, tv
struct timer_list *tmp;
tmp = list_entry(curr, struct timer_list, entry);
- BUG_ON(__get_base(tmp) != base);
+ BUG_ON(tmp-_base != ((void*)base + __TIMER_PENDING));
curr = curr-next;
internal_add_timer(base, tmp);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] timers: rework del_timer_sync()
New rules:
-_base 1: is timer pending
-_base ~1: where the timer was last scheduled
-_base == NULL means that this timer is not running on any cpu.
del_timer_sync() clears -_base, it is merely an optimization, so
that subsequent del_timer calls do not need locking.
del_timer_sync() assumes that the timer's base == (-_base ~1)
can't be changed during execution of timer-function. It is achieved
by the next patch.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 2.6.12-rc1/include/linux/timer.h~2_SYNC 2005-03-19 15:05:46.0
+0300
+++ 2.6.12-rc1/include/linux/timer.h2005-03-19 15:28:13.0 +0300
@@ -21,9 +21,26 @@ struct timer_list {
struct tvec_t_base_s *_base;
};
+/*
+ * To save space, we play games with the least significant bit
+ * of timer_list-_base.
+ *
+ * If (_base __TIMER_PENDING), the timer is pending. Implies
+ * (_base ~__TIMER_PENDING) != NULL.
+ *
+ * (_base ~__TIMER_PENDING), if != NULL, is the address of the
+ * timer's per-cpu tvec_t_base_s where it was last scheduled and
+ * where it may still be running.
+ *
+ * If (_base == NULL), the timer was not scheduled yet or it was
+ * cancelled by del_timer_sync(), so it is not running on any CPU.
+ */
+
+#define__TIMER_PENDING 1
+
static inline int __timer_pending(struct tvec_t_base_s *base)
{
- return base != NULL;
+ return ((unsigned long)base __TIMER_PENDING) != 0;
}
#define TIMER_MAGIC0x4b87ad6e
--- 2.6.12-rc1/kernel/timer.c~2_SYNC2005-03-19 15:05:46.0 +0300
+++ 2.6.12-rc1/kernel/timer.c 2005-03-19 17:19:44.0 +0300
@@ -88,16 +88,26 @@ static inline void set_running_timer(tve
static inline tvec_base_t *__get_base(struct timer_list *timer)
{
- return timer-_base;
+ tvec_base_t *base = timer-_base;
+
+ if (__timer_pending(base))
+ return (void*)base - __TIMER_PENDING;
+ else
+ return NULL;
}
static inline void __set_base(struct timer_list *timer,
tvec_base_t *base, int pending)
{
if (pending)
- timer-_base = base;
+ timer-_base = (void*)base + __TIMER_PENDING;
else
- timer-_base = NULL;
+ timer-_base = base;
+}
+
+static inline tvec_base_t *timer_base(struct timer_list *timer)
+{
+ return (tvec_base_t*)((unsigned long)timer-_base ~__TIMER_PENDING);
}
/* Fake initialization */
@@ -346,41 +356,46 @@ EXPORT_SYMBOL(del_timer);
* Synchronization rules: callers must prevent restarting of the timer,
* otherwise this function is meaningless. It must not be called from
* interrupt contexts. The caller must not hold locks which would prevent
- * completion of the timer's handler. Upon exit the timer is not queued and
- * the handler is not running on any CPU.
+ * completion of the timer's handler. The timer's handler must not call
+ * add_timer_on(). Upon exit the timer is not queued and the handler is
+ * not running on any CPU.
*
* The function returns whether it has deactivated a pending timer or not.
- *
- * del_timer_sync() is slow and complicated because it copes with timer
- * handlers which re-arm the timer (periodic timers). If the timer handler
- * is known to not do this (a single shot timer) then use
- * del_singleshot_timer_sync() instead.
*/
int del_timer_sync(struct timer_list *timer)
{
- tvec_base_t *base;
- int i, ret = 0;
+ int ret;
check_timer(timer);
-del_again:
- ret += del_timer(timer);
+ ret = 0;
+ for (;;) {
+ unsigned long flags;
+ tvec_base_t *base;
- for_each_online_cpu(i) {
- base = per_cpu(tvec_bases, i);
- if (base-running_timer == timer) {
- while (base-running_timer == timer) {
- cpu_relax();
- preempt_check_resched();
- }
- break;
+ base = timer_base(timer);
+ if (!base)
+ return ret;
+
+ spin_lock_irqsave(base-lock, flags);
+
+ if (base-running_timer == timer)
+ goto unlock;
+
+ if (timer_base(timer) != base)
+ goto unlock;
+
+ if (timer_pending(timer)) {
+ list_del(timer-entry);
+ ret = 1;
}
+ /* Need to make sure that anybody who sees a NULL base
+* also sees the list ops */
+ smp_wmb();
+ timer-_base = NULL;
+unlock:
+ spin_unlock_irqrestore(base-lock, flags);
}
- smp_rmb();
- if (timer_pending(timer))
- goto del_again;
-
- return ret;
}
EXPORT_SYMBOL(del_timer_sync);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
[PATCH 3/5] timers: serialize timers
I think it is supposed that timers are serialized wrt to itself,
but I can't find any documentation about it.
If CPU_0 does mod_timer(jiffies+1) while the timer is currently
running on CPU 1, it is quite possible that local interrupt on
CPU_0 will start that timer before it finished on CPU_1.
With this patch __mod_timer() locks old_base even if timer is not
pending, like del_timer_sync() does. If the timer is still running,
and old_base != new_base, __mod_timer() retries.
Now we have:
1. the timer's handler can't run on different cpus at
the same time.
2. the timer's base can't be changed during execution
of the timer's handler.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 2.6.12-rc1/kernel/timer.c~3_MOD 2005-03-19 17:19:44.0 +0300
+++ 2.6.12-rc1/kernel/timer.c 2005-03-19 20:16:47.0 +0300
@@ -193,7 +193,7 @@ int __mod_timer(struct timer_list *timer
spin_lock_irqsave(timer-lock, flags);
new_base = __get_cpu_var(tvec_bases);
repeat:
- old_base = __get_base(timer);
+ old_base = timer_base(timer);
/*
* Prevent deadlocks via ordering by old_base new_base.
@@ -208,29 +208,32 @@ repeat:
}
/*
* The timer base might have been cancelled while we were
-* trying to take the lock(s):
+* trying to take the lock(s), or can still be running on
+* old_base's CPU.
*/
- if (__get_base(timer) != old_base) {
+ if (timer_base(timer) != old_base
+ || old_base-running_timer == timer) {
spin_unlock(new_base-lock);
spin_unlock(old_base-lock);
goto repeat;
}
} else {
spin_lock(new_base-lock);
- if (__get_base(timer) != old_base) {
+ if (timer_base(timer) != old_base) {
spin_unlock(new_base-lock);
goto repeat;
}
}
/*
-* Delete the previous timeout (if there was any), and install
-* the new one:
+* Delete the previous timeout (if there was any).
+* We hold timer-lock, no need to check old_base != 0.
*/
- if (old_base) {
+ if (timer_pending(timer)) {
list_del(timer-entry);
ret = 1;
}
+
timer-expires = expires;
internal_add_timer(new_base, timer);
__set_base(timer, new_base, 1);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] timers: remove memory barriers
del_timer() and __run_timers() use smp_wmb() before
clearing timer's pending flag. It was needed because
__mod_timer() did not locked old_base if the timer is
not pending, so __mod_timer()-internal_add_timer()
can race with del_timer()-list_del().
With the previous patch these functions are serialized
through base-lock, so the barrier can be killed.
Still needed in del_timer_sync(), because it clears -_base.
Signed-off-by: Oleg Nesterov [EMAIL PROTECTED]
--- 2.6.12-rc1/kernel/timer.c~4_BARR2005-03-19 22:26:50.0 +0300
+++ 2.6.12-rc1/kernel/timer.c 2005-03-19 22:28:34.0 +0300
@@ -337,8 +337,6 @@ repeat:
goto repeat;
}
list_del(timer-entry);
- /* Need to make sure that anybody who sees a NULL base also sees the
list ops */
- smp_wmb();
__set_base(timer, base, 0);
spin_unlock_irqrestore(base-lock, flags);
@@ -496,7 +494,6 @@ repeat:
list_del(timer-entry);
set_running_timer(base, timer);
- smp_wmb();
__set_base(timer, base, 0);
spin_unlock_irq(base-lock);
{
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Relayfs question
Hello, according to the relayfs description on opersys.com, |As the Linux kernel matures, there is an ever increasing number of facilities |and tools that need to relay large amounts of data from kernel space to user |space. Up to this point, each of these has had its own mechanism for relaying |data. To supersede the individual mechanisms, we introduce the high-speed |data relay filesystem (relayfs). As such, things like LTT, printk, EVLog, |etc. This sounds to me like it would obsolete most character-based devices, e.g. random and urandom. What do the relayfs developers say to this? Jan Engelhardt -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Need break driver--pci-device automatic association
Stuart, Many thanks for this interesting approach. A huge advantage is that it can be implemented as a script. But: -it still requires the Linux newcomer who wants his modem to work, to recompile her/his kernel - something which frightens beginners. -it implies that when adding a serial device such as an other modem, or a serial scanner, the kernel ought again to be recompiled according to the new hardware configuration. -and at each kernel upgrade, often automatic in large organizations, the kernel must again be tailored to the configuration. Thanks again - Jacques On Fri, 18 Mar 2005, Stuart MacDonald wrote: From: Jacques Goldberg To be ugly or to never be up to date, that's the question. We did patch 8250_pci.c but there is no way to build a stable list of the devices to be handled that way. We will thus spend some time on the hot unplug solution. I think what you want might be accomplished if the serial driver was compiled as a module. Then have your driver grab all the PCI devices it wants, and they shouldn't be grabbed by the serial driver when it loads. If you can't get your driver to load before the serial driver for whatever reason, unloading the serial driver should give up the devices it had claimed. ..Stu - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] sealevel 8 port RS-232/RS-422/RS-485 board
On Thu, Mar 10, 2005 at 11:38:58PM -0600, DHollenbeck wrote: Vendor Sealevel suggested these changes for its new board. Tried them, they work with the card. Please apply the patch below, which was made from 2.6.10 but can be applied to 2.6.11.2 without errors. Whitespace fixed and applied, thanks. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bcm203x broadcom dongle firmware upload fails...
Hi Soeren, I don't see why, it used to work reliably at some point but now it does not. It even won't work without hotplug and then manually typing: echo 1 /sys/class/firmware/2-1/loading cat /lib/firmware/BCM2033-FW.bin /sys/class/firmware/2-1/data echo 0 /sys/class/firmware/2-1/loading usb 2-1: new full speed USB device using ohci_hcd and address 2 Bluetooth: Broadcom Blutonium firmware driver ver 1.0 bcm203x_probe: Mini driver request failed bcm203x: probe of 2-1:1.0 failed with error -5 usbcore: registered new driver bcm203x It does not work with kernel 2.6.10/11 any ideas ? I think this is a general request_firmware() problem. Check the Hotplug mailing list archive. Hannes, Kay and Greg discussed problems with the firmware_class and udev. I haven't found the time to look at it. Regards Marcel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Building Areca arcmsr driver outside kernel source tree
To get the arcmsr driver working with CentOS/RHEL 4 and using the
facility to build kernel modules outside of the kernel source tree, I
found the attached patch was necessary to remove the dependencies on the
internal drivers/scsi/scsi*.h header files and to instead use the public
ones found under include/scsi/ which are provided by the kernel-*-devel
packages.
It builds, loads and appears to work with my limited testing on an
ARC1120. I was just wanting to know if this was the right way to fix it?
Once the driver is in the main kernel tree it's largely irrelevant, but
while CentOS/RHEL 4 use the older kernel without the driver it's a PITA
to maintain kernel packages with this one driver added, when a separate
package containing just the driver is much easier.
The patch is based on the 1.20.00.06 driver that was added to
2.6.11-mm4.
Thanks
Matt
--- linux-2.6.9/drivers/scsi/arcmsr/arcmsr.c.orig 2005-03-19 17:50:52.623490488 +
+++ linux-2.6.9/drivers/scsi/arcmsr/arcmsr.c 2005-03-19 18:03:11.484166592 +
@@ -108,7 +108,9 @@
#include linux/init.h
#include linux/spinlock.h
#include scsi/scsi_host.h
-#include ../scsi.h
+#include scsi/scsi.h
+#include scsi/scsi_cmnd.h
+#include scsi/scsi_device.h
#include arcmsr.h
#endif
/*
@@ -138,10 +140,11 @@
struct block_device *bdev, sector_t capacity,
int *info);
static int arcmsr_release(struct Scsi_Host *);
-static int arcmsr_queue_command(Scsi_Cmnd * cmd, void (*done) (Scsi_Cmnd *));
-static int arcmsr_cmd_abort(Scsi_Cmnd *);
-static int arcmsr_bus_reset(Scsi_Cmnd *);
-static int arcmsr_ioctl(Scsi_Device * dev, int ioctl_cmd, void *arg);
+static int arcmsr_queue_command(struct scsi_cmnd * cmd,
+void (*done) (struct scsi_cmnd *));
+static int arcmsr_cmd_abort(struct scsi_cmnd *);
+static int arcmsr_bus_reset(struct scsi_cmnd *);
+static int arcmsr_ioctl(struct scsi_device * dev, int ioctl_cmd, void *arg);
static int __devinit arcmsr_device_probe(struct pci_dev *pPCI_DEV,
const struct pci_device_id *id);
static void arcmsr_device_remove(struct pci_dev *pPCI_DEV);
@@ -152,7 +155,7 @@
static u_int8_t arcmsr_wait_msgint_ready(PACB pACB);
static const char *arcmsr_info(struct Scsi_Host *);
-static Scsi_Host_Template arcmsr_scsi_host_template = {
+static struct scsi_host_template arcmsr_scsi_host_template = {
.module = THIS_MODULE,
.proc_name = arcmsr,
.proc_info = arcmsr_proc_info,
@@ -417,7 +420,7 @@
*/
-static int arcmsr_scsi_host_template_init(Scsi_Host_Template * psht)
+static int arcmsr_scsi_host_template_init(struct scsi_host_template * psht)
{
psht-proc_name = arcmsr;
memset(pHCBARC, 0, sizeof(struct _HCBARC));
@@ -459,19 +462,19 @@
static void arcmsr_pci_unmap_dma(PCCB pCCB)
{
PACB pACB = pCCB-pACB;
- Scsi_Cmnd *pcmd = pCCB-pcmd;
+ struct scsi_cmnd *pcmd = pCCB-pcmd;
if (pcmd-use_sg != 0) {
struct scatterlist *sl;
sl = (struct scatterlist *)pcmd-request_buffer;
pci_unmap_sg(pACB-pPCI_DEV, sl, pcmd-use_sg,
- scsi_to_pci_dma_dir(pcmd-sc_data_direction));
+ pcmd-sc_data_direction);
} else if (pcmd-request_bufflen != 0) {
pci_unmap_single(pACB-pPCI_DEV,
(dma_addr_t) (unsigned long)pcmd-SCp.ptr,
pcmd-request_bufflen,
- scsi_to_pci_dma_dir(pcmd-sc_data_direction));
+ pcmd-sc_data_direction);
}
return;
}
@@ -575,7 +578,7 @@
**
**
*/
-static void arcmsr_cmd_done(Scsi_Cmnd * pcmd)
+static void arcmsr_cmd_done(struct scsi_cmnd * pcmd)
{
pcmd-scsi_done(pcmd);
return;
@@ -608,7 +611,7 @@
{
unsigned long flag;
PACB pACB = pCCB-pACB;
- Scsi_Cmnd *pcmd = pCCB-pcmd;
+ struct scsi_cmnd *pcmd = pCCB-pcmd;
#if ARCMSR_DEBUG0
printk
@@ -635,7 +638,7 @@
*/
static void arcmsr_report_SenseInfoBuffer(PCCB pCCB)
{
- Scsi_Cmnd *pcmd = pCCB-pcmd;
+ struct scsi_cmnd *pcmd = pCCB-pcmd;
PSENSE_DATA psenseBuffer = (PSENSE_DATA) pcmd-sense_buffer;
#if ARCMSR_DEBUG0
printk(arcmsr_report_SenseInfoBuffer...\n);
@@ -804,7 +807,7 @@
** PAGE_SIZE=4096 or 8192,PAGE_SHIFT=12
**
*/
-static void arcmsr_build_ccb(PACB pACB, PCCB pCCB, Scsi_Cmnd * pcmd)
+static void arcmsr_build_ccb(PACB pACB, PCCB pCCB, struct scsi_cmnd * pcmd)
{
PARCMSR_CDB pARCMSR_CDB = (PARCMSR_CDB) pCCB-arcmsr_cdb;
int8_t *psge = (int8_t *) pARCMSR_CDB-u;
@@ -831,7 +834,7 @@
sl = (struct scatterlist *)pcmd-request_buffer;
sgcount =
pci_map_sg(pACB-pPCI_DEV, sl, pcmd-use_sg,
- scsi_to_pci_dma_dir(pcmd-sc_data_direction));
+ pcmd-sc_data_direction);
/* map stor port SG list to our iop SG List. */
for (i = 0; i sgcount; i++) {
/* Get the physical address of the current data pointer */
@@ -902,8 +905,7 @@
dma_addr =
pci_map_single(pACB-pPCI_DEV,
[PATCH] remove redundant NULL check before before kfree() in kernel/sysctl.c
Tiny patch to remove a redundant check for NULL pointer before calling kfree(). Signed-off-by: Jesper Juhl [EMAIL PROTECTED] diff -up linux-2.6.11-mm4-orig/kernel/sysctl.c linux-2.6.11-mm4/kernel/sysctl.c --- linux-2.6.11-mm4-orig/kernel/sysctl.c 2005-03-16 15:45:40.0 +0100 +++ linux-2.6.11-mm4/kernel/sysctl.c2005-03-19 19:52:18.0 +0100 @@ -991,8 +991,7 @@ int do_sysctl(int __user *name, int nlen int error = parse_table(name, nlen, oldval, oldlenp, newval, newlen, head-ctl_table, context); - if (context) - kfree(context); + kfree(context); if (error != -ENOTDIR) return error; tmp = tmp-next; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.6.10 (EIP is at hid_init_reports+0x151/0x1d0 [usbhid])
* Andrew Morton [EMAIL PROTECTED]: Could you please test 2.6.11 or, even better, 2.6.12-rc1? I will do that, once Debian has such a kernel :| -- Ralf Hildebrandt (i.A. des IT-Zentrum) [EMAIL PROTECTED] Charite - Universitätsmedizin BerlinTel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-BerlinFax. +49 (0)30-450 570-962 IT-Zentrum Standort CBF send no mail to [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Relayfs question
Jan Engelhardt wrote: according to the relayfs description on opersys.com, |As the Linux kernel matures, there is an ever increasing number of facilities |and tools that need to relay large amounts of data from kernel space to user |space. Up to this point, each of these has had its own mechanism for relaying |data. To supersede the individual mechanisms, we introduce the high-speed |data relay filesystem (relayfs). As such, things like LTT, printk, EVLog, |etc. This sounds to me like it would obsolete most character-based devices, e.g. random and urandom. What do the relayfs developers say to this? I'm not a relayfs developer, just a happy user... The latest relayfs versions are slimmed down of the original and are unlikely to be useful as a character-based device, but are much better as a data-transport facility. There is no longer any interface for character based reading so it can't be used for the device replace purposes. The current method is to just manage buffers and enable applications to mmap the buffers to read them with some signalling on when a buffer is to be read and when the kernel can overwrite it. A character device is unlikely to need such interface since you do want 16 bytes of random data and not several pages of mapped random numbers. If you really need a lot of random numbers you need something in user-space anyway since you'll deplete the kernel entropy pool pretty fast anyway. If you have a device that needs to transfer lots of data doesn't mind it being batched and doesn't really need the character device interface then relayfs could be useful. Baruch - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.11-rc3: APM resume problems with USB
On Sat, Mar 19, 2005 at 01:44:24AM -0800, Jeremy Fitzhardinge wrote:
On my IBM ThinkPad X31, I can only do one successful APM resume. After
the resume, there's a stream of messages on the console:
uhci_hcd :00:1d.0: host controller process error, something bad
happened!
uhci_hcd :00:1d.0: host system error, PCI problems?
uhci_hcd :00:1d.0: host controller process error, something bad
happened!
uhci_hcd :00:1d.0: host system error, PCI problems?
uhci_hcd :00:1d.0: host controller process error, something bad
happened!
uhci_hcd :00:1d.0: host system error, PCI problems?
uhci_hcd :00:1d.0: host controller process error, something bad
happened!
uhci_hcd :00:1d.0: host system error, PCI problems?
uhci_hcd :00:1d.0: host controller process error, something bad
happened!
uhci_hcd :00:1d.0: host system error, PCI problems?
uhci_hcd :00:1d.0: host controller process error, something bad
happened!
uhci_hcd :00:1d.0: host system error, PCI problems?
The second resume, the machine panics. I haven't managed to get the
panic message yet.
This happens with both -rc3 and -rc4.
I think you mean -mm[34]. I've seen the problem with -mm3, 2.6.11{,.3}
seem to be fine. Also ACPI rather than APM is fine as well though the
suspend life is pathetic.
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Relayfs question
Hi, [...] The current method is to just manage buffers and enable applications to mmap the buffers to read them with some signalling on when a buffer is to be read and when the kernel can overwrite it. A character device is unlikely to need such interface since you do want 16 bytes of random data and not several pages of mapped random numbers. If you really need a lot of random numbers you need something in user-space anyway since you'll deplete the kernel entropy pool pretty fast anyway. If you have a device that needs to transfer lots of data doesn't mind it being batched and doesn't really need the character device interface then relayfs could be useful. Ok, urandom was a bad example. I have my tty logger (ttyrpld.sf.net) which moves a lot of data (depends) to userspace. It uses a ring buffer of fixed size (set at module load time). Apart from that relayfs could use a dynamic sized ring buffer, I would not see any need to move it to relayfs, would you? Jan Engelhardt -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00
i have released the -V0.7.41-00 Real-Time Preemption patch (merged to 2.6.12-rc1), which can be downloaded from the usual place: http://redhat.com/~mingo/realtime-preempt/ the biggest change in this patch is the merge of Paul E. McKenney's preemptable RCU code. The new RCU code is active on PREEMPT_RT. While it is still quite experimental at this stage, it allowed the removal of locking cruft (mainly in the networking code), so it could solve some of the longstanding netfilter/networking deadlocks/crashes reported by a number of people. Be careful nevertheless. there are a couple of minor changes relative to Paul's latest preemptable-RCU code drop: - made the two variants two #ifdef blocks - this is sufficient for now and we'll see what the best way is in the longer run. - moved rcu_check_callbacks() from the timer IRQ to ksoftirqd. (the timer IRQ still runs in hardirq context on PREEMPT_RT.) - changed the irq-flags method to a preempt_disable()-based method, and moved the lock taking outside of the critical sections. (due to locks potentially sleeping on PREEMPT_RT). to create a -V0.7.41-00 tree from scratch, the patching order is: http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2 http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc1.bz2 http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc1-V0.7.41-00 Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Build issue current MIPS - RaQ2
I have not been able to build kernels since 2.6.9 on my RaQ2 for some time. I have tried the linux-mips.org port and the current 2.6.11.5 release. I keep getting the same error. Building modules, stage 2. MODPOST *** Warning: pci_iounmap [drivers/net/tulip/tulip.ko] undefined! *** Warning: pci_iomap [drivers/net/tulip/tulip.ko] undefined! with Make V=1 Building modules, stage 2. make -rR -f /usr/src/linux-2.6.11.5/scripts/Makefile.modpost scripts/mod/modpost -o /usr/src/linux-2.6.11.5/Module.symvers vmlinux drivers/block/loop.o drivers/block/rd.o drivers/cdrom/cdrom.o drivers/char/rtc.o drivers/net/tulip/tulip.o drivers/scsi/scsi_mod.o drivers/scsi/scsi_transport_spi.o drivers/scsi/sd_mod.o drivers/scsi/sr_mod.o drivers/scsi/st.o drivers/scsi/sym53c8xx_2/sym53c8xx.o fs/exportfs/exportfs.o fs/isofs/isofs.o fs/lockd/lockd.o fs/nfs/nfs.o fs/nfsd/nfsd.o fs/nls/nls_ascii.o fs/nls/nls_base.o fs/nls/nls_cp437.o fs/nls/nls_iso8859-1.o fs/nls/nls_utf8.o fs/smbfs/smbfs.o lib/crc32.o lib/zlib_inflate/zlib_inflate.o net/key/af_key.o net/netlink/netlink_dev.o net/packet/af_packet.o net/sunrpc/sunrpc.o net/unix/unix.o *** Warning: pci_iounmap [drivers/net/tulip/tulip.ko] undefined! *** Warning: pci_iomap [drivers/net/tulip/tulip.ko] undefined! Now it seems to me that the Makefile.modpost would need to include arch/mips/lib/iomap.o file to correct this issue, but that doesn't seem like the correct thing to do, and I have no clue on how to do that. -- Jim Gifford [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Suspend-to-disk woes
Hi! Hello, I experienced a pretty nasty problem a couple of days back: I ran 2.6.11-ck1 and built 2.6.11-ck2. The last thing I did before booting the new kernel was to suspend-to-disk the old kernel (something I usually do as I'm working on this laptop). I ran the new kernel a couple of days and decided to boot the old kernel to do some performance tests. Imagine my dread as the old kernel instead of detecting that the system has booted another kernel just reloads the old suspend-to-disk image. The result is that after succesfully resuming, my harddrive goes bonkers and starts to work. After a couple of minutes the whole kernel hangs. I reboot and try to boot the -ck2 kernel again only to find that the system complains as it finds missing nodes. The reisertools try to rebuild the system unsucessully. The --rebuild-tree parameter worked but a lot of files were still missing. In the end I had to reinstall the whole system as it went so unstable. My question is: Why isn't there a check before resuming a suspend-to-disk image if the system has booted another kernel since the suspend to prevent this kind of hassle? Checking that would be hard, but you might want to provide patch to check last-mounted dates of filesystems and panic if they changed. Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 01/10] char/ds1620: use msleep() instead of schedule_timeout()
On Sat, Mar 19, 2005 at 02:17:15PM +0100, [EMAIL PROTECTED] wrote: Not sure why any driver needs to sleep for *two* ticks, so let's fix it. Use msleep() instead of schedule_timeout() to guarantee the task delays as expected. Signals are never checked for by the callers or in the function itself, so use TASK_UNINTERRUPTIBLE instead of TASK_INTERRUPTIBLE. The delay is presumed to have been written when HZ==100, and thus has been multiplied by 10 to pass to msleep(). Signed-off-by: Nishanth Aravamudan [EMAIL PROTECTED] Signed-off-by: Domen Puncer [EMAIL PROTECTED] Acked-by: Russell King [EMAIL PROTECTED] --- kj-domen/drivers/char/ds1620.c |3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) diff -puN drivers/char/ds1620.c~msleep-drivers_char_ds1620 drivers/char/ds1620.c --- kj/drivers/char/ds1620.c~msleep-drivers_char_ds1620 2005-03-18 20:05:09.0 +0100 +++ kj-domen/drivers/char/ds1620.c2005-03-18 20:05:09.0 +0100 @@ -163,8 +163,7 @@ static void ds1620_out(int cmd, int bits netwinder_ds1620_reset(); netwinder_unlock(flags); - set_current_state(TASK_INTERRUPTIBLE); - schedule_timeout(2); + msleep(20); } static unsigned int ds1620_in(int cmd, int bits) _ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
race between __sync_single_inode() and iput()/bdev_clear_inode()
Hi,
EIP is at filemap_fdatawait+0xe/0x80
eax: e7461ad8 ebx: ecx: 0001 edx:
esi: e5334c40 edi: 6b6b6b6b ebp: de239e88 esp: de239e70
ds: 007b es: 007b ss: 0068
Process fsstress (pid: 31048, threadinfo=de239000 task=e60cd020)
Stack: e7d34358 de239e88 c01834f7 e5334c40 e7461ad8 de239eb0 c01836bf
e7461ad8 0001 0001 e7f0eac8 e5334c40 e7f0eac8 e7d2ddf4
de239f0c c0183777 e5334c40 de239f4c e5334c40 e7f0eac8 e7d2ddf4 de239f0c
Call Trace:
[show_stack+127/160] show_stack+0x7f/0xa0
[show_registers+351/464] show_registers+0x15f/0x1d0
[die+244/384] die+0xf4/0x180
[do_page_fault+886/1749] do_page_fault+0x376/0x6d5
[error_code+43/48] error_code+0x2b/0x30
[__sync_single_inode+447/512] __sync_single_inode+0x1bf/0x200
[__writeback_single_inode+119/352] __writeback_single_inode+0x77/0x160
[sync_sb_inodes+452/736] sync_sb_inodes+0x1c4/0x2e0
[sync_inodes_sb+126/144] sync_inodes_sb+0x7e/0x90
[sync_inodes+140/176] sync_inodes+0x8c/0xb0
[do_sync+90/144] do_sync+0x5a/0x90
[sys_sync+18/32] sys_sync+0x12/0x20
[syscall_call+7/11] syscall_call+0x7/0xb
Code: ab 89 1c 24 8b 75 e4 8b 45 ec 89 74 24 08 89 44 24 04 e8 16 fd ff ff eb
93 8d 74 26 00 55 89 e5 57 56 53 83 ec 0c 8b 45 08 8b 38 8b 97 5c 01 00 00 8d
b6 00 00 00 00 8d bf 00 00 00 00 89 d0 f0
Dump of assembler code for function filemap_fdatawait:
0xc013e290 filemap_fdatawait+0: push %ebp
0xc013e291 filemap_fdatawait+1: mov%esp,%ebp
0xc013e293 filemap_fdatawait+3: push %edi
0xc013e294 filemap_fdatawait+4: push %esi
0xc013e295 filemap_fdatawait+5: push %ebx
0xc013e296 filemap_fdatawait+6: sub$0xc,%esp
0xc013e299 filemap_fdatawait+9: mov0x8(%ebp),%eax - %eax is mapping
0xc013e29c filemap_fdatawait+12: mov(%eax),%edi- %edi is
mapping-host
0xc013e29e filemap_fdatawait+14: mov0x15c(%edi),%edx - Oops here
0xc013e2a4 filemap_fdatawait+20: lea0x0(%esi),%esi
I got the above Oops while doing fs stress test.
The cause of this was race condition between __sync_single_inode() and
iput()/bdev_clear_inode().
This race seems following condition.
cpu0 (fs's inode) cpu1 (bdev's inode)
close(/dev/hda2)
[...]
__sync_single_inode()
/* copy the bdev's -i_mapping */
mapping = inode-i_mapping;
generic_forget_inode()
bdev_clear_inode()
/* restre the fs's -i_mapping */
inode-i_mapping = inode-i_data;
/* bdev's inode was freed */
destroy_inode(inode);
if (wait) {
/* dereference a freed bdev's mapping-host */
filemap_fdatawait(mapping); /* Oops */
I wrote the attached patch for making sure fs's inode is not in
__sync_single_inode().
What do you think of this?
Thanks.
--
OGAWA Hirofumi [EMAIL PROTECTED]
Signed-off-by: OGAWA Hirofumi [EMAIL PROTECTED]
---
fs/block_dev.c| 27 ++-
fs/fs-writeback.c | 34 --
2 files changed, 46 insertions(+), 15 deletions(-)
diff -puN fs/block_dev.c~bdev-inode-sync fs/block_dev.c
--- linux-2.6.12-rc1/fs/block_dev.c~bdev-inode-sync 2005-03-20
02:59:24.0 +0900
+++ linux-2.6.12-rc1-hirofumi/fs/block_dev.c2005-03-20 03:59:54.0
+0900
@@ -23,6 +23,7 @@
#include linux/mount.h
#include linux/uio.h
#include linux/namei.h
+#include linux/writeback.h
#include asm/uaccess.h
struct bdev_inode {
@@ -282,11 +283,35 @@ static inline void __bd_forget(struct in
static void bdev_clear_inode(struct inode *inode)
{
+ extern void wait_inode_ilock(struct inode *inode);
struct block_device *bdev = BDEV_I(inode)-bdev;
struct list_head *p;
+ struct inode *i;
+
spin_lock(bdev_lock);
while ( (p = bdev-bd_inodes.next) != bdev-bd_inodes ) {
- __bd_forget(list_entry(p, struct inode, i_devices));
+ inode = list_entry(p, struct inode, i_devices);
+ i = igrab(inode);
+ spin_unlock(bdev_lock);
+ /*
+* Preparation for changeing the -i_mapping. Make
+* sure this inode is not in __sync_single_inode().
+*/
+ if (i) {
+ spin_lock(inode_lock);
+ wait_inode_ilock(i);
+ inode-i_state |= I_LOCK;
+ spin_unlock(inode_lock);
+ }
+ spin_lock(bdev_lock);
+ spin_lock(inode_lock);
+ if (i) {
+ inode-i_state = ~I_LOCK;
+ wake_up_inode(i);
+
Re: [PATCH 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation
On Fri, Mar 18, 2005 at 03:23:44PM -0600, Matt Domsch wrote: For review and comment. On x86_64 systems with no IOMMU and with 4GB RAM (in fact, whenever there are any pages mapped above 4GB), pci_alloc_consistent() falls back to using ZONE_DMA for all allocations, even if the device's dma_mask could have supported using memory from other zones. Problems can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume all of ZONE_DMA, leaving none left for pci_alloc_consistent() use. Patch below makes pci_alloc_consistent() for the nommu case (EM64T processors) match the 2.6 implementation of dma_alloc_coherent(), with the exception that this continues to use GFP_ATOMIC. You fixed the wrong code. The pci-nommu code is only used when IOMMU is disabled in the Kconfig. But most kernels have it enabled. You would need to change it in pci-gart.c too. The reason it is like this that nommu was always intended as a hackish kludge that would be only used for debugging - little did we know that it would become standard later. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.12-rc1 report
Greetings; Usually I come looking for a bone when I post here, but today its with verbal flowers in hand. I just built 2.6.12-rc1 and I'm pleased to report that the ieee1394 problems that required the bk-ieee1394.patch previously are apparently alleviated. Kino worked as expected, including the audio from the cameras microphones. tvtime, with my pcHDTV-3000 card, had a miss-cue due to the wrong modprobe statement in my rc.local, so I cleaned out those modules that it had loaded, and reloaded them with the 'modprobe cx88_dvb' statement, which brought that up with working video but raw noise for audio at about +40db! Going into its menu's for tv standards I chose to 'restart with new values' without changing anything which restored the audio to normal. Thats happened before, and Jack tells me there will be another coding session this weekend so there will no doubt be more patches for that. This FWIW, was without actually installing either version of his drivers, so this is nice progress. My scanner works normally. As does the spca5xx stuffs that I did install again after the boot. This just plain feels good under my fngertips, even kmails curser motions are as expected, but that lag comes and goes according to the number of bees around the crocus's in the front yard, or some such mysticly quasi random control. I don't have any idea about how much faster the machine is in fact, but it sure feels snappier, a lot snappier. So, a smart tip of the hat to all the patchers, this is seeable, feelable, progress. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 patch] net/bluetooth/rfcomm/core.: make a variable static
Hi Adrian, This patch makes a needlessly global variable static. the patch is in my tree now. Thanks. Regards Marcel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Suspend-to-disk woes
On Saturday 19 March 2005 05:26, Pavel Machek wrote: Checking that would be hard, but you might want to provide patch to check last-mounted dates of filesystems and panic if they changed. Pavel Then how would you fix it? There'd also have to be a way to reset it, otherwise the kernel will never boot again. Perhaps an argument to the kernel that allows for resetting of the mechanism? --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] _raw_read_trylock for alpha
alpha SMP doesn't build, due to lack of _raw_read_trylock().
Patch below completely untested... needs review and testing.
One could also use the arch-neutral generic_raw_read_trylock(),
but that implementation is rather lame (it spins). I'm amazed at the
number of arches that use the generic implementation, since the generic
version isn't really a trylock.
Don't send this patch upstream until its been verified to actually work.
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
diff -ur ../kernel-2.6.11.orig/linux-2.6.11/include/asm-alpha/spinlock.h
linux-2.6.11/include/asm-alpha/spinlock.h
--- ../kernel-2.6.11.orig/linux-2.6.11/include/asm-alpha/spinlock.h
2005-03-02 02:38:12.0 -0500
+++ linux-2.6.11/include/asm-alpha/spinlock.h 2005-03-19 03:26:11.0
-0500
@@ -153,6 +153,29 @@
}
#endif /* CONFIG_DEBUG_RWLOCK */
+static inline int _raw_read_trylock(rwlock_t * lock)
+{
+ long regx;
+ int success;
+
+ __asm__ __volatile__(
+ 1: ldl_l %1,%0\n
+ lda %2,0\n
+ blbs%1,6f\n
+ subl%1,2,%1\n
+ stl_c %1,%0\n
+ beq %1,6f\n
+ lda %2,1\n
+ 4: mb\n
+ .subsection 2\n
+ 6: br 1b\n
+ .previous
+ : =m (*lock), =r (regx), =r (success)
+ : m (*lock) : memory);
+
+ return success;
+}
+
static inline int _raw_write_trylock(rwlock_t * lock)
{
long regx;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Relayfs question
Jan Engelhardt wrote: Ok, urandom was a bad example. I have my tty logger (ttyrpld.sf.net) which moves a lot of data (depends) to userspace. It uses a ring buffer of fixed size (set at module load time). Apart from that relayfs could use a dynamic sized ring buffer, I would not see any need to move it to relayfs, would you? First, please note that the info on Opersys' site is out-of-date. While it was relevant while we were still maintaining relayfs separately, it has somewhat lost its relevance since we started posting the most up-to- date code directly to LKML. For one thing, the dynamic resizing was dropped very early in relayfs' inclusion review. What relayfs does, and does very well, is move very large amounts of data out of the kernel and make them available to user-space with very little overhead. In the actual case of your tty logger, I've browsed through the code briefly, and I think that with relayfs you should be able to: - Get rid of half the code: - No need to manage your own user/kernel-buffer boundary (Most of the code in uio_*()). - No need to do any buffer management at all. - Get better performance out of your logging functions. - Get per-cpu buffers for free. Basically, all the transport code you are doing in the kernel side of your logger would be taken care of by relayfs. And given that there are a lot of people doing similar ad-hoc buffering code, it just makes sense to have one well-tested yet generic mechanism. Have a look at Documentation/filesystems/relayfs.txt for the API details. On a separate yet related topic: Looking closer at rpldev.c, I believe that you'll be able to get rid of it entirely (or very close to) once I actually get the time to refactor the tracing code in LTT to make it generic. What I intend to do is to obsolete the need for functions like your kio_*, and make it all automatically generated at build time (you'll still to add the instrumentation, but won't need to hand-code the callbacks). This is still on the top of my to-do list and I should be able to get to this shortly. Karim -- Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NULL pointer bug in netpoll.c
Hi,
it seems that there is a gremlin sleeping in
net/core/netpoll.c:find_skb(). Even if no more buffers are available
through skbs, skb is dereferenced anyway. The tiny patch should fix it.
Jan
--- linux-2.6.11.4/net/core/netpoll.c.orig 2005-03-16 01:09:19.0
+0100
+++ linux-2.6.11.4/net/core/netpoll.c 2005-03-19 21:42:41.573018776 +0100
@@ -165,10 +165,11 @@ repeat:
if (!skb) {
spin_lock_irqsave(skb_list_lock, flags);
skb = skbs;
- if (skb)
+ if (skb) {
skbs = skb-next;
- skb-next = NULL;
- nr_skbs--;
+ skb-next = NULL;
+ nr_skbs--;
+ }
spin_unlock_irqrestore(skb_list_lock, flags);
}
RE: [patch] arch hook for notifying changes in PTE protections bits
David S. Miller mailto:[EMAIL PROTECTED] wrote on Friday, March 18, 2005 8:06 PM: Take a look at set_pte_at(). You get the mm, the virtual address, the pte pointer, and the new pte value. Thanks for pointing out the updated interface in 2.6.12-* kernel. I think I can overload the arch specific part of set_pte_at(or for that matter set_pte, as what I need is only pte_t) to always check if we need to do lazy I/D coherency for IA-64.but this incurs extra cost for making a check every time set_pte_at is called. This new hook, lazy_mmu_prot_update, though needs to be used only when the permissions on a valid PTE is changing. For example, at the time of remap or swap, this API is not called. What else could you possibly need to track stuff like this and react appropriately? :-) Stuff is there, though the call needs to be made to ensure we are reacting to it most optimally and correctly.I guess something similar to why update_mmu_cache API is still existing in generic part and not overloading arch specific set_pte_at definition. -rohit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] arch hook for notifying changes in PTE protections bits
On Sat, 19 Mar 2005 12:22:20 -0800, Seth, Rohit [EMAIL PROTECTED] said: Rohit David S. Miller mailto:[EMAIL PROTECTED] wrote on Friday, Rohit March 18, 2005 8:06 PM: Take a look at set_pte_at(). You get the mm, the virtual address, the pte pointer, and the new pte value. Rohit Thanks for pointing out the updated interface in 2.6.12-* Rohit kernel. I think I can overload the arch specific part of Rohit set_pte_at(or for that matter set_pte, as what I need is only Rohit pte_t) to always check if we need to do lazy I/D coherency Rohit for IA-64.but this incurs extra cost for making a check Rohit every time set_pte_at is called. This new hook, Rohit lazy_mmu_prot_update, though needs to be used only when the Rohit permissions on a valid PTE is changing. For example, at the Rohit time of remap or swap, this API is not called. Careful though: not every PTE has an associated page_map entry. I agree about your concern about cost. Accessing the page_map is expensive (integer division + memory access) and we have to do that in order to find out if the page is i-cache clean. --david - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Relayfs question
Karim Yaghmour wrote: What relayfs does, and does very well, is move very large amounts of data out of the kernel and make them available to user-space with very little overhead. In the actual case of your tty logger, I've browsed through the code briefly, and I think that with relayfs you should be able to: Just to avoid any confusion, note that I'm referring mainly to rpldev.c, which is the kernel-side driver for the logger, I haven't looked at any of the user tools. Karim -- Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pwc driver in -mm kernels
On Sat, Mar 19, 2005 at 02:04:24PM +0100, Norbert Preining wrote: Hi Andrew, hi Luc! I just realized that there is now the pwc driver back in -mm kernels, but interestingly not the one from Luc, or at least not the last published one (10.0.6). and wanted to ask if there is a specific reason for this? Because that is the version that was submitted for inclusion. Patches are gladly accepted to bring the driver up to date. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Nasty ReiserFS bug in 2.6.12-rc1, 2.6.12-rc1-bk1
Hi. I have built 2.6.12-rc1 and 2.6.12-rc1-bk1. There seems to be a nasty bug in ReiserFS (things are fine in 2.6.11.4). The system wants to un-configure my SCSI Adaptec devices, and stall at starting Hal daemon. I also get the following error message (applied variously at different times to different drives): Mar 19 12:17:35 localhost kernel: ReiserFS: sdb1: using ordered data mode Mar 19 12:17:35 localhost kernel: ReiserFS: sdb1: journal params: device sdb1, s ize 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Mar 19 12:17:35 localhost kernel: ReiserFS: sdb1: checking transaction log (sdb1 ) Mar 19 12:17:36 localhost kernel: ReiserFS: sdb1: Using r5 hash to sort names Mar 19 12:20:25 localhost su(pam_unix)[6809]: session opened for user root by bo b(uid=500) Mar 19 12:25:13 localhost kernel: Unable to handle kernel NULL pointer dereferen ce at virtual address 000e Mar 19 12:25:13 localhost kernel: printing eip: Mar 19 12:25:13 localhost kernel: c021c4af Mar 19 12:25:13 localhost kernel: *pde = Mar 19 12:25:13 localhost kernel: Oops: [#1] Mar 19 12:25:13 localhost kernel: PREEMPT Mar 19 12:25:13 localhost kernel: Modules linked in: nvidia agpgart imm snd_emu1 0k1_synth snd_emux_synth snd_seq_oss raw1394 snd_seq_virmidi snd_seq_midi_emul snd_seq_midi snd_seq_midi_event snd_seq_dummy snd_seq ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables binfmt_misc s d_mod video thermal processor fan button battery ac usblp ohci1394 ohci_hcd usbc ore tuner bttv video_buf i2c_algo_bit v4l2_common btcx_risc tveeprom videodev i2c_sis96x i 2c_core snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm_oss snd_mi xer_oss snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore si s900 sbp2 scsi_mod ieee1394 Mar 19 12:25:13 localhost kernel: CPU:0 Mar 19 12:25:13 localhost kernel: EIP:0060:[c021c4af]Tainted: P V LI Mar 19 12:25:13 localhost kernel: EFLAGS: 00010086 (2.6.12-rc1) Mar 19 12:25:13 localhost kernel: EIP is at as_find_arq_hash+0x38/0x7d Mar 19 12:25:13 localhost kernel: eax: f751d000 ebx: ecx: 0006 edx: f7b60a64 Mar 19 12:25:13 localhost kernel: esi: f7489e00 edi: f7b60d80 ebp: 0de8e63f esp: d0373bd4 Mar 19 12:25:13 localhost kernel: ds: 007b es: 007b ss: 0068 Mar 19 12:25:13 localhost kernel: Process cc1 (pid: 6878, threadinfo=d0372000 ta sk=e08c8a00) Mar 19 12:25:13 localhost kernel: Stack: c1bf00ac d0473894 0de8e647 f7d26b4c d02 43a80 c021de95 f7b60d80 Mar 19 12:25:13 localhost kernel:0de8e63f 0020 c1bfc5d0 f7b60d80 000 0 f7d26b4c c1bf00ac Mar 19 12:25:13 localhost kernel:c02188f5 c1bf00ac d0373c34 d0243a80 000 0 0de8e63f 0008 0008 Mar 19 12:25:13 localhost kernel: Call Trace: Mar 19 12:25:13 localhost kernel: [c021de95] as_merge+0x64/0x1ad Mar 19 12:25:13 localhost kernel: [c02188f5] __make_request +0xac/0x4ed Mar 19 12:25:13 localhost kernel: [c0219044] generic_make_request +0x90/0x1ff Mar 19 12:25:13 localhost kernel: [c015762a] bio_alloc_bioset +0x10f/0x1bf Mar 19 12:25:13 localhost kernel: [c012b3b7] autoremove_wake_function +0x0/0x4 b Mar 19 12:25:13 localhost kernel: [c012b3b7] autoremove_wake_function +0x0/0x4 b Mar 19 12:25:13 localhost kernel: [c017536d] do_mpage_readpage +0x28e/0x3c7 Mar 19 12:25:13 localhost kernel: [c0219200] submit_bio+0x4d/0xdc Mar 19 12:25:13 localhost kernel: [c01be8a9] radix_tree_insert +0x83/0x12a Mar 19 12:25:13 localhost kernel: [c013e309] __pagevec_lru_add +0xde/0x107 Mar 19 12:25:13 localhost kernel: [c0174fc4] mpage_bio_submit +0x2b/0x32 Mar 19 12:25:13 localhost kernel: [c0175579] mpage_readpages +0xd3/0x173 Mar 19 12:25:13 localhost kernel: [c018fd2d] reiserfs_get_block +0x0/0x1530 Mar 19 12:25:13 localhost kernel: [c013b747] read_pages+0x13f/0x14f Mar 19 12:25:13 localhost kernel: [c018fd2d] reiserfs_get_block +0x0/0x1530 Mar 19 12:25:13 localhost kernel: [c01394e2] __alloc_pages +0x173/0x3e1 Mar 19 12:25:13 localhost kernel: [c013b8a3] __do_page_cache_readahead+0x14c/ 0x183 Mar 19 12:25:13 localhost kernel: [c0135b71] filemap_nopage +0x29a/0x3d9 Mar 19 12:25:13 localhost kernel: [c01358d7] filemap_nopage+0x0/0x3d9 Mar 19 12:25:13 localhost kernel: [c0143fd6] do_no_page+0xaf/0x3a5 Mar 19 12:25:13 localhost kernel: [c0142101] pte_alloc_map+0x99/0xbe Mar 19 12:25:13 localhost kernel: [c0144530] handle_mm_fault +0x16e/0x1b0 Mar 19 12:25:13 localhost kernel: [c0112bb9] do_page_fault +0x1c5/0x5c7 Mar 19 12:25:13 localhost kernel: [c0146224] do_mmap_pgoff +0x4a7/0x78e Mar 19 12:25:13 localhost kernel: [c0108813] sys_mmap2+0x7a/0xa9 Mar 19 12:25:13 localhost kernel: [c01129f4] do_page_fault+0x0/0x5c7 Mar 19 12:25:13 localhost kernel: [c0103907] error_code+0x2b/0x30 Mar 19 12:25:13 localhost kernel: Code: 24 1c 89 e8 8b 57 30 c1 e8 03 69 c0 01 0 0 37 9e c1 e8 1a 8d 34 c2 8b 1e 39 f3 74 2c 8d 53 e4 8b 1b 8b 42 24 8b 4a 14 85 c0 74 3b 8b 41 08 a8
Re: Relayfs question
Ok, urandom was a bad example. I have my tty logger (ttyrpld.sf.net) which moves a lot of data (depends) to userspace. It uses a ring buffer [...] [...] Basically, all the transport code you are doing in the kernel side of your logger would be taken care of by relayfs. And given that there are a lot of people doing similar ad-hoc buffering code, it just makes sense to have one well-tested yet generic mechanism. Have a look at Documentation/filesystems/relayfs.txt for the API details. Well, what about things like urandom? It also moves a lot of data and does nothing else. [...] Just to avoid any confusion, note that I'm referring mainly to rpldev.c, which is the kernel-side driver for the logger, I haven't looked at any of the user tools. The userspace daemon just read()s the device and analyzes it. Nothing to optimize there, with respect to relayfs, I think. Jan Engelhardt -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: yenta_socket nobody cared - Disabling IRQ #4 - WORKING!!
On Saturday 19 March 2005 09:05, Jonas Oreland wrote: Hi again and thx again, SUMMARY: It's working with new hook (wo/ trying second part) I'll post again if error comes up again. that's good news! Daniel Ritz wrote: On Saturday 19 March 2005 00:00, Jonas Oreland wrote: it's the second time now i see this problem with an atheros chipset in combination with a TI bridge. last time it was the 1225... attached a patch that could help... Report: 1) It works somewhat better. irq doesn't get disabled. 2) however wlan card get disfunctional. I haven't been able to contact my wap even if i'm standing on it... i was afraid that it could have some side effects. it's probably because just writing a 0 to the MFUNC register is stupid...can you try to replace ti12xx_hook() in ti113x.h with this one? yes, now it works!!! (limited testing) I tried rebooting plugging/unplugging/swsuspending maybe 6 times. All of them working, that a new record :-) Should I try second step anyway? not neccessarily.. 3) unplug has resulted in kernel panic (twice) (btw: how do I do to capture and report those) at a first guess i would blame the atheros driver which taints the kernel. so try _not_ loading the atheros driver and see if it still happens. if so the messages please. to capture them you can use a serial console (null modem cable to second pc). check out the remote serial console howto on www.tldp.org might be...the driver...haven't tried wo/ it. note: I never got this after new hook, 4) when unlug don't produce kernel panic, then there is no way of power-oning that card again. 5) booting with the card inserted makes it not power on when yenta_socket is loaded (module) anything in dmesg then? zero comment: the card being disfunction could have something to with the driver. but before it worked sometimes... -- for TI bridges: turn off interrupts during card power-on. this seems to be neccessary for some combination of TI bridges with at least CB cards with atheros chipset...problem is that they produce an interrupt storm during power-on so the kernel happens to disable the IRQ which is a bad thing (tm). adds a generic hook function so that a socket driver can hook into almost anywhere (by adding more hook points of course). this is the cleanest way i can think of. and it allows adding more workarounds for more problems... for the TI specific interrupt on-off stuff just save the MFUNC register and set it to 0 to disable all interrupts, restore it afterwards. Signed-off-by: Daniel Ritz [EMAIL PROTECTED] Some thoughts: (not I'm neither pcmcia nor linux expert). The irq storm, shouldn't that be acked in someway. I.e. the card produced a lot of irq's (that get ignored) isn't the real solution to capture them, and do something clever? Instead of just shutting the card down. hmmm...wonder if that made sence it's the CB device that is making the interrupt storm and the TI bridge is stupid enough to let the interrupts thru during power on. thing is you can't ack them at this time because the cardbus resources are not set up at this time and ack'ing an IRQ is device specifc. ok Question: Why do you think that it worked sometimes before? pure luck? How about 2.4? can you compare cs code with 2.6? It always worked in 2.4... the problem is there also, it just doesn't show up. 2.6 checks for every interrupt if one of the handlers took care of it. if not the dump is printed and a counter is increased. if this counter reaches a limit the interrupt line is disabled. 2.4 doesn't do it so the interrupt storm is there too, it just recovers...you can try with 2.4...after you have the card up do a cat /proc/interrupts and you'll see a high number for yenta's interrupt line... /Jonas can you also give me a dump of /proc/iomem? [snip /proc/iomem] it was just to be sure nothing is mapped over existing physical RAM which is not the case... i'll cook up a more flexible patch which handles other TI bridges as well (the current one will fail on some older controllers and on 2-slot controllers) rgds -daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] clean up FIXME in do_timer_interrupt-lock fix
George Anzinger george@mvista.com wrote:
Did you pick this up? First sent on 3-11.
I did, although now looking at it I have issues.
I was not happy with the locking on this. Two changes:
1) Turn off irq while setting the clock.
2) Call the timer code only through the timer interface
(set a short timer to do it from the ntp call).
I would consider this to be an inadequate description :(
Signed-off-by: George Anzinger george@mvista.com
time.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.12-rc/arch/i386/kernel/time.c
===
--- linux-2.6.12-rc.orig/arch/i386/kernel/time.c
+++ linux-2.6.12-rc/arch/i386/kernel/time.c
@@ -176,12 +176,12 @@ static int set_rtc_mmss(unsigned long no
int retval;
/* gets recalled with irq locally disabled */
-spin_lock(rtc_lock);
+spin_lock_irq(rtc_lock);
if (efi_enabled)
retval = efi_set_rtc_mmss(nowtime);
else
retval = mach_set_rtc_mmss(nowtime);
-spin_unlock(rtc_lock);
+spin_unlock_irq(rtc_lock);
return retval;
}
If the comment is correct, and this code is called with local irq's
disabled then this patch should be using spin_lock_irqsave()
@@ -338,7 +338,7 @@ static void sync_cmos_clock(unsigned lon
}
void notify_arch_cmos_timer(void)
{
-sync_cmos_clock(0);
+mod_timer(sync_cmos_timer, jiffies + 1);
}
static long clock_cmos_diff, sleep_start;
Your description says what this does, but it doesn't way why it was done?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: swsusp: Remove arch-specific references from generic code
Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Wednesday, 16 of March 2005 01:12, Pavel Machek wrote: Hi! This is fix for swsusp_restore crap-: we had some i386-specific code referenced from generic code. This fixes it by inlining tlb_flush_all into assembly. Please apply, Unfortunately, this patch requires the following fix. Without it, swsusp will leak lots of memory on every resume. Sorry for this bug, it was really dumb. Just fyi, the only swsusp patches I currently have queued are swsusp-add-missing-refrigerator-calls.patch swsusp-suspend_pd_pages-fix.patch suspend-to-ram-update-videotxt-with-more-systems.patch I've been ducking all the swsusp_restore crap patches. Pavel, could you please aggregate, test and resend everything when the dust has settled? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Suspend-to-disk woes
On So 19-03-05 12:20:35, Russell Miller wrote: On Saturday 19 March 2005 05:26, Pavel Machek wrote: Checking that would be hard, but you might want to provide patch to check last-mounted dates of filesystems and panic if they changed. Pavel Then how would you fix it? There'd also have to be a way to reset it, boot with noresume, then mkswap. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swsusp: Remove arch-specific references from generic code
Hi! swsusp-suspend_pd_pages-fix.patch Could you drop this one? It is fixing unused macro, we don't want it going anywhere. suspend-to-ram-update-videotxt-with-more-systems.patch I've been ducking all the swsusp_restore crap patches. Pavel, could you please aggregate, test and resend everything when the dust has settled? Ok. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Suspend-to-disk woes
On Saturday 19 March 2005 13:29, Pavel Machek wrote: On So 19-03-05 12:20:35, Russell Miller wrote: On Saturday 19 March 2005 05:26, Pavel Machek wrote: Checking that would be hard, but you might want to provide patch to check last-mounted dates of filesystems and panic if they changed. Pavel Then how would you fix it? There'd also have to be a way to reset it, boot with noresume, then mkswap. Pavel Ah, makes sense. I've never used the resume functionality, so my ignorance on that subject is understandable... :-) --Russell -- Russell Miller - [EMAIL PROTECTED] - Agoura, CA - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Latency tests with 2.6.12-rc1
On Sat, 2005-03-19 at 02:51 -0500, Lee Revell wrote:
On Sat, 2005-03-19 at 08:08 +0100, Ingo Molnar wrote:
great! The change in question is most likely the copy_page_range() fix
that Hugh resurrected:
ChangeSet 1.2037, 2005/03/08 09:26:46-08:00, [EMAIL PROTECTED]
[PATCH] copy_pte_range latency fix
Ingo's patch to reduce scheduling latencies, by checking for lockbreak
in
copy_page_range, was in the -VP and -mm patchsets some months ago; but
got
preempted by the 4level rework, and not reinstated since. Restore it now
in copy_pte_range - which mercifully makes it easier.
are the ext3 related latencies are gone as well - or are you working it
around by not using data=ordered?
As a matter of fact the ext3 latencies do not appear to be causing
problems, at least not at those settings, even with data=ordered.
It's impossible to tell much more because the mainline kernel lacks the
instrumentation that the realtime patchset provides.
Ingo,
I think I have nailed this down to a bug in the latency tracer.
I ran 2.6.12-rc1 all night with JACK at 64 frames. Anything longer than
1.3 ms will cause xruns at this setting. I did not get a single xrun
all night, despite running dbench 64.
(The workload for all of the following tests was dbench 16)
Then I tried 2.6.12-rc1-RT-V0.7.41-00 with PREEMPT_DESKTOP which should
be similar to mainline, with the addition of IRQ threading and the
latency instrumentation. As soon as I ran updatedb, the latency
tracer reported 3 and 4ms bumps in that same ext3 code path. But, JACK
was not running at the time.
Next I tried the same test but with JACK running. The longest latency
reported was only 200 usecs, and I did not get xruns.
Then, right after I stopped JACK, the latency tracer shot up to 1645
usecs.
So there seems to be a bug in the latency tracer where the timer is not
being reset on reschedule. If an RT task like JACK is running, the
task does wakeup properly and the counter is reset. But if JACK is not
running then long latencies will be reported.
Lee
preemption latency trace v1.1.4 on 2.6.12-rc1-RT-V0.7.41-00
latency: 3402 s, #4095/20285, CPU#0 | (M:preempt VP:0, KP:1, SP:1 HP:1 #P:1)
-
| task: ksoftirqd/0-2 (uid:0 nice:-10 policy:0 rt_prio:0)
-
_--= CPU#
/ _-= irqs-off
| / _= need-resched
|| / _---= hardirq/softirq
||| / _--= preempt-depth
/
| delay
cmd pid | time | caller
\ /| \ | /
(T1/#0)... 2576 0 3 0004 [0002512920677720] 0.000ms
(+3971052.610ms): 756f6a6b (6c616e72)
(T1/#2)... 2576 0 3 0004 0002 [0002512920677953] 0.000ms
(+0.000ms): __trace_start_sched_wakeup+0x9a/0xd0 c013150a
(try_to_wake_up+0x94/0x140 c0110474)
(T1/#3)... 2576 0 3 0003 0003 [0002512920678126] 0.000ms
(+0.000ms): preempt_schedule+0x11/0x80 c02b57c1 (try_to_wake_up+0x94/0x140
c0110474)
(T3/#4)...-2576 0dn.30s : try_to_wake_up+0x11e/0x140 c01104fe
...-2 (69 73):
(T1/#5)... 2576 0 3 0002 0005 [0002512920678609] 0.000ms
(+0.000ms): preempt_schedule+0x11/0x80 c02b57c1 (try_to_wake_up+0xf8/0x140
c01104d8)
(T1/#6)... 2576 0 3 0002 0006 [0002512920678807] 0.000ms
(+0.000ms): wake_up_process+0x35/0x40 c0110555 (do_softirq+0x3f/0x50
c011b05f)
(T6/#7)...-2576 0dn.11s (1)
(T1/#8)... 2576 0 2 0001 0008 [0002512920679575] 0.001ms
(+0.000ms): __journal_unfile_buffer+0xe/0x1c0 c01a9d2e
(journal_commit_transaction+0xda2/0x1170 c01aba72)
(T1/#9)... 2576 0 2 0001 0009 [0002512920680035] 0.001ms
(+0.000ms): journal_remove_journal_head+0xc/0x60 c01b074c
(journal_commit_transaction+0xdb7/0x1170 c01aba87)
(T1/#10)... 2576 0 2 0001 000a [0002512920680231]
0.001ms (+0.000ms): __journal_remove_journal_head+0x11/0x180 c01b05d1
(journal_remove_journal_head+0x3c/0x60 c01b077c)
(T1/#11)... 2576 0 2 0001 000b [0002512920680454]
0.002ms (+0.000ms): __brelse+0xb/0x70 c015c10b
(__journal_remove_journal_head+0xb5/0x180 c01b0675)
(T1/#12)... 2576 0 2 0001 000c [0002512920680599]
0.002ms (+0.000ms): journal_free_journal_head+0xb/0x30 c01b040b
(journal_remove_journal_head+0x3c/0x60 c01b077c)
(T1/#13)... 2576 0 2 0001 000d [0002512920680736]
0.002ms (+0.000ms): kmem_cache_free+0x14/0x60 c01432c4
(journal_free_journal_head+0x1f/0x30 c01b041f)
(T1/#14)... 2576 0 2 0001 000e [0002512920681179]
0.002ms (+0.000ms): inverted_lock+0xb/0x50 c01aab4b
(journal_commit_transaction+0x333/0x1170 c01ab003)
(T1/#15)
Re: [PATCH] partitions/msdos.c
Andries Brouwer wrote: In other words, we need the user space command `partition', where partition -t dos /dev/sda reads a DOS-type partition table. So if you e.g. hotplug a new device, its partitions won't be accessible before you (or some hotplug manager, etc.) run partition ? The two variants are: (i) partition tells the kernel to do the partition table reading, and (ii) partition uses partx to read the partition table and tells the kernel one-by-one about the partitions found this way. I guess, once you've reached the point where the kernel is unable to find partitions without user-space help, you may as well do everything in user space. Since this is a fundamental change, Pretty much, yes. Except for a few embedded systems (*), this would mark the end of kernels that can do anything useful without initrd or initramfs. (*) Oh, regarding the other exception, ceterum censeo nfsroot esse delendam. a long transition period is needed, and that period could start with a kernel boot parameter telling the kernel not to do partition table parsing on a particular disk, or a particular type of disks, or all disks. ... and allow partition to override partitions previously auto-detected by the kernel. That way, you can phase in partition without needing to change your kernel setup. Besides, the ability to correct past mistakes would also be useful if auto-detection from user space yields garbage. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swsusp: Remove arch-specific references from generic code
Hi! Do you think you could just send me diff between 2.6.12-rc1 and your tree? I'll merge it here. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Scheduling changes in -mm tree
Martin J. Bligh [EMAIL PROTECTED] wrote: I don't think these are doing much for performance. Or at least *something* in your tree isn't ... Kernbench: ElapsedSystem User CPU elm3b67 2.6.11 50.24146.60 1117.61 2516.67 elm3b67 2.6.11-mm1 52.27141.14 1099.91 2374.33 elm3b67 2.6.11-mm2 51.88142.41 1104.85 2403.67 elm3b67 2.6.11-mm4 51.23145.04 1100.70 2431.00 (elm3b67 is a 16x x440 ia32 NUMA system + HT) Sounds like the CPU scheduler, yes Is there an easy way to just test those sched changes alone? Nick has tossed out and redone all the scheduler patches from -mm4, but I assume it's all pretty much the same. At http://www.zip.com.au/~akpm/linux/patches/stuff/mbligh.gz is a rollup (against 2.6.12-rc1) of sched2-fix-schedstats-warning.patch sched2-cleanup-wake_idle.patch sched2-improve-load-balancing-pinned-tasks.patch sched2-reduce-active-load-balancing.patch sched2-fix-smt-scheduling-problems.patch sched2-add-debugging.patch sched2-less-aggressive-idle-balancing.patch sched2-balance-timers.patch sched2-tweak-affine-wakeups.patch sched2-no-aggressive-idle-balancing.patch sched2-balance-on-fork.patch sched2-schedstats-update-for-balance-on-fork.patch sched2-sched-tuning.patch sched2-sched-domain-sysctl.patch add-do_proc_doulonglongvec_minmax-to-sysctl-functions.patch - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] Trivial patch to update a comment in drivers/video/s1d13xxxfb.c
Trivial patch to update a comment in drivers/video/s1d13xxxfb.c
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
--- linux-2.6.11-mm4-orig/drivers/video/s1d13xxxfb.c2005-03-16
15:45:26.0 +0100
+++ linux-2.6.11-mm4/drivers/video/s1d13xxxfb.c 2005-03-19 22:45:10.0
+0100
@@ -720,7 +720,7 @@ static int s1d13xxxfb_resume(struct devi
if (s1dfb-disp_save) {
memcpy_toio(info-screen_base, s1dfb-disp_save,
info-fix.smem_len);
- kfree(s1dfb-disp_save);/* XXX kmalloc()'d when? */
+ kfree(s1dfb-disp_save);/* kmalloc()'d in
s1d13xxxfb_suspend */
}
if ((s1dfb-display 0x01) != 0)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bitrotting serial drivers
Russell King [EMAIL PROTECTED] wrote: Hi, m32r_sio Maintainer: Hirokazu Takata Please clean up the m32r_sio driver, removing whatever bits of code aren't absolutely necessary. Specifically, I'd like to see the following addressed: - the usage of SERIAL_IO_HUB6 (this driver doesn't support hub6 cards) - SERIAL_IO_* should be UPIO_* - __register_m32r_sio, register_m32r_sio, unregister_m32r_sio, m32r_sio_get_irq_map (this driver doesn't support PCMCIA cards, all of which are based on 8250-compatible devices.) - early_serial_setup (should we really have the function name duplicated across different hardware drivers?) au1x00_uart --- Maintainer: unknown (akpm - any ideas?) Ralf. This is a complete clone of 8250.c, which includes all the 8250-specific structure names. Specifically, I'd like to see the following addressed: - Please clean this up to use au1x00-specific names. - this driver is lagging behind with fixes that the other drivers are getting. Is au1x00_uart actually maintained? - the usage of UPIO_HUB6 (this driver doesn't support hub6 cards) - __register_serial, register_serial, unregister_serial (this driver doesn't support PCMCIA cards, all of which are based on 8250-compatible devices.) - early_serial_setup (should we really have the function name duplicated across different hardware drivers?) The main reason is I wish to kill off uart_register_port and uart_unregister_port, but these drivers are using it. Thanks. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clean up FIXME in do_timer_interrupt-lock fix
Andrew Morton wrote:
George Anzinger george@mvista.com wrote:
Did you pick this up? First sent on 3-11.
I did, although now looking at it I have issues.
I was not happy with the locking on this. Two changes:
1) Turn off irq while setting the clock.
2) Call the timer code only through the timer interface
(set a short timer to do it from the ntp call).
I wanted the calls to sync_cmos_clock() to be made in a consistent environment.
This was not true when calling it directly from the NTP call code. The change
means that sync_cmos_clock() is ALWAYS called from run_timers(), i.e. as a timer
call back function.
I would consider this to be an inadequate description :(
Signed-off-by: George Anzinger george@mvista.com
time.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.12-rc/arch/i386/kernel/time.c
===
--- linux-2.6.12-rc.orig/arch/i386/kernel/time.c
+++ linux-2.6.12-rc/arch/i386/kernel/time.c
@@ -176,12 +176,12 @@ static int set_rtc_mmss(unsigned long no
int retval;
/* gets recalled with irq locally disabled */
- spin_lock(rtc_lock);
+ spin_lock_irq(rtc_lock);
if (efi_enabled)
retval = efi_set_rtc_mmss(nowtime);
else
retval = mach_set_rtc_mmss(nowtime);
- spin_unlock(rtc_lock);
+ spin_unlock_irq(rtc_lock);
return retval;
}
If the comment is correct, and this code is called with local irq's
disabled then this patch should be using spin_lock_irqsave()
With the change below, it is always called from the timer call back code which,
I believe, is always called with irq on. Looks like I missed the comment :(
@@ -338,7 +338,7 @@ static void sync_cmos_clock(unsigned lon
}
void notify_arch_cmos_timer(void)
{
- sync_cmos_clock(0);
+ mod_timer(sync_cmos_timer, jiffies + 1);
}
static long clock_cmos_diff, sleep_start;
Your description says what this does, but it doesn't way why it was done?
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] partitions/msdos.c
On Sat, 19 Mar 2005, Werner Almesberger wrote: Andries Brouwer wrote: The two variants are: (i) partition tells the kernel to do the partition table reading, and (ii) partition uses partx to read the partition table and tells the kernel one-by-one about the partitions found this way. I guess, once you've reached the point where the kernel is unable to find partitions without user-space help, you may as well do everything in user space. I agree. This is userspace job. This can be done very easily using device-mapper. I think EVMS does something similar. I even asked on LKML some time ago about option for disabling kernel partition driver (maybe for some devices) from kernel command line to allow other tools do the job (because now I have unusable /dev/sda1 and usable /dev/evms/sda1 and this leads to stupid mistakes). But there were no replies. Grzegorz Kulewski - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation
On Sat, Mar 19, 2005 at 08:26:45PM +0100, Andi Kleen wrote:
On Fri, Mar 18, 2005 at 03:23:44PM -0600, Matt Domsch wrote:
For review and comment.
On x86_64 systems with no IOMMU and with 4GB RAM (in fact, whenever
there are any pages mapped above 4GB), pci_alloc_consistent() falls
back to using ZONE_DMA for all allocations, even if the device's
dma_mask could have supported using memory from other zones. Problems
can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume
all of ZONE_DMA, leaving none left for pci_alloc_consistent() use.
Patch below makes pci_alloc_consistent() for the nommu case (EM64T
processors) match the 2.6 implementation of dma_alloc_coherent(), with
the exception that this continues to use GFP_ATOMIC.
You fixed the wrong code. The pci-nommu code is only used
when IOMMU is disabled in the Kconfig. But most kernels have
it enabled. You would need to change it in pci-gart.c too.
OK, then how's this for review? Compiles clean, can't test it myself
for a few days.
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
= arch/x86_64/kernel/pci-gart.c 1.12 vs edited =
--- 1.12/arch/x86_64/kernel/pci-gart.c 2004-06-03 05:29:36 -05:00
+++ edited/arch/x86_64/kernel/pci-gart.c2005-03-19 15:56:34 -06:00
@@ -154,27 +154,37 @@ void *pci_alloc_consistent(struct pci_de
int gfp = GFP_ATOMIC;
int i;
unsigned long iommu_page;
+ dma_addr_t dma_mask;
- if (hwdev == NULL || hwdev-dma_mask 0x || no_iommu)
+ if (hwdev == NULL || hwdev-dma_mask 0x)
gfp |= GFP_DMA;
+ dma_mask = hwdev ? hwdev-dma_mask : 0xULL;
+ if (dma_mask == 0)
+ dma_mask = 0xULL;
+
/*
-* First try to allocate continuous and use directly if already
-* in lowmem.
+* First try to allocate continuous and use directly if
+* our device supports it
*/
size = round_up(size, PAGE_SIZE);
+ again:
memory = (void *)__get_free_pages(gfp, get_order(size));
if (memory == NULL) {
return NULL;
} else {
- int high = 0, mmu;
- if (((unsigned long)virt_to_bus(memory) + size) 0xUL)
- high = 1;
- mmu = high;
+ int high = (((unsigned long)virt_to_bus(memory) + size)
~dma_mask) != 0;
+ int mmu = high;
if (force_mmu !(gfp GFP_DMA))
mmu = 1;
if (no_iommu) {
- if (high) goto error;
+ if (high (gfp GFP_DMA))
+ goto error;
+ if (high) {
+ free_pages((unsigned long)memory,
get_order(size));
+ gfp |= GFP_DMA;
+ goto again;
+ }
mmu = 0;
}
memset(memory, 0, size);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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.11.5
Hi Greg, The changelog states that the patches for the AMD8111e and VIA-Rhine originated from dilingeratdebian.org although I was the one who they originated from. http://article.gmane.org/gmane.linux.kernel/282245 http://article.gmane.org/gmane.linux.kernel/282263 dilinger:debian.org: o Possible AMD8111e free irq issue o Possible VIA-Rhine free irq issue With friendly regards, Takis -- OpenPGP key: http://lumumba.luc.ac.be/takis/takis_public_key.txt fingerprint: 6571 13A3 33D9 3726 F728 AA98 F643 B12E ECF3 E029 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [MC] [CHECKER] Do ext2, jfs and reiserfs respect mount -o sync/dirsync option?
* Bernd Eckenfels: In article [EMAIL PROTECTED] you wrote: 3. I open a file w/o O_SYNC, issue a bunch of writes, then call ioctl(FIOASYNC) to set the fd sync, then issure a second set of writes. Only the second set of writes are synchronous? I also am curious if one can open a file, write to it, close it, open it and do fsync()/fdatasync() on it? Hopefully the fsync/fdatasync call will flush all previous writes (even from other processes). Berkeley DB relies on this behavior for correct operation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] remove redundant NULL checks before kfree() in drivers/video/
Checking a pointer for NULL before calling kfree() on it is redundant,
kfree() deals with NULL pointers just fine.
This patch removes such checks from files in drivers/video/
Since this is a fairly trivial change (and the same change made
everywhere) I've just made a single patch for all the files and CC all
authors/maintainers of those files I could find for comments. If spliting
this into one patch pr file is prefered, then I can easily do that as
well.
These are the files being modified :
drivers/video/aty/atyfb_base.c
drivers/video/aty/radeon_base.c
drivers/video/aty/radeon_monitor.c
drivers/video/console/bitblit.c
drivers/video/console/sticore.c
drivers/video/fbmem.c
drivers/video/fbmon.c
drivers/video/igafb.c
drivers/video/pxafb.c
drivers/video/riva/fbdev.c
drivers/video/sa1100fb.c
(please CC me on replies to lists other than linux-kernel)
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
--- linux-2.6.11-mm4-orig/drivers/video/aty/atyfb_base.c2005-03-16
15:45:26.0 +0100
+++ linux-2.6.11-mm4/drivers/video/aty/atyfb_base.c 2005-03-19
22:23:47.0 +0100
@@ -3435,8 +3435,7 @@ static int __devinit atyfb_pci_probe(str
err_release_io:
#ifdef __sparc__
- if (par-mmap_map)
- kfree(par-mmap_map);
+ kfree(par-mmap_map);
#else
if (par-ati_regbase)
iounmap(par-ati_regbase);
@@ -3444,7 +3443,7 @@ err_release_io:
iounmap(info-screen_base);
#endif
err_release_mem:
- if(par-aux_start)
+ if (par-aux_start)
release_mem_region(par-aux_start, par-aux_size);
release_mem_region(par-res_start, par-res_size);
@@ -3551,8 +3550,7 @@ static void __devexit atyfb_remove(struc
#endif
#endif
#ifdef __sparc__
- if (par-mmap_map)
- kfree(par-mmap_map);
+ kfree(par-mmap_map);
#endif
if (par-aux_start)
release_mem_region(par-aux_start, par-aux_size);
--- linux-2.6.11-mm4-orig/drivers/video/aty/radeon_base.c 2005-03-16
15:45:26.0 +0100
+++ linux-2.6.11-mm4/drivers/video/aty/radeon_base.c2005-03-19
22:24:39.0 +0100
@@ -2420,10 +2420,8 @@ static int radeonfb_pci_register (struct
err_unmap_fb:
iounmap(rinfo-fb_base);
err_unmap_rom:
- if (rinfo-mon1_EDID)
- kfree(rinfo-mon1_EDID);
- if (rinfo-mon2_EDID)
- kfree(rinfo-mon2_EDID);
+ kfree(rinfo-mon1_EDID);
+ kfree(rinfo-mon2_EDID);
if (rinfo-mon1_modedb)
fb_destroy_modedb(rinfo-mon1_modedb);
fb_dealloc_cmap(info-cmap);
@@ -2479,10 +2477,8 @@ static void __devexit radeonfb_pci_unreg
pci_release_regions(pdev);
- if (rinfo-mon1_EDID)
- kfree(rinfo-mon1_EDID);
- if (rinfo-mon2_EDID)
- kfree(rinfo-mon2_EDID);
+ kfree(rinfo-mon1_EDID);
+ kfree(rinfo-mon2_EDID);
if (rinfo-mon1_modedb)
fb_destroy_modedb(rinfo-mon1_modedb);
#ifdef CONFIG_FB_RADEON_I2C
--- linux-2.6.11-mm4-orig/drivers/video/aty/radeon_monitor.c2005-03-16
15:45:26.0 +0100
+++ linux-2.6.11-mm4/drivers/video/aty/radeon_monitor.c 2005-03-19
22:25:11.0 +0100
@@ -618,11 +618,9 @@ void __devinit radeon_probe_screens(stru
}
}
if (ignore_edid) {
- if (rinfo-mon1_EDID)
- kfree(rinfo-mon1_EDID);
+ kfree(rinfo-mon1_EDID);
rinfo-mon1_EDID = NULL;
- if (rinfo-mon2_EDID)
- kfree(rinfo-mon2_EDID);
+ kfree(rinfo-mon2_EDID);
rinfo-mon2_EDID = NULL;
}
--- linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c 2005-03-16
15:45:26.0 +0100
+++ linux-2.6.11-mm4/drivers/video/console/bitblit.c2005-03-19
22:27:39.0 +0100
@@ -199,8 +199,7 @@ static void bit_putcs(struct vc_data *vc
count -= cnt;
}
- if (buf)
- kfree(buf);
+ kfree(buf);
}
static void bit_clear_margins(struct vc_data *vc, struct fb_info *info,
@@ -273,8 +272,7 @@ static void bit_cursor(struct vc_data *v
dst = kmalloc(w * vc-vc_font.height, GFP_ATOMIC);
if (!dst)
return;
- if (ops-cursor_data)
- kfree(ops-cursor_data);
+ kfree(ops-cursor_data);
ops-cursor_data = dst;
update_attr(dst, src, attribute, vc);
src = dst;
@@ -321,8 +319,7 @@ static void bit_cursor(struct vc_data *v
if (!mask)
return;
- if (ops-cursor_state.mask)
- kfree(ops-cursor_state.mask);
+ kfree(ops-cursor_state.mask);
ops-cursor_state.mask = mask;
p-cursor_shape = vc-vc_cursor_type;
---
Re: [PATCH] alpha build fixes
On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
+/* TODO: integrate with include/asm-generic/pci.h ? */
+static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
+{
+ return channel ? 15 : 14;
+}
Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
Why in the world would we have this much infrastructure for one driver? And
why not just not compile that one for Alpha, since it'll never be used.
r~
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] alpha build fixes
On Sat, Mar 19, 2005 at 03:11:16PM -0800, Richard Henderson wrote:
On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
+/* TODO: integrate with include/asm-generic/pci.h ? */
+static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
+{
+ return channel ? 15 : 14;
+}
Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
Why in the world would we have this much infrastructure for one driver? And
why not just not compile that one for Alpha, since it'll never be used.
My presumption is that it will be used in other IDE drivers in the
future. Bart?
If it will only be used in that one driver, then I agree.
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gcc-4.0 compatibility fixes for i386, m68k, ppc64, x86_64
gcc-4.0 fails with
error: array type has incomplete element type
(see http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html)
on several files in linux-2.6.11.3.
Who knows, maybe all this is fixed in the -mm tree already,
but what the heck, here are a few fixes I haven't seen anyone
else post yet. These fix build problems for me, and
are all trivial. I haven't tested the resulting binaries.
See also related sets of fixes at
http://user.it.uu.se/~mikpe/linux/patches/2.6/patch-gcc4-fixes-v2-2.6.11
and
http://archives.andrew.net.au/lm-sensors/msg29809.html
I don't duplicate any of those here, I think.
--- part 1 ---
Fixes
In file included from include/asm/thread_info.h:16,
from include/linux/thread_info.h:21,
from include/linux/spinlock.h:12,
from include/linux/capability.h:45,
from include/linux/sched.h:7,
from arch/i386/kernel/asm-offsets.c:7:
include/asm/processor.h:87: error: array type has incomplete element type
make[1]: *** [arch/i386/kernel/asm-offsets.asm] Error 1
--- linux-2.6.11.3/include/asm-i386/processor.h.old Tue Mar 15 06:45:26 2005
+++ linux-2.6.11.3/include/asm-i386/processor.h Tue Mar 15 06:46:45 2005
@@ -81,6 +81,64 @@
#define X86_VENDOR_UNKNOWN 0xff
/*
+ * Size of io_bitmap.
+ */
+#define IO_BITMAP_BITS 65536
+#define IO_BITMAP_BYTES (IO_BITMAP_BITS/8)
+#define IO_BITMAP_LONGS (IO_BITMAP_BYTES/sizeof(long))
+#define INVALID_IO_BITMAP_OFFSET 0x8000
+#define INVALID_IO_BITMAP_OFFSET_LAZY 0x9000
+
+struct tss_struct {
+ unsigned short back_link,__blh;
+ unsigned long esp0;
+ unsigned short ss0,__ss0h;
+ unsigned long esp1;
+ unsigned short ss1,__ss1h; /* ss1 is used to cache
MSR_IA32_SYSENTER_CS */
+ unsigned long esp2;
+ unsigned short ss2,__ss2h;
+ unsigned long __cr3;
+ unsigned long eip;
+ unsigned long eflags;
+ unsigned long eax,ecx,edx,ebx;
+ unsigned long esp;
+ unsigned long ebp;
+ unsigned long esi;
+ unsigned long edi;
+ unsigned short es, __esh;
+ unsigned short cs, __csh;
+ unsigned short ss, __ssh;
+ unsigned short ds, __dsh;
+ unsigned short fs, __fsh;
+ unsigned short gs, __gsh;
+ unsigned short ldt, __ldth;
+ unsigned short trace, io_bitmap_base;
+ /*
+* The extra 1 is there because the CPU will access an
+* additional byte beyond the end of the IO permission
+* bitmap. The extra byte must be all 1 bits, and must
+* be within the limit.
+*/
+ unsigned long io_bitmap[IO_BITMAP_LONGS + 1];
+ /*
+* Cache the current maximum and the last task that used the bitmap:
+*/
+ unsigned long io_bitmap_max;
+ struct thread_struct *io_bitmap_owner;
+ /*
+* pads the TSS to be cacheline-aligned (size is 0x100)
+*/
+ unsigned long __cacheline_filler[35];
+ /*
+* .. and then another 0x100 bytes for emergency kernel stack
+*/
+ unsigned long stack[64];
+} __attribute__((packed));
+
+#define IO_BITMAP_OFFSET offsetof(struct tss_struct,io_bitmap)
+#define ARCH_MIN_TASKALIGN 16
+
+/*
* capabilities of CPUs
*/
@@ -308,16 +366,6 @@
#define HAVE_ARCH_PICK_MMAP_LAYOUT
-/*
- * Size of io_bitmap.
- */
-#define IO_BITMAP_BITS 65536
-#define IO_BITMAP_BYTES (IO_BITMAP_BITS/8)
-#define IO_BITMAP_LONGS (IO_BITMAP_BYTES/sizeof(long))
-#define IO_BITMAP_OFFSET offsetof(struct tss_struct,io_bitmap)
-#define INVALID_IO_BITMAP_OFFSET 0x8000
-#define INVALID_IO_BITMAP_OFFSET_LAZY 0x9000
-
struct i387_fsave_struct {
longcwd;
longswd;
@@ -371,54 +419,6 @@
} mm_segment_t;
struct thread_struct;
-
-struct tss_struct {
- unsigned short back_link,__blh;
- unsigned long esp0;
- unsigned short ss0,__ss0h;
- unsigned long esp1;
- unsigned short ss1,__ss1h; /* ss1 is used to cache
MSR_IA32_SYSENTER_CS */
- unsigned long esp2;
- unsigned short ss2,__ss2h;
- unsigned long __cr3;
- unsigned long eip;
- unsigned long eflags;
- unsigned long eax,ecx,edx,ebx;
- unsigned long esp;
- unsigned long ebp;
- unsigned long esi;
- unsigned long edi;
- unsigned short es, __esh;
- unsigned short cs, __csh;
- unsigned short ss, __ssh;
- unsigned short ds, __dsh;
- unsigned short fs, __fsh;
- unsigned short gs, __gsh;
- unsigned short ldt, __ldth;
- unsigned short trace, io_bitmap_base;
- /*
-* The extra 1 is there because the CPU will access an
-* additional byte beyond the end of the IO permission
-* bitmap. The extra byte must be all 1 bits, and must
-* be within the limit.
-*/
- unsigned long io_bitmap[IO_BITMAP_LONGS + 1];
- /*
-* Cache the current maximum
Re: [2.6 patch] fix bridge - ATM compile error
On Thu, Mar 17, 2005 at 03:36:40PM -0500, chas williams - CONTRACTOR wrote: In message [EMAIL PROTECTED],Adrian Bunk writes: Letting CONFIG_BRIDGE depend on CONFIG_ATM doesn't sound like a good idea, since I doubt all people using the Bridge code require ATM support. how about the following? ... Looks good. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] disable builtin modules
This patch makes it possible to disable built in code from the kernel
command line. The patch is rather simple - it extends the compiled-in case
of module_init() to include __setup() with a name based on KBUILD_MODNAME.
Problem: Say that your Firewire PHY breaks and you find yourself unable to
boot any installation cd that includes built in Firewire support because
the ohci1394 code together with your broken hardware makes the kernel crash
during bootup.
Solution: Boot a kernel that includes this patch and pass ohci1394=off.
Signed-off-by: Magnus Damm [EMAIL PROTECTED]
diff -urNp linux-2.6.11.4/include/linux/init.h
linux-2.6.11.4-disable_builtin/include/linux/init.h
--- linux-2.6.11.4/include/linux/init.h 2005-03-16 10:56:20.0 +0100
+++ linux-2.6.11.4-disable_builtin/include/linux/init.h 2005-03-19
23:42:29.417496240 +0100
@@ -143,6 +143,16 @@ struct obs_kernel_param {
/* Relies on saved_command_line being set */
void __init parse_early_param(void);
+
+void __init disable_initcall(void *fn);
+#define __module_init_disable(x) \
+static int __init x##_disable_module(char *str)\
+{ \
+ disable_initcall(x);\
+ return 1; \
+} \
+__setup(__stringify(KBUILD_MODNAME) =off, x##_disable_module)
+
#endif /* __ASSEMBLY__ */
/**
@@ -153,7 +163,7 @@ void __init parse_early_param(void);
* builtin) or at module insertion time (if a module). There can only
* be one per module.
*/
-#define module_init(x) __initcall(x);
+#define module_init(x) __initcall(x); __module_init_disable(x);
/**
* module_exit() - driver exit entry point
diff -urNp linux-2.6.11.4/init/main.c linux-2.6.11.4-disable_builtin/init/main.c
--- linux-2.6.11.4/init/main.c 2005-03-16 10:56:20.0 +0100
+++ linux-2.6.11.4-disable_builtin/init/main.c 2005-03-19 23:31:52.676295616
+0100
@@ -527,6 +527,17 @@ struct task_struct *child_reaper = init
extern initcall_t __initcall_start[], __initcall_end[];
+void __init disable_initcall(void *fn)
+{
+ initcall_t *call;
+
+ for (call = __initcall_start; call __initcall_end; call++) {
+
+ if (*call == fn)
+ *call = NULL;
+ }
+}
+
static void __init do_initcalls(void)
{
initcall_t *call;
@@ -541,7 +552,8 @@ static void __init do_initcalls(void)
printk(\n);
}
- (*call)();
+ if (*call)
+ (*call)();
msg = NULL;
if (preempt_count() != count) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] get rid of redundant NULL checks before kfree() in arch/i386/
Checking a pointer for NULL before calling kfree() on it is redundant,
kfree() deals with NULL pointers just fine.
This patch removes such checks from files in arch/i386/
Since this is a fairly trivial change (and the same change made
everywhere) I've just made a single patch for all four files and CC all
authors/maintainers of those files I could find for comments. If spliting
this into one patch pr file is prefered, then I can easily do that as
well.
These are the files being modified :
arch/i386/kernel/cpu/cpufreq/powernow-k7.c
arch/i386/kernel/cpu/intel_cacheinfo.c
arch/i386/kernel/cpu/mtrr/generic.c
arch/i386/kernel/io_apic.c
(please CC me on replies to lists other than linux-kernel)
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
--- linux-2.6.11-mm4-orig/arch/i386/kernel/cpu/cpufreq/powernow-k7.c
2005-03-16 15:45:02.0 +0100
+++ linux-2.6.11-mm4/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2005-03-20
00:41:27.0 +0100
@@ -643,9 +643,7 @@ static int powernow_cpu_exit (struct cpu
}
#endif
- if (powernow_table)
- kfree(powernow_table);
-
+ kfree(powernow_table);
return 0;
}
--- linux-2.6.11-mm4-orig/arch/i386/kernel/cpu/intel_cacheinfo.c
2005-03-16 15:45:02.0 +0100
+++ linux-2.6.11-mm4/arch/i386/kernel/cpu/intel_cacheinfo.c 2005-03-20
00:43:21.0 +0100
@@ -491,12 +491,9 @@ static int cpuid4_cache_sysfs_init(unsig
err_out:
for (i = 0; i NR_CPUS; i++) {
- if(cpuid4_info[i])
- kfree(cpuid4_info[i]);
- if(cache_kobject[i])
- kfree(cache_kobject[i]);
- if(index_kobject[i])
- kfree(index_kobject[i]);
+ kfree(cpuid4_info[i]);
+ kfree(cache_kobject[i]);
+ kfree(index_kobject[i]);
cpuid4_info[i] = NULL;
cache_kobject[i] = NULL;
@@ -508,12 +505,9 @@ err_out:
static int cpuid4_cache_sysfs_exit(unsigned int i)
{
- if(cpuid4_info[i])
- kfree(cpuid4_info[i]);
- if(cache_kobject[i])
- kfree(cache_kobject[i]);
- if(index_kobject[i])
- kfree(index_kobject[i]);
+ kfree(cpuid4_info[i]);
+ kfree(cache_kobject[i]);
+ kfree(index_kobject[i]);
cpuid4_info[i] = NULL;
cache_kobject[i] = NULL;
--- linux-2.6.11-mm4-orig/arch/i386/kernel/cpu/mtrr/generic.c 2005-03-16
15:45:02.0 +0100
+++ linux-2.6.11-mm4/arch/i386/kernel/cpu/mtrr/generic.c2005-03-20
00:43:39.0 +0100
@@ -70,8 +70,7 @@ void __init get_mtrr_state(void)
/* Free resources associated with a struct mtrr_state */
void __init finalize_mtrr_state(void)
{
- if (mtrr_state.var_ranges)
- kfree(mtrr_state.var_ranges);
+ kfree(mtrr_state.var_ranges);
mtrr_state.var_ranges = NULL;
}
--- linux-2.6.11-mm4-orig/arch/i386/kernel/io_apic.c2005-03-16
15:45:02.0 +0100
+++ linux-2.6.11-mm4/arch/i386/kernel/io_apic.c 2005-03-20 00:44:47.0
+0100
@@ -632,10 +632,8 @@ static int __init balanced_irq_init(void
printk(KERN_ERR balanced_irq_init: failed to spawn
balanced_irq);
failed:
for (i = 0; i NR_CPUS; i++) {
- if(irq_cpu_data[i].irq_delta)
- kfree(irq_cpu_data[i].irq_delta);
- if(irq_cpu_data[i].last_irq)
- kfree(irq_cpu_data[i].last_irq);
+ kfree(irq_cpu_data[i].irq_delta);
+ kfree(irq_cpu_data[i].last_irq);
}
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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][0/6] Change proc file permissions with sysctls
The following patches implement another interface that allows an admin to restrict permissions inside /proc/pid to enhance the privacy of users. Following a suggestion by Albert Calahan this set of patches introduces five sysctls, each one changes the permissions of a certain file in /proc/pid. It works by implementing getattr and permission methods that update the files' permissions (btw. Al Viro suggested doing it this way right from the start..). To cloak as much as currently possible: # sysctl -q proc.cmdline=0400 # sysctl -q proc.maps=0400 # sysctl -q proc.stat=0400 # sysctl -q proc.statm=0400 # sysctl -q proc.status=0400 This will set the permissions of /proc/*/cmdline etc. to the given value. The permissions of files in /proc/1 (usually belonging to init) are kept as they are. The idea is to let system processes be freely visible by anyone, just as before. Especially interesting in this regard would be instances of login. I don't know how to easily discriminate between system processes and normal processes inside the kernel (apart from pid == 1 and uid == 0 (which is too broad)). Any ideas? It's easy to make more files' permissions configurable, if the need arises. This implementation is a lot bigger than the quick hacks I sent earlier. Is this feature growing too fat? Also I'm unsure about the #ifdef'ery in fs/proc/base.c, I just wanted to be consistent with the surrounding code. :-P Rene - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00
On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote:
i have released the -V0.7.41-00 Real-Time Preemption patch (merged to
2.6.12-rc1), which can be downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
3ms latency in the NFS client code. Workload was a kernel compile over
NFS.
preemption latency trace v1.1.4 on 2.6.12-rc1-RT-V0.7.41-00
latency: 3178 s, #4095/14224, CPU#0 | (M:preempt VP:0, KP:1, SP:1 HP:1 #P:1)
-
| task: ksoftirqd/0-2 (uid:0 nice:-10 policy:0 rt_prio:0)
-
_--= CPU#
/ _-= irqs-off
| / _= need-resched
|| / _---= hardirq/softirq
||| / _--= preempt-depth
/
| delay
cmd pid | time | caller
\ /| \ | /
(T1/#0)... 32105 0 3 0004 [0011939614227867] 0.000ms
(+4137027.445ms): 6500646c (6100)
(T1/#2)... 32105 0 3 0004 0002 [0011939614228097] 0.000ms
(+0.000ms): __trace_start_sched_wakeup+0x9a/0xd0 c013150a
(try_to_wake_up+0x94/0x140 c0110474)
(T1/#3)... 32105 0 3 0003 0003 [0011939614228436] 0.000ms
(+0.000ms): preempt_schedule+0x11/0x80 c02b57c1 (try_to_wake_up+0x94/0x140
c0110474)
(T3/#4)...-32105 0dn.30s : try_to_wake_up+0x11e/0x140 c01104fe
...-2 (69 76):
(T1/#5)... 32105 0 3 0002 0005 [0011939614228942] 0.000ms
(+0.000ms): preempt_schedule+0x11/0x80 c02b57c1 (try_to_wake_up+0xf8/0x140
c01104d8)
(T1/#6)... 32105 0 3 0002 0006 [0011939614229130] 0.000ms
(+0.000ms): wake_up_process+0x35/0x40 c0110555 (do_softirq+0x3f/0x50
c011b05f)
(T6/#7)...-32105 0dn.11s (1)
(T1/#8)... 32105 0 2 0001 0008 [0011939614229782] 0.001ms
(+0.000ms): radix_tree_gang_lookup+0xe/0x70 c01e05ee
(nfs_wait_on_requests+0x6d/0x110 c01c744d)
(T1/#9)... 32105 0 2 0001 0009 [0011939614229985] 0.001ms
(+0.000ms): __lookup+0xe/0xd0 c01e051e (radix_tree_gang_lookup+0x52/0x70
c01e0632)
(T1/#10)... 32105 0 2 0001 000a [0011939614230480]
0.001ms (+0.000ms): radix_tree_gang_lookup+0xe/0x70 c01e05ee
(nfs_wait_on_requests+0x6d/0x110 c01c744d)
(T1/#11)... 32105 0 2 0001 000b [0011939614230634]
0.002ms (+0.000ms): __lookup+0xe/0xd0 c01e051e
(radix_tree_gang_lookup+0x52/0x70 c01e0632)
(T1/#12)... 32105 0 2 0001 000c [0011939614230889]
0.002ms (+0.000ms): radix_tree_gang_lookup+0xe/0x70 c01e05ee
(nfs_wait_on_requests+0x6d/0x110 c01c744d)
(T1/#13)... 32105 0 2 0001 000d [0011939614231034]
0.002ms (+0.000ms): __lookup+0xe/0xd0 c01e051e
(radix_tree_gang_lookup+0x52/0x70 c01e0632)
(T1/#14)... 32105 0 2 0001 000e [0011939614231302]
0.002ms (+0.000ms): radix_tree_gang_lookup+0xe/0x70 c01e05ee
(nfs_wait_on_requests+0x6d/0x110 c01c744d)
(T1/#15)... 32105 0 2 0001 000f [0011939614231419]
0.002ms (+0.000ms): __lookup+0xe/0xd0 c01e051e
(radix_tree_gang_lookup+0x52/0x70 c01e0632)
(last two lines just repeat)
This is probably not be a regression; I had never tested this with NFS
before.
Lee
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [KBUILD] Bug in make deb-pkg when using seperate source and object directories
On Mon, Mar 14, 2005 at 11:59:26AM -0800, Ajay Patel wrote: I had a similar problem building binrpm-pkg. Try following patch. It worked for me. My problem wasn't actually resolved by this - the make in builddeb still caused issues. So, a normal, unified diff form of the patch, fixed up, is attached. Signed-off-By: Ryan Anderson [EMAIL PROTECTED] Index: local-quilt/scripts/package/Makefile === --- local-quilt.orig/scripts/package/Makefile 2005-03-19 19:25:03.0 -0500 +++ local-quilt/scripts/package/Makefile2005-03-19 19:25:06.0 -0500 @@ -59,7 +59,7 @@ $(objtree)/binkernel.spec: $(MKSPEC) $(s $(CONFIG_SHELL) $(MKSPEC) prebuilt $@ binrpm-pkg: $(objtree)/binkernel.spec - $(MAKE) + $(MAKE) KBUILD_SRC= set -e; \ $(CONFIG_SHELL) $(srctree)/scripts/mkversion $(objtree)/.tmp_version set -e; \ @@ -74,7 +74,7 @@ clean-files += $(objtree)/binkernel.spec # .PHONY: deb-pkg deb-pkg: - $(MAKE) + $(MAKE) KBUILD_SRC= $(CONFIG_SHELL) $(srctree)/scripts/package/builddeb clean-dirs += $(objtree)/debian/ Index: local-quilt/scripts/package/builddeb === --- local-quilt.orig/scripts/package/builddeb 2005-03-19 19:25:03.0 -0500 +++ local-quilt/scripts/package/builddeb2005-03-19 19:25:27.0 -0500 @@ -25,7 +25,7 @@ cp .config $tmpdir/boot/config-$version cp $KBUILD_IMAGE $tmpdir/boot/vmlinuz-$version if grep -q '^CONFIG_MODULES=y' .config ; then - INSTALL_MOD_PATH=$tmpdir make modules_install + INSTALL_MOD_PATH=$tmpdir make KBUILD_SRC= modules_install fi # Install the maintainer scripts -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swsusp: Remove arch-specific references from generic code
Hi,
On Saturday, 19 of March 2005 23:07, Pavel Machek wrote:
Hi!
Do you think you could just send me diff between 2.6.12-rc1 and your
tree? I'll merge it here.
Sure, no problem, the diff follows. :-) It contains the following changes:
- remove swsusp_restore() (with the fix to return 0 from swsusp_arch_resume()
on x86*)
- drop SUSPEND_PD_PAGES and pagedir_order
- fix possible memory leaks in swsusp_suspend()
The original patches are also attached in case you need them (they all apply to
2.6.12-rc1).
Please let me know if that's ok.
Greets,
Rafael
diff -Nrup linux-2.6.12-rc1/arch/i386/power/swsusp.S
linux-2.6.12-rc1-new/arch/i386/power/swsusp.S
--- linux-2.6.12-rc1/arch/i386/power/swsusp.S 2005-03-20 00:36:44.0
+0100
+++ linux-2.6.12-rc1-new/arch/i386/power/swsusp.S 2005-03-20
00:38:13.0 +0100
@@ -51,6 +51,15 @@ copy_loop:
.p2align 4,,7
done:
+ /* Flush TLB, including global things (vmalloc) */
+ movlmmu_cr4_features, %eax
+ movl%eax, %edx
+ andl$~(17), %edx; # PGE
+ movl%edx, %cr4; # turn off PGE
+ movl%cr3, %ecx; # flush TLB
+ movl%ecx, %cr3
+ movl%eax, %cr4; # turn PGE back on
+
movl saved_context_esp, %esp
movl saved_context_ebp, %ebp
movl saved_context_ebx, %ebx
@@ -58,5 +67,7 @@ done:
movl saved_context_edi, %edi
pushl saved_context_eflags ; popfl
- call swsusp_restore
+
+ xorl%eax, %eax
+
ret
diff -Nrup linux-2.6.12-rc1/arch/x86_64/kernel/suspend_asm.S
linux-2.6.12-rc1-new/arch/x86_64/kernel/suspend_asm.S
--- linux-2.6.12-rc1/arch/x86_64/kernel/suspend_asm.S 2005-03-20
00:36:45.0 +0100
+++ linux-2.6.12-rc1-new/arch/x86_64/kernel/suspend_asm.S 2005-03-20
00:38:14.0 +0100
@@ -69,12 +69,21 @@ loop:
movqpbe_next(%rdx), %rdx
jmp loop
done:
+ /* Flush TLB, including global things (vmalloc) */
+ movqmmu_cr4_features(%rip), %rax
+ movq%rax, %rdx
+ andq$~(17), %rdx; # PGE
+ movq%rdx, %cr4; # turn off PGE
+ movq%cr3, %rcx; # flush TLB
+ movq%rcx, %cr3
+ movq%rax, %cr4; # turn PGE back on
+
movl$24, %eax
movl%eax, %ds
movq saved_context_esp(%rip), %rsp
movq saved_context_ebp(%rip), %rbp
- movq saved_context_eax(%rip), %rax
+ /* Don't restore %rax, it must be 0 anyway */
movq saved_context_ebx(%rip), %rbx
movq saved_context_ecx(%rip), %rcx
movq saved_context_edx(%rip), %rdx
@@ -89,5 +98,7 @@ done:
movq saved_context_r14(%rip), %r14
movq saved_context_r15(%rip), %r15
pushq saved_context_eflags(%rip) ; popfq
- callswsusp_restore
+
+ xorq%rax, %rax
+
ret
diff -Nrup linux-2.6.12-rc1/include/linux/suspend.h
linux-2.6.12-rc1-new/include/linux/suspend.h
--- linux-2.6.12-rc1/include/linux/suspend.h2005-03-20 00:36:55.0
+0100
+++ linux-2.6.12-rc1-new/include/linux/suspend.h2005-03-20
00:38:53.0 +0100
@@ -34,8 +34,6 @@ typedef struct pbe {
#define SWAP_FILENAME_MAXLENGTH32
-#define SUSPEND_PD_PAGES(x) (((x)*sizeof(struct pbe))/PAGE_SIZE+1)
-
extern dev_t swsusp_resume_device;
/* mm/vmscan.c */
diff -Nrup linux-2.6.12-rc1/kernel/power/swsusp.c
linux-2.6.12-rc1-new/kernel/power/swsusp.c
--- linux-2.6.12-rc1/kernel/power/swsusp.c 2005-03-20 00:37:04.0
+0100
+++ linux-2.6.12-rc1-new/kernel/power/swsusp.c 2005-03-20 00:38:53.0
+0100
@@ -98,7 +98,6 @@ unsigned int nr_copy_pages __nosavedata
*/
suspend_pagedir_t *pagedir_nosave __nosavedata = NULL;
static suspend_pagedir_t *pagedir_save;
-static int pagedir_order __nosavedata = 0;
#define SWSUSP_SIG S1SUSPEND
@@ -894,28 +893,21 @@ int swsusp_suspend(void)
*/
if ((error = device_power_down(PMSG_FREEZE))) {
local_irq_enable();
+ swsusp_free();
return error;
}
save_processor_state();
- error = swsusp_arch_suspend();
+ if ((error = swsusp_arch_suspend()))
+ swsusp_free();
/* Restore control flow magically appears here */
restore_processor_state();
+ BUG_ON (nr_copy_pages_check != nr_copy_pages);
restore_highmem();
device_power_up();
local_irq_enable();
return error;
}
-
-asmlinkage int swsusp_restore(void)
-{
- BUG_ON (nr_copy_pages_check != nr_copy_pages);
-
- /* Even mappings of global things (vmalloc) need to be fixed */
- __flush_tlb_global();
- return 0;
-}
-
int swsusp_resume(void)
{
int error;
@@ -1219,7 +1211,6 @@ static int check_header(void)
return -EPERM;
}
nr_copy_pages = swsusp_info.image_pages;
- pagedir_order = get_bitmask_order(SUSPEND_PD_PAGES(nr_copy_pages));
return error;
}
Re: [patch] arch hook for notifying changes in PTE protections bits
On Sat, 19 Mar 2005 12:30:05 -0800 David Mosberger [EMAIL PROTECTED] wrote: I agree about your concern about cost. Accessing the page_map is expensive (integer division + memory access) and we have to do that in order to find out if the page is i-cache clean. First, it's a multiply by reciprocol. At least on sparc64 I get this emitted by the compiler. Secondly, if you're willing to sacrifice 8 bytes per page struct simply define WANT_PAGE_VIRTUAL and page struct will be exactly 64 bytes and thus the divide a will turn into a simple shift. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Mail from batman
Attn sir, I am Mr. Batman cole the manager of ITT bank, Mr Haryanto Tomo from indonesia deposited the sum of U$10million in our bank, right now he is one of the viticms of the tsunami in asia that kill thousands. Sir, if you are willing to receive this money in your account as his next of kin call me on +23480 33127410 or email me on: [EMAIL PROTECTED] the sharing of the money between you and I will not be the problem. Thanks Batman Cole __ Try Yopolis Mail for free! Sign up for your free Web-Based or POP3 email account with 50MB of space. No Ads, No Pop-Ups, No Banners, More Space Go to http://www.yopolis.com then click on the Webmail link! Enjoy other features such as Auto Responders, Mail Forwarding, Aliases plus more. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SATA VIA8237 Problems (Install)
I have a KT600 based motherboard I am planning to set up my new system using
that. It has onboard via 8237 sata {raid, cough cough} controller. I am
planning to use a single sata disk (I am not interested in raid). The
various distro installers are having tough time noticing a brand new western
digital disk. Following is the dmesg from the installer :
##
libata version 1.10 loaded.
sata_via version 1.1
ACPI: PCI interrupt :00:0f.0[B] - GSI 11 (level, low) - IRQ 11
sata_via(:00:0f.0): routed to hard irq line 11
ata1: SATA max UDMA/133 cmd 0xB000 ctl 0xB402 bmdma 0xC000 irq 11
ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xBC02 bmdma 0xC008 irq 11
ata1: dev 0 cfg 49:3030 82:0078 83:0078 84: 85: 86:3fff 87:0010
88:000f
ata1: no dma/lba
ata1: dev 0 not supported, ignoring
scsi0 : sata_via
ata2: no device found (phy stat )
scsi1 : sata_via
###
Is the line ata1: dev 0 not supported, ignoring expected?Is there
something basic I am missing. I would appreciate any help.
I have tried to digest info on Jeff Garzik's linux.yyz.us/sata/ and also
www.linuxmafia.com/faq/Hardware/sata.html but its quite possible I might
have misinterpreted it. FWIW, the installer is 2.6.11-1 based and
following modules are present in the system. Thanks,
Jay
odule Size Used byNot tainted
parport_pc 28805 0 - Live 0xd0a1c000
parport 39689 1 parport_pc, Live 0xd09d5000
dm_snapshot 17797 0 - Live 0xd097a000
dm_mirror 25389 0 - Live 0xd0998000
dm_zero 2497 0 - Live 0xd081b000
dm_mod 61013 3 dm_snapshot,dm_mirror,dm_zero, Live 0xd0a25000
xfs 586897 0 - Live 0xd0c0f000
exportfs 8513 1 xfs, Live 0xd0902000
jfs 203897 0 - Live 0xd0ae9000
reiserfs 267317 0 - Live 0xd0aa6000
ext3 133065 0 - Live 0xd0a39000
jbd 79065 1 ext3, Live 0xd09fc000
msdos 8641 0 - Live 0xd0906000
raid6 107345 0 - Live 0xd09e
raid5 28737 0 - Live 0xd098f000
xor 15305 2 raid6,raid5, Live 0xd0939000
raid1 21441 0 - Live 0xd08ab000
raid0 8513 0 - Live 0xd08fe000
sata_via 8389 0 - Live 0xd08d
libata 47429 1 sata_via, Live 0xd0982000
via_rhine 27209 0 - Live 0xd0931000
mii 4929 1 via_rhine, Live 0xd0894000
uhci_hcd 33497 0 - Live 0xd090a000
ehci_hcd 39245 0 - Live 0xd0926000
sr_mod 19173 0 - Live 0xd08ca000
sd_mod 19137 0 - Live 0xd08b2000
scsi_mod 138665 3 libata,sr_mod,sd_mod, Live 0xd09a
edd 9889 0 - Live 0xd089
floppy 63729 0 - Live 0xd0915000
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
