Re: [PATCH] 8/8 Create MMU 2/3 level accessors in the sub-arch layer (i386)
Andrew Morton wrote: Zachary Amsden [EMAIL PROTECTED] wrote: Yeah, I said ugly ones specificly. There's been some nice previous ones, but most in this series (all the move of stuff to subarches) are rather horrible and lack lots of explanation. All of my previous patches have been aimed at fixing bugs, improving performance, reliability and maintinability of the i386 architecture. Yup, with one or two semi-exceptions, all the patches up to this series seem to be good general cleanups - certainly it's good to move all those open-coded asm statements into single-site inlines and macros: people keep on screwing them up. We do need to wake the Xen poeple up, make sure that these changes suit them as well, or at least don't screw them over (hard to see how it could though). This patch in particular is still quite controversial. I know at least Andi has objections (quite valid) to the way PAE/non-PAE was dissected, and I would definitely like to address these concerns. Although I have no objection to you committing it to the mm tree right now, please be advised that Chris Wright and I will have to converge quite a bit on this patch, and will likely be doing a substantial amount of rework here to work out Xen compatibilty issues as well as general cleanliness. If it is more convenient for you to live without that churn, by all means feel free to, and we can update the patch once everyone is happy. Zach - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] 5/8 Move descriptor table management into the sub-arch layer
Chris Wright wrote:
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
This change encapsulates descriptor and task register management.
These will need some merging together, will take a stab tomorrow.
--- linux-2.6.12-xen0-arch.orig/include/asm-i386/desc.h
+++ linux-2.6.12-xen0-arch/include/asm-i386/desc.h
@@ -14,9 +14,6 @@
static inline void __set_tss_desc(unsigned int cpu, unsigned int entry, void
*addr)
{
- _set_tssldt_desc(per_cpu(cpu_gdt_table, cpu)[entry], (int)addr,
+ _set_tssldt_desc(get_cpu_gdt_table(cpu)[entry], (int)addr,
What is Xen doing for the GDT on SMP? Does Xen have 16 pages of GDT per
CPU?
+++ linux-2.6.12-xen0-arch/include/asm-i386/mach-default/mach_desc.h
@@ -0,0 +1,57 @@
+#ifndef __ASM_MACH_DESC_H
+#define __ASM_MACH_DESC_H
+
+extern struct desc_struct cpu_gdt_table[GDT_ENTRIES];
+DECLARE_PER_CPU(struct desc_struct, cpu_gdt_table[GDT_ENTRIES]);
+#define get_cpu_gdt_table(_cpu) per_cpu(cpu_gdt_table, cpu)
+
+#define _set_tssldt_desc(n,addr,limit,type) \
+__asm__ __volatile__ (movw %w3,0(%2)\n\t \
+ movw %%ax,2(%2)\n\t \
+ rorl $16,%%eax\n\t \
+ movb %%al,4(%2)\n\t \
+ movb %4,5(%2)\n\t \
+ movb $0,6(%2)\n\t \
+ movb %%ah,7(%2)\n\t \
+ rorl $16,%%eax \
+ : =m(*(n)) : a (addr), r(n), ir(limit), i(type))
This actually doesn't need to move into sub-arch. You can redefine the
call sites (set_ldt_desc / set_tss_desc) to operate on stack (implicit
register) values instead and then notify the hypervisor about GDT
updates. Course, which way is cleaner looks still TBD.
+static inline void clear_LDT(void)
+{
+ int cpu = get_cpu();
+
+ set_ldt_desc(cpu, default_ldt[0], 5);
+ load_LDT_desc();
+ put_cpu();
+}
+
+/*
+ * load one particular LDT into the current CPU
+ */
+static inline void load_LDT_nolock(mm_context_t *pc, int cpu)
+{
+ void *segments = pc-ldt;
+ int count = pc-size;
+
+ if (likely(!count)) {
+ segments = default_ldt[0];
+ count = 5;
+ }
+
+ set_ldt_desc(cpu, segments, count);
+ load_LDT_desc();
+}
+
+#endif
These two don't actually need to move into sub-arch ; they can call
functions that have already moved.
So far looks like we are pretty much on the same page, with mostly
cosmetic differences.
Zach
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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_HAS_IRQ_PER_CPU avoids dead code in __do_IRQ()
Hi Karsten, On Sunday 07 August 2005 12:25, Karsten Wiese wrote: With my proposal the #if defined(ARCH_HAS_IRQ_PER_CPU) #endif lets readers of __do_IRQ() immediately grasp: this block might not be compiled / depends an ARCH And you'll get compile error's using IRQ_PER_CPU on ie i386, letting you immediately know, that you've got to change something to be able to use IRQ_PER_CPU. That are advantages I think. That's a valid argument. But an if is an if for the reader. It is a conditional he has to be aware of and it usally has no idention, if it is just inside #if instead of if (). I have seen people seen missing #if 0 [1] around code while reading it. Missing an normal if () is harder with proper idention. A normal conditional has also the advantage, that the compiler checks the code for syntactic and some semantic errors within it. In an #if 0 you can basically write any plain text[2] and any error will go undetected, until it becomes an #if 1. Since your define is true for most compilations out there, this argument is not very strong. Last argument: Many kernel developers -- including Linus -- don't like #if in C files and prefer them in headers. Their reasons might be similiar to my own. Regards Ingo Oeser [1] Let's just consider the values of the pre-processor symbols here, ok? [2] Pavel Machek used this already to combine Makefile and C file :-) pgpS2eoyKJboQ.pgp Description: PGP signature
Re: Getting rid of SHMMAX/SHMALL ?
On Iau, 2005-08-04 at 15:48 +0100, Hugh Dickins wrote: On Thu, 4 Aug 2005, Matti Aarnio wrote: SHM resources are non-swappable, thus I would not by default let user programs go and allocate very much SHM spaces at all. No, SHM resources are swappable. Large limits as oracle needs still allows any user to clog up the box completely. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: overcommit verses MAP_NORESERVE
On Sad, 2005-08-06 at 20:52 -0700, Nicholas Miell wrote: Why does overcommit in mode 2 (OVERCOMMIT_NEVER) explicitly force MAP_NORESERVE mappings to reserve memory? My understanding is that MAP_NORESERVE is a way for apps to state that they are aware that the memory allocated may not exist and that they might get a SIGSEGV and that's OK with them. Because a MAP_NORESERVE space that is filled with pages might cause insufficient memory to be left available for another object that is not MAP_NORESERVE. You are right it could be improved but that would require someone writing code that forcibly reclaimed MAP_NORESERVE objects when we were close to out of memory. At the moment nobody has done this, but nothing is stopping someone having a go. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/14] GFS
On Mer, 2005-08-03 at 16:33 +0200, Andi Kleen wrote: http://redhat.com/~teigland/gfs2/20050801/gfs2-full.patch http://redhat.com/~teigland/gfs2/20050801/broken-out/ I would suggest to not merge this before not all the code has not been reviewed by some experienced linux developer from outside the GFS team. Are you volunteering ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lost Ticks on x86_64
Erick Turnquist [EMAIL PROTECTED] writes: Hi, I'm running an Athlon64 X2 4400+ (a dual core model) with an nVidia GeForce 6800 Ultra on a Gigabyte GA-K8NXP-SLI motherboard and getting nasty messages like these in my dmesg: warning: many lost ticks. Your time source seems to be instable or some driver is hogging interupts rip default_idle+0x20/0x30 It's most likely bad SMM code in the BIOS that blocks the CPU too long and is triggered in idle. You can verify that by using idle=poll (not recommended for production, just for testing) and see if it goes away. No way to fix this, but you can work around it with very new kernels by compiling with a lower HZ than 1000. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Logitech Quickcam Express USB Address Aquisition Issues
On Sun, 2005-08-07 at 16:02 +0900, Chris White wrote: [Pre Note: please CC me all responses, thanks] Currently, I have a Logitech Quickcam Express webcamera. Unfortunately, it seems to have issues getting assigned an address. I quote the following from dmesg: usb 1-1.1: new full speed USB device using ehci_hcd and address 11 usb 1-1.1: device descriptor read/64, error -32 usb 1-1.1: device descriptor read/64, error -32 usb 1-1.1: new full speed USB device using ehci_hcd and address 12 usb 1-1.1: device descriptor read/64, error -32 usb 1-1.1: device descriptor read/64, error -32 usb 1-1.1: new full speed USB device using ehci_hcd and address 13 usb 1-1.1: device not accepting address 13, error -32 usb 1-1.1: new full speed USB device using ehci_hcd and address 14 usb 1-1.1: device not accepting address 14, error -32 As far as the host goes, I have the following USB hosts: :00:11.0 USB Controller: NEC Corporation USB (rev 43) :00:11.1 USB Controller: NEC Corporation USB (rev 43) :00:11.2 USB Controller: NEC Corporation USB 2.0 (rev 04) The first is my builtin Intel USB controller, the second is one belkin USB 1.0 card, and another 2.0 card. I've tried it in all three just to verify one of my hosts wasn't broken. Considering my printer works with it, as well as my scanner, I'm sort of thinking that's not an issue. I searched up google a bit and recieved some warnings about acpi causing problems, so I disabled that, but was still unsucessful in getting that to work. Please let me know if any other information is required. Thanks ahead of time. Chris White does the drivers for the Phillips web cams come back to the kernel? because i thought that it was taken out... http://www.smcc.demon.nl/webcam/ check this site and see if your cam was one of the cams that supported from the driver that discontinue... so if is supported by this driver, download and install it... it works i try it with my cam ;) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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_HAS_IRQ_PER_CPU avoids dead code in __do_IRQ()
Am Sonntag, 7. August 2005 13:07 schrieb Ingo Oeser:
Last argument: Many kernel developers -- including Linus --
don't like #if in C files and prefer them in headers.
Their reasons might be similiar to my own.
What about writing
if(CHECK_IRQ_PER_CPU(desc-status)) {
...
}
in __do_IRQ(),
and
#if defined(ARCH_HAS_IRQ_PER_CPU)
#define IRQ_PER_CPU 256 /* IRQ is per CPU */
#define CHECK_IRQ_PER_CPU(var) ((var) IRQ_PER_CPU)
#else
#define CHECK_IRQ_PER_CPU(var) 0
#endif
in include/linux/irq.h then?
Gruesse,
Karsten
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] tpm_infineon: Bugfix in PNPACPI-handling
Dear all,
Changelog:
This patch corrects the PNP-handling inside the tpm-driver
and some minor coding style bugs.
Note: the pci-device and pnp-device mixture is currently necessary,
since the used tpm-interface requires a pci-dev in order to register
the driver. This will be fixed within the next iterations.
Signed-off-by: Marcel Selhorst [EMAIL PROTECTED]
---
diff -pruN linux-2.6.13-rc5/drivers/char/tpm/tpm_infineon.c
linux-2.6.13-rc5.new/drivers/char/tpm/tpm_infineon.c
--- linux-2.6.13-rc5/drivers/char/tpm/tpm_infineon.c2005-08-06
17:07:55.0 +
+++ linux-2.6.13-rc5.new/drivers/char/tpm/tpm_infineon.c2005-08-06
18:56:46.0 +
@@ -14,7 +14,6 @@
* License.
*/
-#include acpi/acpi_bus.h
#include linux/pnp.h
#include tpm.h
@@ -29,9 +28,10 @@
#defineTPM_MAX_TRIES 5000
#defineTPM_INFINEON_DEV_VEN_VALUE 0x15D1
-/* These values will be filled after ACPI-call */
+/* These values will be filled after PnP-call */
static int TPM_INF_DATA = 0;
static int TPM_INF_ADDR = 0;
+static int pnp_registered = 0;
/* TPM header definitions */
enum infineon_tpm_header {
@@ -356,24 +356,26 @@ static const struct pnp_device_id tpm_pn
{IFX0102, 0},
{, 0}
};
+MODULE_DEVICE_TABLE(pnp, tpm_pnp_tbl);
-static int __devinit tpm_inf_acpi_probe(struct pnp_dev *dev,
+static int __devinit tpm_inf_pnp_probe(struct pnp_dev *dev,
const struct pnp_device_id *dev_id)
{
- TPM_INF_ADDR = (pnp_port_start(dev, 0) 0xff);
- TPM_INF_DATA = ((TPM_INF_ADDR + 1) 0xff);
- tpm_inf.base = pnp_port_start(dev, 1);
- dev_info(dev-dev, Found %s with ID %s\n,
+ if (pnp_port_valid(dev, 0)) {
+ TPM_INF_ADDR = (pnp_port_start(dev, 0) 0xff);
+ TPM_INF_DATA = ((TPM_INF_ADDR + 1) 0xff);
+ tpm_inf.base = pnp_port_start(dev, 1);
+ dev_info(dev-dev, Found %s with ID %s\n,
dev-name, dev_id-id);
- if (!((tpm_inf.base 8) 0xff))
- tpm_inf.base = 0;
- return 0;
+ return 0;
+ } else
+ return -ENODEV;
}
static struct pnp_driver tpm_inf_pnp = {
.name = tpm_inf_pnp,
.id_table = tpm_pnp_tbl,
- .probe = tpm_inf_acpi_probe,
+ .probe = tpm_inf_pnp_probe,
};
static int __devinit tpm_inf_probe(struct pci_dev *pci_dev,
@@ -386,19 +388,28 @@ static int __devinit tpm_inf_probe(struc
int productid[2];
char chipname[20];
- if (pci_enable_device(pci_dev))
- return -EIO;
+ rc = pci_enable_device(pci_dev);
+ if (rc)
+ return rc;
dev_info(pci_dev-dev, LPC-bus found at 0x%x\n, pci_id-device);
- /* read IO-ports from ACPI */
- pnp_register_driver(tpm_inf_pnp);
- pnp_unregister_driver(tpm_inf_pnp);
+ /* read IO-ports from PnP */
+ rc = pnp_register_driver(tpm_inf_pnp);
+ if (rc 0) {
+ dev_err(pci_dev-dev, Error %x from pnp_register_driver!\n,rc);
+ goto error2;
+ }
+ if (!rc) {
+ dev_info(pci_dev-dev, No Infineon TPM found!\n);
+ goto error;
+ } else
+ pnp_registered = 1;
/* Make sure, we have received valid config ports */
if (!TPM_INF_ADDR) {
- pci_disable_device(pci_dev);
- return -EIO;
+ dev_err(pci_dev-dev, No valid IO-ports received!\n);
+ goto error;
}
/* query chip for its vendor, its version number a.s.o. */
@@ -418,23 +429,21 @@ static int __devinit tpm_inf_probe(struc
switch ((productid[0] 8) | productid[1]) {
case 6:
- sprintf(chipname, (SLD 9630 TT 1.1));
+ snprintf(chipname, sizeof(chipname), (SLD 9630 TT 1.1));
break;
case 11:
- sprintf(chipname, (SLB 9635 TT 1.2));
+ snprintf(chipname, sizeof(chipname), (SLB 9635 TT 1.2));
break;
default:
- sprintf(chipname, (unknown chip));
+ snprintf(chipname, sizeof(chipname), (unknown chip));
break;
}
- chipname[19] = 0;
if ((vendorid[0] 8 | vendorid[1]) == (TPM_INFINEON_DEV_VEN_VALUE)) {
if (tpm_inf.base == 0) {
- dev_err(pci_dev-dev, No IO-ports found!\n);
- pci_disable_device(pci_dev);
- return -EIO;
+ dev_err(pci_dev-dev, No IO-ports found!\n);
+ goto error;
}
/* configure TPM with IO-ports */
outb(IOLIMH, TPM_INF_ADDR);
@@ -452,8 +461,7 @@ static int __devinit tpm_inf_probe(struc
dev_err(pci_dev-dev,
Could not set IO-ports to %04x\n,
tpm_inf.base);
- pci_disable_device(pci_dev);
- return
Re: assertion (cnt = tp-packets_out) failed
On Sat, Aug 06, 2005 at 02:06:53PM +0200, John B?ckstrand wrote:
Yes, I have no other patches in, so if it was not in -RC5, I was not
running it.
OK having looked at it briefly I have a hunch that it may be the
fackets_out issue (when the effective MSS is reduced tcp_tso_acked
may increase fackets_out) I referred to in another thread.
However, I'd like to be more certain as to whether this is the
cause before we do anything. So please apply this patch and
attempt to reproduce the problem. It should give us more info
which may help in pin-pointing the problem.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1474,6 +1474,10 @@ static void tcp_mark_head_lost(struct so
int cnt = packets;
BUG_TRAP(cnt = tp-packets_out);
+ if (unlikely(cnt = tp-packets_out)) {
+ printk(packets_out = %d, fackets_out = %d, reordering = %d,
sack_ok = 0x%x, mss_cache=%d\n, tp-packets_out, tp-fackets_out,
tp-reordering, tp-rx_opt.sack_ok, tp-mss_cache);
+ dump_stack();
+ }
sk_stream_for_retrans_queue(skb, sk) {
cnt -= tcp_skb_pcount(skb);
[PATCH] x86_64 Avoid some atomic operations during address space destruction
This turned out to be a huge win on 32-bit i386 in PAE mode, but it is
likely not as significant on x86_64; I don't know because I haven't
actually measured the cost. I don't have 64-bit hardware that I have
the luxury of rebooting right now, so this patch is untested, but if
someone wants to try this out, it might actually show a measurable win
on fork/exit. I lost my cycle count measurement diffs, but I don't
think they would apply cleanly to x86_64 anyways. This patch at least
looks good, and compiles cleanly on 2.6.13-rc5-mm1, thus passing some
level of testing.
Also, it might show reduced latency on pre-emptible kernels during heavy
fork/exit activity, possibly allowing ZAP_BLOCK_SIZE to be raised for
some architectures (I measured a ~30-50% reduction in cycle timings for
zap_pte_range on i386 with CONFIG_PREEMPT with the analogous patch).
Zach
Any architecture that has hardware updated A/D bits that require
synchronization against other processors during PTE operations
can benefit from doing non-atomic PTE updates during address space
destruction. Originally done on i386, now ported to x86_64.
Doing a read/write pair instead of an xchg() operation saves the
implicit lock, which turns out to be a big win on 32-bit (esp w PAE).
Diffs-against: 2.6.13-rc5-mm1
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
Index: linux-2.6.13-rc5-mm1/include/asm-x86_64/pgtable.h
===
--- linux-2.6.13-rc5-mm1.orig/include/asm-x86_64/pgtable.h 2005-08-07
04:56:37.0 -0700
+++ linux-2.6.13-rc5-mm1/include/asm-x86_64/pgtable.h 2005-08-07
04:59:18.601856096 -0700
@@ -104,6 +104,19 @@
((unsigned long) __va(pud_val(pud) PHYSICAL_PAGE_MASK))
#define ptep_get_and_clear(mm,addr,xp) __pte(xchg((xp)-pte, 0))
+
+static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, unsigned
long addr, pte_t *ptep, int full)
+{
+ pte_t pte;
+ if (full) {
+ pte = *ptep;
+ *ptep = __pte(0);
+ } else {
+ pte = ptep_get_and_clear(mm, addr, ptep);
+ }
+ return pte;
+}
+
#define pte_same(a, b) ((a).pte == (b).pte)
#define PMD_SIZE (1UL PMD_SHIFT)
@@ -433,6 +446,7 @@
#define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
#define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_DIRTY
#define __HAVE_ARCH_PTEP_GET_AND_CLEAR
+#define __HAVE_ARCH_PTEP_GET_AND_CLEAR_FULL
#define __HAVE_ARCH_PTEP_SET_WRPROTECT
#define __HAVE_ARCH_PTE_SAME
#include asm-generic/pgtable.h
[PATCH] net/ipv4 debug cleanup, kernel 2.6.13-rc5
Here's a small patch to cleanup NETDEBUG() use in net/ipv4/ for Linux
kernel 2.6.13-rc5. Also weird use of indentation is changed in some
places.
Signed-off-by: Heikki Orsila [EMAIL PROTECTED]
---
diff -urp linux-2.6.13-rc5-org/net/ipv4/icmp.c linux-2.6.13-rc5/net/ipv4/icmp.c
--- linux-2.6.13-rc5-org/net/ipv4/icmp.c2005-08-02 07:45:48.0
+0300
+++ linux-2.6.13-rc5/net/ipv4/icmp.c2005-08-07 15:10:42.0 +0300
@@ -936,8 +936,7 @@ int icmp_rcv(struct sk_buff *skb)
case CHECKSUM_HW:
if (!(u16)csum_fold(skb-csum))
break;
- NETDEBUG(if (net_ratelimit())
- printk(KERN_DEBUG icmp v4 hw csum failure\n));
+ LIMIT_NETDEBUG(printk(KERN_DEBUG icmp v4 hw csum failure\n));
case CHECKSUM_NONE:
if ((u16)csum_fold(skb_checksum(skb, 0, skb-len, 0)))
goto error;
diff -urp linux-2.6.13-rc5-org/net/ipv4/ip_fragment.c
linux-2.6.13-rc5/net/ipv4/ip_fragment.c
--- linux-2.6.13-rc5-org/net/ipv4/ip_fragment.c 2005-08-02 07:45:48.0
+0300
+++ linux-2.6.13-rc5/net/ipv4/ip_fragment.c 2005-08-07 15:15:05.0
+0300
@@ -377,7 +377,7 @@ static struct ipq *ip_frag_create(unsign
return ip_frag_intern(hash, qp);
out_nomem:
- NETDEBUG(if (net_ratelimit()) printk(KERN_ERR ip_frag_create: no
memory left !\n));
+ LIMIT_NETDEBUG(printk(KERN_ERR ip_frag_create: no memory left !\n));
return NULL;
}
@@ -625,10 +625,8 @@ static struct sk_buff *ip_frag_reasm(str
return head;
out_nomem:
- NETDEBUG(if (net_ratelimit())
-printk(KERN_ERR
- IP: queue_glue: no memory for gluing queue %p\n,
- qp));
+ LIMIT_NETDEBUG(printk(KERN_ERR IP: queue_glue: no memory for gluing
+ queue %p\n, qp));
goto out_fail;
out_oversize:
if (net_ratelimit())
diff -urp linux-2.6.13-rc5-org/net/ipv4/tcp_ipv4.c
linux-2.6.13-rc5/net/ipv4/tcp_ipv4.c
--- linux-2.6.13-rc5-org/net/ipv4/tcp_ipv4.c2005-08-02 07:45:48.0
+0300
+++ linux-2.6.13-rc5/net/ipv4/tcp_ipv4.c2005-08-07 15:03:28.0
+0300
@@ -1494,12 +1494,11 @@ int tcp_v4_conn_request(struct sock *sk,
* to destinations, already remembered
* to the moment of synflood.
*/
- NETDEBUG(if (net_ratelimit()) \
- printk(KERN_DEBUG TCP: drop open
- request from %u.%u.
- %u.%u/%u\n, \
- NIPQUAD(saddr),
- ntohs(skb-h.th-source)));
+ LIMIT_NETDEBUG(printk(KERN_DEBUG TCP: drop open
+ request from %u.%u.
+ %u.%u/%u\n,
+ NIPQUAD(saddr),
+ ntohs(skb-h.th-source)));
dst_release(dst);
goto drop_and_free;
}
@@ -1627,8 +1626,7 @@ static int tcp_v4_checksum_init(struct s
skb-nh.iph-daddr, skb-csum))
return 0;
- NETDEBUG(if (net_ratelimit())
- printk(KERN_DEBUG hw tcp v4 csum failed\n));
+ LIMIT_NETDEBUG(printk(KERN_DEBUG hw tcp v4 csum failed\n));
skb-ip_summed = CHECKSUM_NONE;
}
if (skb-len = 76) {
diff -urp linux-2.6.13-rc5-org/net/ipv4/udp.c linux-2.6.13-rc5/net/ipv4/udp.c
--- linux-2.6.13-rc5-org/net/ipv4/udp.c 2005-08-02 07:45:48.0 +0300
+++ linux-2.6.13-rc5/net/ipv4/udp.c 2005-08-07 15:16:57.0 +0300
@@ -628,7 +628,7 @@ back_from_confirm:
/* ... which is an evident application bug. --ANK */
release_sock(sk);
- NETDEBUG(if (net_ratelimit()) printk(KERN_DEBUG udp cork app
bug 2\n));
+ LIMIT_NETDEBUG(printk(KERN_DEBUG udp cork app bug 2\n));
err = -EINVAL;
goto out;
}
@@ -693,7 +693,7 @@ static int udp_sendpage(struct sock *sk,
if (unlikely(!up-pending)) {
release_sock(sk);
- NETDEBUG(if (net_ratelimit()) printk(KERN_DEBUG udp cork app
bug 3\n));
+ LIMIT_NETDEBUG(printk(KERN_DEBUG udp cork app bug 3\n));
return -EINVAL;
}
@@ -1102,7 +1102,7 @@ static int udp_checksum_init(struct sk_b
skb-ip_summed = CHECKSUM_UNNECESSARY;
if (!udp_check(uh, ulen, saddr, daddr, skb-csum))
return 0;
- NETDEBUG(if (net_ratelimit()) printk(KERN_DEBUG udp v4 hw csum
failure.\n));
+
[patch resend] w100fb: Update corgi platform code to match new driver
This patch moves the platform specific Sharp SL-C7x0 LCD code from
the w100fb driver into a more appropriate place and updates the Corgi
code to match the new w100fb driver.
It also updates the corgi touchscreen code to match the new
simplified interface available from w100fb.
Signed-off-by: Richard Purdie [EMAIL PROTECTED]
Index: linux-2.6.12/arch/arm/mach-pxa/Makefile
===
--- linux-2.6.12.orig/arch/arm/mach-pxa/Makefile2005-08-05
17:31:38.0 +0100
+++ linux-2.6.12/arch/arm/mach-pxa/Makefile 2005-08-05 17:31:47.0
+0100
@@ -11,7 +11,7 @@
obj-$(CONFIG_ARCH_LUBBOCK) += lubbock.o
obj-$(CONFIG_MACH_MAINSTONE) += mainstone.o
obj-$(CONFIG_ARCH_PXA_IDP) += idp.o
-obj-$(CONFIG_PXA_SHARP_C7xx) += corgi.o corgi_ssp.o ssp.o
+obj-$(CONFIG_PXA_SHARP_C7xx) += corgi.o corgi_ssp.o corgi_lcd.o ssp.o
obj-$(CONFIG_MACH_POODLE) += poodle.o
# Support for blinky lights
Index: linux-2.6.12/arch/arm/mach-pxa/corgi.c
===
--- linux-2.6.12.orig/arch/arm/mach-pxa/corgi.c 2005-08-05 17:31:38.0
+0100
+++ linux-2.6.12/arch/arm/mach-pxa/corgi.c 2005-08-05 17:31:47.0
+0100
@@ -39,7 +39,6 @@
#include asm/mach/sharpsl_param.h
#include asm/hardware/scoop.h
-#include video/w100fb.h
#include generic.h
@@ -78,7 +77,7 @@
* also use scoop functions and this makes the power up/down order
* work correctly.
*/
-static struct platform_device corgissp_device = {
+struct platform_device corgissp_device = {
.name = corgi-ssp,
.dev= {
.parent = corgiscoop_device.dev,
@@ -88,35 +87,6 @@
/*
- * Corgi w100 Frame Buffer Device
- */
-static struct w100fb_mach_info corgi_fb_info = {
- .w100fb_ssp_send= corgi_ssp_lcdtg_send,
- .comadj = -1,
- .phadadj= -1,
-};
-
-static struct resource corgi_fb_resources[] = {
- [0] = {
- .start = 0x0800,
- .end= 0x08ff,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device corgifb_device = {
- .name = w100fb,
- .id = -1,
- .dev= {
- .platform_data = corgi_fb_info,
- .parent = corgissp_device.dev,
- },
- .num_resources = ARRAY_SIZE(corgi_fb_resources),
- .resource = corgi_fb_resources,
-};
-
-
-/*
* Corgi Backlight Device
*/
static struct platform_device corgibl_device = {
@@ -234,9 +204,6 @@
static void __init corgi_init(void)
{
- corgi_fb_info.comadj=sharpsl_param.comadj;
- corgi_fb_info.phadadj=sharpsl_param.phadadj;
-
pxa_gpio_mode(CORGI_GPIO_USB_PULLUP | GPIO_OUT);
pxa_set_udc_info(udc_info);
pxa_set_mci_info(corgi_mci_platform_data);
Index: linux-2.6.12/arch/arm/mach-pxa/corgi_lcd.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.12/arch/arm/mach-pxa/corgi_lcd.c 2005-08-07 11:18:01.0
+0100
@@ -0,0 +1,396 @@
+/*
+ * linux/drivers/video/w100fb.c
+ *
+ * Corgi LCD Specific Code for ATI Imageon w100 (Wallaby)
+ *
+ * Copyright (C) 2005 Richard Purdie
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include linux/delay.h
+#include linux/kernel.h
+#include linux/device.h
+#include asm/arch/corgi.h
+#include asm/mach/sharpsl_param.h
+#include video/w100fb.h
+
+/* Register Addresses */
+#define RESCTL_ADRS 0x00
+#define PHACTRL_ADRS0x01
+#define DUTYCTRL_ADRS 0x02
+#define POWERREG0_ADRS 0x03
+#define POWERREG1_ADRS 0x04
+#define GPOR3_ADRS 0x05
+#define PICTRL_ADRS 0x06
+#define POLCTRL_ADRS0x07
+
+/* Resgister Bit Definitions */
+#define RESCTL_QVGA 0x01
+#define RESCTL_VGA 0x00
+
+#define POWER1_VW_ON0x01 /* VW Supply FET ON */
+#define POWER1_GVSS_ON 0x02 /* GVSS(-8V) Power Supply ON */
+#define POWER1_VDD_ON 0x04 /* VDD(8V),SVSS(-4V) Power Supply ON */
+
+#define POWER1_VW_OFF 0x00 /* VW Supply FET OFF */
+#define POWER1_GVSS_OFF 0x00 /* GVSS(-8V) Power Supply OFF */
+#define POWER1_VDD_OFF 0x00 /* VDD(8V),SVSS(-4V) Power Supply OFF */
+
+#define POWER0_COM_DCLK 0x01 /* COM Voltage DC Bias DAC Serial Data Clock */
+#define POWER0_COM_DOUT 0x02 /* COM Voltage DC Bias DAC Serial Data Out */
+#define POWER0_DAC_ON 0x04 /* DAC Power Supply ON */
+#define POWER0_COM_ON 0x08 /* COM Powewr Supply ON */
+#define POWER0_VCC5_ON 0x10 /* VCC5 Power Supply ON */
+
+#define POWER0_DAC_OFF 0x00 /* DAC Power Supply OFF */
+#define POWER0_COM_OFF 0x00 /* COM Powewr Supply OFF */
+#define POWER0_VCC5_OFF 0x00 /* VCC5 Power Supply
FYI: device_suspend(...) in kernel_power_off().
Early in the 2.6.13 process my kexec related patches were introduced
into the reboot path, and under the rule you touch it you fix it
it I have been involved in tracking quite a few regressions
on the reboot path.
Recently with Benjamin Herrenschmidt's removal of
device_suppend(PMSG_SUPPEND) from kernel_power_off(),
it seems the last of the issues went away. I asked
for confirmation that reintroducing the patch below
would break systems and I received it.
The experimental evidence then is that calling
device_suspend(PMSG_SUSPEND) in kernel_power_off
when performing an acpi_power_off is actively harmful.
There as been a fair amount of consensus that calling
device_suspend(...) in the reboot path was inappropriate now, because
the device suspend code was too immature. With this latest
piece of evidence it seems to me that introducing device_suspend(...)
in kernel_power_off, kernel_halt, kernel_reboot, or kernel_kexec
can never be appropriate. I am including as many people as
I can on this so we in our collective wisdom don't forget this
lesson.
What lead us to this situation was a real problem, and a desire
to fix it. Currently linux has a proliferation of interfaces
to place devices in different states. The reboot notifiers,
device_suspend(...), device_shutdown+system_state, remove_one,
module_exit, and probably a few I'm not aware of. Each interface
introduced by a different author wanting to solve a different problem.
Just writing this list of interfaces is confusing. The implementation
task for device driver writers appears even harder as simultaneously
implementing all of these interfaces correctly seems not to happen.
The lesson: fixing this problem is heavy lifting, and that
device_suspend() in the reboot path is not the answer.
Eric
This is the patch that subtly and mysterously broke things.
diff --git a/kernel/sys.c b/kernel/sys.c
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -404,6 +404,7 @@ void kernel_halt(void)
{
notifier_call_chain(reboot_notifier_list, SYS_HALT, NULL);
system_state = SYSTEM_HALT;
+ device_suspend(PMSG_SUSPEND);
device_shutdown();
printk(KERN_EMERG System halted.\n);
machine_halt();
@@ -414,6 +415,7 @@ void kernel_power_off(void)
{
notifier_call_chain(reboot_notifier_list, SYS_POWER_OFF, NULL);
system_state = SYSTEM_POWER_OFF;
+ device_suspend(PMSG_SUSPEND);
device_shutdown();
printk(KERN_EMERG Power down.\n);
machine_power_off();
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] fix warning in sa1100fb.c
On Sat, Jul 30, 2005 at 04:35:51PM +0200, Pavel Machek wrote: Fix compile-time warning in sa1100fb.c I think it makes sense to change this to an inline function. Thanks for pointing this out. -- 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: assertion (cnt = tp-packets_out) failed
Someone asked if I could try to trigger this assertion again, and I'm afraid I probably cannot, I didnt do anything special at the time. But I've got something even better for you all, got a BUG from something tcp-related. Mind you, I am trying to find a possibly hardware-related issue here, so if this bug does not make any sense it might be my hardware! I would actually want to know it if this is likely hardware-related or not, since I have no idea if its RAM, CPU, motherboard or only a disk that is broken. I know _something_ is broken, due to lockups, and seeing a faulty disk indicated in a HDD diag, but only once, the disk is apparently fine 99% of the time. --- John Bäckstrand [148475.651000] [ cut here ] [148475.651050] kernel BUG at net/ipv4/tcp_output.c:918! [148475.651078] invalid operand: [#1] [148475.651103] Modules linked in: sha256 aes_i586 dm_crypt ipt_state ipt_multiport ipt_MASQUERADE iptable_filter netconsole md5 ipv6 af_packet pdc202xx_new e1000 8139cp de2104x i2c_viapro via686a i2c_sensor i2c_core uhci_hcd usbcore 3c59x 8139too mii de4x5 crc32 parport_pc parport reiserfs dm_mod ip_nat_ftp iptable_nat ip_tables ip_conntrack_ftp ip_conntrack rtc unix [148475.651378] CPU:0 [148475.651380] EIP:0060:[c0286619]Not tainted VLI [148475.651383] EFLAGS: 00010287 (2.6.13-rc5sand4) [148475.651464] EIP is at tcp_tso_should_defer+0xc9/0xe0 [148475.651494] eax: 002b ebx: ce49a660 ecx: 002c edx: ca008d00 [148475.651526] esi: 002c edi: 000e ebp: 99d57104 esp: c0865dec [148475.651556] ds: 007b es: 007b ss: 0068 [148475.651582] Process tor (pid: 10849, threadinfo=c0864000 task=c6234530) [148475.651602] Stack: ce49a660 002c ca008d00 99d57104 c02866fc ca008d00 ca008d00 ce49a660 [148475.651676]003a 0102 000e 0001 ca008d00 ca008d00 ca008d00 c9290034 [148475.651751]c0286a49 ca008d00 05b4 0001 c0254674 81dd5b2f 81dd5b2f 0010 [148475.651823] Call Trace: [148475.651869] [c02866fc] tcp_write_xmit+0xcc/0x3e0 [148475.651910] [c0286a49] __tcp_push_pending_frames+0x39/0xd0 [148475.651947] [c0254674] kfree_skbmem+0x24/0x30 [148475.651988] [c0283bbe] tcp_rcv_established+0x26e/0x840 [148475.652033] [c028c935] tcp_v4_do_rcv+0x115/0x120 [148475.652072] [c028cf8f] tcp_v4_rcv+0x64f/0x890 [148475.652106] [c02735b0] ip_local_deliver_finish+0x0/0x1c0 [148475.652150] [c0265a6e] nf_hook_slow+0x6e/0x100 [148475.652199] [c0272f63] ip_local_deliver+0xe3/0x250 [148475.652234] [c02735b0] ip_local_deliver_finish+0x0/0x1c0 [148475.652272] [c0273425] ip_rcv+0x355/0x4e0 [148475.652309] [c0273770] ip_rcv_finish+0x0/0x290 [148475.652347] [c0259f11] netif_receive_skb+0x1f1/0x270 [148475.652394] [c025a00f] process_backlog+0x7f/0x100 [148475.652431] [c025a10a] net_rx_action+0x7a/0x120 [148475.652467] [c011b9bd] __do_softirq+0x7d/0x90 [148475.652509] [c011b9f6] do_softirq+0x26/0x30 [148475.652544] [c010561e] do_IRQ+0x1e/0x30 [148475.652588] [c0103a92] common_interrupt+0x1a/0x20 [148475.652630] Code: db 74 1d 89 f8 0f af c2 39 f0 0f 46 f0 31 d2 89 f0 f7 f3 31 d2 39 c1 73 cb ba 01 00 00 00 eb c4 6b c2 03 31 d2 39 c1 77 bb eb ee 0f 0b 96 03 20 2f 2e c0 eb 83 8b ba 7c 02 00 00 eb ee 90 8d 74 [148475.653330] 0Kernel panic - not syncing: Fatal exception in interrupt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] mips: moreover remove vr4181
Hi, We also need this patch for removing mips vr4181. Please apply. Yoichi Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED] diff -urN -X dontdiff mm1-orig/arch/mips/Makefile mm1/arch/mips/Makefile --- mm1-orig/arch/mips/Makefile 2005-08-07 22:15:17.0 +0900 +++ mm1/arch/mips/Makefile 2005-08-07 22:08:19.0 +0900 @@ -469,13 +469,6 @@ load-$(CONFIG_LASAT) += 0x8000 # -# NEC Osprey (vr4181) board -# -core-$(CONFIG_NEC_OSPREY) += arch/mips/vr4181/common/ \ - arch/mips/vr4181/osprey/ -load-$(CONFIG_NEC_OSPREY) += 0x80002000 - -# # Common VR41xx # core-$(CONFIG_MACH_VR41XX) += arch/mips/vr41xx/common/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Fri, 2005-08-05 at 08:17 -0700, Christoph Lameter wrote: On Thu, 4 Aug 2005, Richard Purdie wrote: We know the the failure case can be identified by the cmpxchg_fail_flag_update condition being met. Can you provide me with a patch to dump useful debugging information when that occurs? Well yes simply print out the information available in that context. + printk(KERN_CRIT cmpxchg fail mm=%p vma=%p addr=%lx write=%d ptep=%p pmd=%p entry=%lx new=%lx\n, + mm, vma, address, write_access, pte, pmd, pte_val(entry), pte_val(new_entry)); Ok, this results in an infinite loop of one message with no change to the numbers: cmpxchg fail mm=c3455ae0 vma=c355517c addr=4025f000 write=2048 ptep=c2f0597c pmd=c2b79008 entry=88000f7 new=8800077 Richard - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote: On Fri, 2005-08-05 at 19:38 +0200, Bodo Eggert wrote: On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote: On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote: My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized. 2.6.12 does not show this behaviour. I'm out of town at the moment, could you maybe diff radeonfb between working non-working and CC me the diff ? I don't have my work stuff at hand not my kernel images so... There were no changes in radeonfb.c, but I could trace to to CONFIG_PREEMPT. With _NONE, it works as expected. Ah ! Interesting... I don't see why PREEMPT would affect radeonfb though ... Can you try something like wrapper radeon_write_mode() with preempt_disable()/preempt_enable() and tell me if it makes a difference ? I'm having a similar issue with my shiny new 17 Powerbook G4. The radeon chip works fine with framebuffer in 2.6.12.4 _with_ PREEMPT, but not in 2.6.13-rc5 _with_ PREEMPT (configs are virtually identical). I'll try your idea this afternoon when I get the chance. I wonder if perhaps some code in radeonfb is used under the BKL, which is now preemptable (Or maybe an ordinary spinlock changed or went away?), because I also set PREEMPT_BKL. I've got an LCD, and on mine it looks like every third pixel-line gets shifted about 32-64 pixels to the left, and they move with display refresh. My guess is that something is interrupting radeonfb during a critical time in display syncing and forcing the video card to wait too far into the next line before sending pixels. One other data point, I've seen something like this, except not nearly as bad, is stock debian 2.6.8 vs. stock debian 2.6.11 on powerpc. The former exhibits some similar (but not nearly as bad) symptoms. (Same Powerbook), whereas 2.6.11 doesn't. In that case, neither has PREEMPT. I'll run more tests this afternoon/evening, to try to track it down. Cheers, Kyle Moffett -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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-rc5 and 2.6.12: cannot transmit anything - more info
On Thursday 04 August 2005 23:45, Tommy Christensen wrote: Denis Vlasenko wrote: Hi, As reported earlier, sometimes my home box don't want to send anything. # ip r 1.1.5.5 dev tun0 proto kernel scope link src 1.1.5.6 1.1.4.0/24 dev if proto kernel scope link src 1.1.4.6 default via 1.1.5.5 dev tun0 # ping 1.1.4.1 -i 0.01 2005-08-02_19:12:18.19551 kern.info: qdisc_restart: start, q-dequeue=c03e8662 2005-08-02_19:12:19.19536 kern.info: qdisc_restart: start, q-dequeue=c03e8662 System.map: c03e8662 t noop_dequeue I guess this explains why I do not see calls to pfifo_fast_dequeue! :) But how come my interface is using noop queue, is a mystery to me. Because link is down. Or at least the kernel thinks so. # ip l 1: if: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0a:e6:7c:dd:79 brd ff:ff:ff:ff:ff:ff 2: lo: LOOPBACK,UP mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 17: tun0: POINTOPOINT,MULTICAST,NOARP,UP mtu 1464 qdisc pfifo_fast qlen 100 link/[65534] As you can see, ip l reports that iface 'if' uses pfifo_fast, not noop... Yeah, a bit confusing. pfifo_fast is the *configured* qdisc, but in this case it is not the *active* qdisc. The qdisc is set to noop when carrier is lost. Any ideas? Try tracking the calls to netif_carrier_on/off. Your analysis is correct. I just caught it again. diff between logs: /* Basic mode status register. */ #define BMSR_ERCAP 0x0001 /* Ext-reg capability */ #define BMSR_JCD0x0002 /* Jabber detected */ #define BMSR_LSTATUS0x0004 /* Link status */ #define BMSR_ANEGCAPABLE0x0008 /* Able to do auto-negotiation */ #define BMSR_RFAULT 0x0010 /* Remote fault detected */ #define BMSR_ANEGCOMPLETE 0x0020 /* Auto-negotiation complete */ #define BMSR_RESV 0x07c0 /* Unused... */ #define BMSR_10HALF 0x0800 /* Can do 10mbps, half-duplex */ #define BMSR_10FULL 0x1000 /* Can do 10mbps, full-duplex */ #define BMSR_100HALF0x2000 /* Can do 100mbps, half-duplex */ #define BMSR_100FULL0x4000 /* Can do 100mbps, full-duplex */ #define BMSR_100BASE4 0x8000 /* Can do 100mbps, 4k packets */ 9 = 1001 - link down D = 1101 - link up --- klogSun Aug 7 14:21:20 2005 +++ klog2 Sun Aug 7 14:21:29 2005 @@ -125,7 +125,7 @@ kern.warn: PCI: setting IRQ 11 as level-triggered kern.info: ACPI: PCI Interrupt :00:12.0[A] - Link [LNKA] - GSI 11 (level, low) - IRQ 11 kern.info: eth0: VIA Rhine II at 0x1e800, 00:0a:e6:7c:dd:79, IRQ 11. -kern.info: eth0: MII PHY found at address 1, status 0x7849 advertising 05e1 Link . +kern.info: eth0: MII PHY found at address 1, status 0x784d advertising 05e1 Link . ^^ Here. It thinks that link is down. I will run ethtool next time... kern.warn: cs89x0:cs89x0_probe(0x0) kern.warn: PP_addr=0x kern.err: eth1: incorrect signature 0x @@ -287,13 +287,27 @@ kern.info: ACPI: PCI Interrupt :00:11.5[C] - Link [LNKC] - GSI 10 (level, low) - IRQ 10 kern.debug: PCI: Setting latency timer of device :00:11.5 to 64 kern.warn: netdev tun0: qdisc = pfifo_fast_qdisc -kern.warn: qdisc_restart: start, q-dequeue=c03e8662 -kern.warn: qdisc_restart: start, q-dequeue=c03e8662 -kern.warn: qdisc_restart: start, q-dequeue=c03e8662 == noop +kern.warn: pfifo_fast_enqueue returns 0 +kern.warn: qdisc_restart: start, q-dequeue=c03e8752 == pfifo_fast +kern.warn: pfifo_fast_dequeue returns a skb +kern.warn: qdisc_restart: skb!=NULL +kern.warn: qdisc_restart: start, q-dequeue=c03e8752 +kern.warn: pfifo_fast_dequeue returns NULL +kern.warn: pfifo_fast_enqueue returns 0 +kern.warn: qdisc_restart: start, q-dequeue=c03e8752 +kern.warn: pfifo_fast_dequeue returns a skb +kern.warn: qdisc_restart: skb!=NULL +kern.warn: qdisc_restart: start, q-dequeue=c03e8752 +kern.warn: pfifo_fast_dequeue returns NULL kern.warn: pfifo_fast_enqueue returns 0 kern.warn: pfifo_fast_dequeue returns a skb kern.warn: pfifo_fast_dequeue returns NULL -kern.warn: qdisc_restart: start, q-dequeue=c03e8662 +kern.warn: pfifo_fast_enqueue returns 0 +kern.warn: qdisc_restart: start, q-dequeue=c03e8752 +kern.warn: pfifo_fast_dequeue returns a skb +kern.warn: qdisc_restart: skb!=NULL +kern.warn: qdisc_restart: start, q-dequeue=c03e8752 +kern.warn: pfifo_fast_dequeue returns NULL kern.info: usbcore: registered new driver usbfs ... -- vda - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] fix ucb1x00 support on collie
On Sun, Jul 31, 2005 at 04:42:45PM +0100, Russell King wrote: On Sun, Jul 31, 2005 at 03:46:17PM +0200, Pavel Machek wrote: Collie is slightly strange; it does not seem to have proper ucb1x00 ID. With this patch, basic ucb support seems to work and I can get interrupts from battery. Out of interest, what ID does it appear to have? diff --git a/drivers/misc/mcp-sa1100.c b/drivers/misc/mcp-sa1100.c --- a/drivers/misc/mcp-sa1100.c +++ b/drivers/misc/mcp-sa1100.c @@ -149,7 +149,7 @@ static int mcp_sa1100_probe(struct devic !machine_is_graphicsmaster() !machine_is_lart() !machine_is_omnimeter() !machine_is_pfs168() !machine_is_shannon() !machine_is_simpad() - !machine_is_yopy()) + !machine_is_yopy()!machine_is_collie()) I think it's about time we did something better with this, like only registering the platform device on those which use it. @@ -181,7 +187,10 @@ static int mcp_sa1100_probe(struct devic Ser4MCSR = -1; Ser4MCCR1 = 0; - Ser4MCCR0 = 0x7f7f | MCCR0_ADM; + if (machine_is_collie()) + Ser4MCCR0 = MCCR0_ADM | MCCR0_ExtClk; + else + Ser4MCCR0 = 0x7f7f | MCCR0_ADM; And this setup should probably be passed as part of the platform device data. Ok, new set of patches on the ftp site with the above two items resolved. I've also moved it into drivers/mfd and linked that directory into kbuild. Of course, the audio driver isn't expected to build without Nico's sa11x0 audio support. -- 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: Lost Ticks on x86_64
No way to fix this, but you can work around it with very new kernels by compiling with a lower HZ than 1000. John Stultz's timeofday patches seem to fix this lost ticks issue. You might want to try them. (I too, routinely get lost ticks - rip is at acpi_processor_idle messages which vanished during the period when I was trying John's patches.) Parag - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: As of 2.6.13-rc1 Fusion-MPT very slow
On Sun, 2005-08-07 at 05:59 +, Holger Kiehl wrote: Thanks, removing those it compiles fine. This patch also solves my problem, here the output of dmesg: Well ... the transport class was supposed to help diagnose the problem rather than fix it. However, what it shows is that the original problem is in the fusion internal domain validation somewhere, but that we still don't know where... James - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: Re: Elitegroup K7S5A + usb_storage problem
On Sun, 7 Aug 2005, Martin Maurer wrote: Hi Pete, when using ub with your patch i get a lot further: the device is detected and uba+uba1 entries appear. I can mount the device correctly. Copying the files down and comparing them with the originals gives correct results. but: when i delete the files which are on the stick and do an umount/mount cycle, the files are there again. Copying files to the stick gives wrong results too. Once the created file vanished after the remount, and once it was there with a different name/size/date and garbage as content. It sounds as though the device isn't actually carrying out the write operations. Is it write-protected? Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: Re: Elitegroup K7S5A + usb_storage problem
Hi Alan, no. the stick doesn't have a write protection switch. Once when i tried to copy a file to the mp3 player i got a new file there on remount, but it consisted of incorrect data. (so writing seemed to be possible and just went wrong) (in that case the fat seemed to be damaged after i had tried this, so that windows wasn't able to read it correctly any more. (formatting from the mp3 players menu helped) greetings Martin PS: just as an info - i sent a usbmon trace to Pete Zaitcev today, should I send it to you too? Alan Stern [EMAIL PROTECTED] schrieb am 07.08.05 17:14:52: On Sun, 7 Aug 2005, Martin Maurer wrote: Hi Pete, when using ub with your patch i get a lot further: the device is detected and uba+uba1 entries appear. I can mount the device correctly. Copying the files down and comparing them with the originals gives correct results. but: when i delete the files which are on the stick and do an umount/mount cycle, the files are there again. Copying files to the stick gives wrong results too. Once the created file vanished after the remount, and once it was there with a different name/size/date and garbage as content. It sounds as though the device isn't actually carrying out the write operations. Is it write-protected? Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] more vr4181 removal
On Sun, Aug 07, 2005 at 01:42:14AM -0700, Andrew Morton wrote:
...
Changes since 2.6.13-rc4-mm1:
...
+mips-remove-vr4181-support.patch
...
MIPS stuff
...
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
arch/mips/Kconfig| 12 +---
arch/mips/Makefile |7 ---
arch/mips/kernel/cpu-probe.c |6 --
3 files changed, 1 insertion(+), 24 deletions(-)
--- linux-2.6.13-rc5-mm1-full/arch/mips/Kconfig.old 2005-08-07
17:31:12.0 +0200
+++ linux-2.6.13-rc5-mm1-full/arch/mips/Kconfig 2005-08-07 17:32:04.0
+0200
@@ -445,11 +445,6 @@
depends on DDB5477
default 0
-config NEC_OSPREY
- bool Support for NEC Osprey board
- select DMA_NONCOHERENT
- select IRQ_CPU
-
config SGI_IP22
bool Support for SGI IP22 (Indy/Indigo2)
select ARC
@@ -974,7 +969,7 @@
config CPU_LITTLE_ENDIAN
bool Generate little endian code
- default y if ACER_PICA_61 || CASIO_E55 || DDB5074 || DDB5476 || DDB5477
|| MACH_DECSTATION || IBM_WORKPAD || LASAT || MIPS_COBALT || MIPS_ITE8172 ||
MIPS_IVR || SOC_AU1X00 || NEC_OSPREY || OLIVETTI_M700 || SNI_RM200_PCI ||
VICTOR_MPC30X || ZAO_CAPCELLA
+ default y if ACER_PICA_61 || CASIO_E55 || DDB5074 || DDB5476 || DDB5477
|| MACH_DECSTATION || IBM_WORKPAD || LASAT || MIPS_COBALT || MIPS_ITE8172 ||
MIPS_IVR || SOC_AU1X00 || OLIVETTI_M700 || SNI_RM200_PCI || VICTOR_MPC30X ||
ZAO_CAPCELLA
default n if MIPS_EV64120 || MIPS_EV96100 || MOMENCO_OCELOT ||
MOMENCO_OCELOT_G || SGI_IP22 || SGI_IP27 || SGI_IP32 || TOSHIBA_JMR3927
help
Some MIPS machines can be configured for either little or big endian
@@ -1091,11 +1086,6 @@
config HAVE_STD_PC_SERIAL_PORT
bool
-config VR4181
- bool
- depends on NEC_OSPREY
- default y
-
config ARC_CONSOLE
bool ARC console support
depends on SGI_IP22 || SNI_RM200_PCI
--- linux-2.6.13-rc5-mm1-full/arch/mips/Makefile.old2005-08-07
17:32:19.0 +0200
+++ linux-2.6.13-rc5-mm1-full/arch/mips/Makefile2005-08-07
17:32:30.0 +0200
@@ -469,13 +469,6 @@
load-$(CONFIG_LASAT) += 0x8000
#
-# NEC Osprey (vr4181) board
-#
-core-$(CONFIG_NEC_OSPREY) += arch/mips/vr4181/common/ \
- arch/mips/vr4181/osprey/
-load-$(CONFIG_NEC_OSPREY) += 0x80002000
-
-#
# Common VR41xx
#
core-$(CONFIG_MACH_VR41XX) += arch/mips/vr41xx/common/
--- linux-2.6.13-rc5-mm1-full/arch/mips/kernel/cpu-probe.c.old 2005-08-07
17:32:45.0 +0200
+++ linux-2.6.13-rc5-mm1-full/arch/mips/kernel/cpu-probe.c 2005-08-07
17:33:46.0 +0200
@@ -229,15 +229,9 @@
break;
case PRID_IMP_VR41XX:
switch (c-processor_id 0xf0) {
-#ifndef CONFIG_VR4181
case PRID_REV_VR4111:
c-cputype = CPU_VR4111;
break;
-#else
- case PRID_REV_VR4181:
- c-cputype = CPU_VR4181;
- break;
-#endif
case PRID_REV_VR4121:
c-cputype = CPU_VR4121;
break;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] 6700/6702PXH quirk
On Saturday 06 August 2005 18:57, Jeff Garzik wrote: On Sat, Aug 06, 2005 at 09:50:13AM +0100, Matthew Wilcox wrote: On Fri, Aug 05, 2005 at 11:34:55PM -0400, Jeff Garzik wrote: FWIW, compilers generate AWFUL code for bitfields. Bitfields are really tough to do optimally, whereas bit flags [unsigned int flags bitmask] are the familiar ints and longs that the compiler is well tuned to optimize. I'm sure the GCC developers would appreciate a good bug report with a test-case that generates worse code. If you don't want to mess with their bug tracking system, just send me a test case and I'll add it for you. Its an order-of-complexity issue. No matter how hard you try, bitfields will -always- be tougher to optimize, than machine ints. Bitfields are weirdly-sized, weirdly-aligned integers. A simple look at the generated asm from gcc on ARM or MIPS demonstrates the explosion of code that can sometimes occur, versus a simple 'and' test of a machine int and a mask. x86 is a tiny bit better, but still more expensive to do bitfields than machine ints. But we are talking about one-bit field here: + unsigned intno_msi:1; /* device may not use msi */ If _this_ isn't optimized nicely into ANDs, ORs, etc, then bug report is in order and gcc should be fixed. -- vda - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
any update on the pcmcia bug blocking Audigy2 notebook sound card driver development
Hi all, I remember there's a kernel pcmcia bug preventing the development for the Audigy2 pcmcia notebook sound card driver. See http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-Creative_Labs#matrix Is there any new updates on the situation? Has the bug been fixed? or anyone working on it? Thanks, Raymond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] drivers/net/phy/phy_device.c: fix compilation
On Sun, Aug 07, 2005 at 01:42:14AM -0700, Andrew Morton wrote: ... Changes since 2.6.13-rc4-mm1: ... git-netdev-upstream.patch ... Subsystem trees ... gcc 4.0 correctly rejects this code: -- snip -- ... CC drivers/net/phy/phy_device.o drivers/net/phy/phy_device.c:659: error: static declaration of 'genphy_driver' follows non-static declaration include/linux/phy.h:377: error: previous declaration of 'genphy_driver' was here make[3]: *** [drivers/net/phy/phy_device.o] Error 1 -- snip -- Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- linux-2.6.13-rc5-mm1-full/include/linux/phy.h.old 2005-08-07 15:34:01.0 +0200 +++ linux-2.6.13-rc5-mm1-full/include/linux/phy.h 2005-08-07 15:34:08.0 +0200 @@ -374,5 +374,4 @@ void phy_print_status(struct phy_device *phydev); extern struct bus_type mdio_bus_type; -extern struct phy_driver genphy_driver; #endif /* __PHY_H */ --- linux-2.6.13-rc5-mm1-full/drivers/net/phy/phy_device.c.old 2005-08-07 15:34:15.0 +0200 +++ linux-2.6.13-rc5-mm1-full/drivers/net/phy/phy_device.c 2005-08-07 15:39:34.0 +0200 @@ -39,6 +39,8 @@ #include asm/irq.h #include asm/uaccess.h +static struct phy_driver genphy_driver; + /* get_phy_device * * description: Reads the ID registers of the PHY at addr on the - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
I'm having a similar issue with my shiny new 17 Powerbook G4. The radeon chip works fine with framebuffer in 2.6.12.4 _with_ PREEMPT, but not in 2.6.13-rc5 _with_ PREEMPT (configs are virtually identical). I'll try your idea this afternoon when I get the chance. Note that PREEMPT is known to cause problems on ppc32 ... I'm not sure what's up yet. (Random SIGILLs/SEGVs in userland typically) I wonder if perhaps some code in radeonfb is used under the BKL, which is now preemptable (Or maybe an ordinary spinlock changed or went away?), because I also set PREEMPT_BKL. radeonfb should only rely on the console semaphore I've got an LCD, and on mine it looks like every third pixel-line gets shifted about 32-64 pixels to the left, and they move with display refresh. My guess is that something is interrupting radeonfb during a critical time in display syncing and forcing the video card to wait too far into the next line before sending pixels. radeonfb is mostly inactive after it has setup the framebuffer and unless you actually draw something, in which case, accel code is called. _However_ there is an unrelated problem with some panels, including some of the 17: The panel doesn't always sync properly. This seem to be related to some subtle timing issue in the LVDS code but I don't know exactly what yet. You can usually get it back by repeately turning the backlight all the way down (which shuts the panel off) and back up until it catches. One other data point, I've seen something like this, except not nearly as bad, is stock debian 2.6.8 vs. stock debian 2.6.11 on powerpc. The former exhibits some similar (but not nearly as bad) symptoms. (Same Powerbook), whereas 2.6.11 doesn't. In that case, neither has PREEMPT. I'll run more tests this afternoon/evening, to try to track it down. Cheers, Kyle Moffett -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lost Ticks on x86_64
On Sun, Aug 07, 2005 at 02:29:16PM +, Parag Warudkar wrote: No way to fix this, but you can work around it with very new kernels by compiling with a lower HZ than 1000. John Stultz's timeofday patches seem to fix this lost ticks issue. You might want to try them. (I too, routinely get lost ticks - rip is at acpi_processor_idle messages which vanished during the period when I was trying John's patches.) They will just hide the problem in this case. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: assertion (cnt = tp-packets_out) failed
David S. Miller wrote: I suspect this is a side effect of some changes Herbert Xu and myself did to fix some other bugs. I think I crossed this bug independently today. I did some testing, and got kernel panics when uploading files with ftp on a gigabit lan. The error happens always at net/ipv4/tcp_output.c:918. Here's a matrix of combinations that crashes or doesn't crash: kernel what happens 2.6.12 no crash 2.6.13-rc1 e1000 no crash 2.6.13-rc1 skge no crash 2.6.13-rc2 e1000 crash 2.6.13-rc2 skge no crash 2.6.13-rc3 e1000 crash 2.6.13-rc3 skge no crash 2.6.13-rc5 e1000 crash 2.6.13-rc5 skge no crash There were big changes in tcp_output.c between rc1 and rc2, and the bug is triggered when using e1000 with rc2 or later. And because the bug does not happen on skge (new sk98 driver) it makes me guess it's a race condition of sorts.. I am surprised this bug wasn't noticed with rc2. The crash happens just in the beginning of a tcp connection. Only some packets are sent and then the sends stall by slowing down, and after 5 secs the kernel crashes. Basically usage pattern is this: upload file a upload file b upload file a (replaces old file) upload file b (replaces old file) upload file a (replaces old file) = slowdown and then a crash in 5 secs Here's the kernel greeting: Kernel BUG at net/ipv4/tcp_output.c:918 Invalid operand: [1] CPU 0 Modules linked in: Pid 0, comm: swapper Not tainted 2.6.13-rc5 RIP: 0010:[804d086d] 804d086d__tcp_push_pending_frames+429 ... Process swapper (pid: 0, threadinfo 807de000, task 80640ec0) ... Call Trace: IRQ 804ce30ctcp_rcv_established+1964 ... tcp_v4_do_rcv+37 ... ...ip_local_deliver_finish+0 ... tcp_v4_rcv+1483 ... ...ip_local_deliver+322 ... ip_rcv+1107 ... ...netif_receive_skb+426 ... process_backlog+154 ... __do_softirq+83 ... do_softirq+53 ... ret_from_intr+0 ... default_idle+0 ... cpu_idle+49 ... _sinittext+534 ... ... ... ... ... ... ... RIP 804d086d__tcp_push_pending_frames+429 ... 0Kernel panic - not syncing: Aiee, killing interrupt handler! Here's system info: Linux e275d 2.6.13-rc2 #1 Sun Aug 7 18:48:05 EEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux Gnu C 3.4.3 Gnu make 3.80 binutils 2.15.92.0.2 util-linux 2.12i mount 2.12i module-init-tools 3.0 e2fsprogs 1.38 jfsutils 1.1.4 reiserfsprogs line reiser4progs line xfsprogs 2.6.25 nfs-utils 1.0.6 Linux C Library2.3.5 Dynamic linker (ldd) 2.3.5 Procps 3.2.5 Net-tools 1.60 Kbd1.12 Sh-utils 5.2.1 udev 058 Modules Loaded -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] remove support for gcc 3.2
On Monday 01 August 2005 01:36, David S. Miller wrote: From: Adrian Bunk [EMAIL PROTECTED] Date: Mon, 1 Aug 2005 00:26:07 +0200 - my impression is that the older compilers are only rarely used, so miscompilations of a driver with an old gcc might not be detected for a longer amount of time Many people still use 2.95 because it's still the fastest way to get a kernel build done and that's important for many people. And with 4.0 being a scary regression in the compile time performance area compared to 3.4, this becomes even more important to keep around. This is a rather strange form of progress, especially since in my experience newer gcc's do not show significant reductions in code size... -- vda - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: assertion (cnt = tp-packets_out) failed
Herbert Xu [EMAIL PROTECTED] wrote: Hang on a second, the original poster mentioned rc5. Is this really pristine rc5 with the one netpoll patch? If so then it can't be the patches we're talking about because they only went in days later. I produced a similar panic on rc2 and later (which doesn't happen on rc1). See my other post in this thread. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: assertion (cnt = tp-packets_out) failed
Heikki Orsila wrote: There were big changes in tcp_output.c between rc1 and rc2, and the bug is triggered when using e1000 with rc2 or later. And because the bug does not happen on skge (new sk98 driver) it makes me guess it's a race condition of sorts.. I am surprised this bug wasn't noticed with rc2. One more bit of info: there was no e1000 driver changes between rc1 and rc2, which increases the evidence that the error was induced by tcp_output.c. -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.13-rc5-mm1: oops when starting nscd on AMD64
Hi,
I get the following Oops after trying to start nscd from YaST on an
Athlon64-based box
(compiled with CONFIG_DEBUG_SPINLOCK=y):
Unable to handle kernel NULL pointer dereference at 0008 RIP:
801664d8{kmem_cache_alloc+232}
PGD 1501a067 PUD 1501b067 PMD 0
Oops: [1] PREEMPT
CPU 0
Modules linked in: raw af_key usbserial thermal processor fan button battery ac
snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97t
Pid: 6570, comm: nscd Not tainted 2.6.13-rc5-mm1
RIP: 0010:[801664d8] 801664d8{kmem_cache_alloc+232}
RSP: 0018:81001506de88 EFLAGS: 00010202
RAX: RBX: 8010eb3e RCX:
RDX: RSI: 8100292bdd68 RDI: 810001c3f6c0
RBP: 81001506deb8 R08: R09: 8100292bdd70
R10: 0006 R11: R12: 810001c3f6c0
R13: 8100292bdd68 R14: 80d0 R15: 801abe5c
FS: 2b11cb00() GS:804f2840() knlGS:56abc320
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0008 CR3: 15019000 CR4: 06e0
Process nscd (pid: 6570, threadinfo 81001506c000, task 81001506b250)
Stack: 0246 81001569b5a0 8100155fe980
fff4 000a 81001506df78 801abe5c
40a05fff 81001569b5a0
Call Trace:801abe5c{sys_epoll_create+604}
80243579{add_preempt_count+105}
8010eb3e{system_call+126}
BUG: spinlock trylock failure on UP on CPU#0, nscd/6570
lock: 803bae80, .magic: dead4ead, .owner: nscd/6570, .owner_cpu: 0
Call Trace:80243579{add_preempt_count+105}
802431a3{spin_bug+211}
8011004b{show_trace+571}
8024328e{_raw_spin_trylock+62}
8035270e{_spin_trylock+30} 8010fc81{oops_begin+17}
803538ea{do_page_fault+1722} 801343de{vprintk+830}
801343de{vprintk+830} 801521f6{kallsyms_lookup+246}
8010f431{error_exit+0} 8011004b{show_trace+571}
80110047{show_trace+567} 80110168{show_stack+216}
80110207{show_registers+135} 8011050e{__die+142}
80353958{do_page_fault+1832} 802410c1{vsnprintf+1393}
801abe5c{sys_epoll_create+604} 8010f431{error_exit+0}
801abe5c{sys_epoll_create+604}
8010eb3e{system_call+126}
801664d8{kmem_cache_alloc+232}
801664c8{kmem_cache_alloc+216}
801abe5c{sys_epoll_create+604}
80243579{add_preempt_count+105}
8010eb3e{system_call+126}
---
| preempt count: 0002 ]
| 2 level deep critical section nesting:
.. [80352706] _spin_trylock+0x16/0x60
.[8010fc81] .. ( = oops_begin+0x11/0x60)
.. [80352706] _spin_trylock+0x16/0x60
.[8010fc81] .. ( = oops_begin+0x11/0x60)
It causes other Oopses to appear in an infinite loop (some of them are
attached).
This is 100% reproducible, and 2.6.13-rc5 is not affected.
Greets,
Rafael
--
- 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
Unable to handle kernel NULL pointer dereference at 0008 RIP:
8011004b{show_trace+571}
PGD 1501a067 PUD 1501b067 PMD 0
Oops: [2] PREEMPT
CPU 0
Modules linked in: raw af_key usbserial thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97t
Pid: 6570, comm: nscd Not tainted 2.6.13-rc5-mm1
RIP: 0010:[8011004b] 8011004b{show_trace+571}
RSP: 0018:81001506dbc8 EFLAGS: 00010092
RAX: 0001 RBX: 002b RCX:
RDX: RSI: 0096 RDI: 0001
RBP: 81001506dc08 R08: R09: 0001
R10: 81001506dae8 R11: R12: 81001506e000
R13: R14: 0024 R15: 80463fc0
FS: 2b11cb00() GS:804f2840() knlGS:56abc320
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0008 CR3: 15019000 CR4: 06e0
Process nscd (pid: 6570, threadinfo 81001506c000, task 81001506b250)
Stack: 0092 1506dc08 81001506ded8
000a 80463fc0 8045ffc0
81001506dc48 80110168
Call Trace:80110168{show_stack+216} 80110207{show_registers+135}
8011050e{__die+142} 80353958{do_page_fault+1832}
802410c1{vsnprintf+1393} 801abe5c{sys_epoll_create+604}
8010f431{error_exit+0} 801abe5c{sys_epoll_create+604}
DMA problem with kernel 2.6.10
Hi all,
I'm trying to figure out the reason of my laptop problem.
I beg your help to find the right way to debug it (I mean,
I don't want to flood the mailing list with useless details,
and so on).
Well, let's try...
Hardware: Toshiba Satellite P20 (P4-3200 MHz, 512MB RAM) [1]
Software: Debian Unstable
GCC: 3.4.5 [2]
Memtest86+: v.1.60 (stress tools, CPU/RAM and so on, are all happy)
Problem: with kernel =2.6.10 everything is all right...
but with any kernel released after 2.6.10 (pre, rc, stable, mm, and
so on), I've got this:
hda: dma_timer_expiry: dma status == 0x21
hda: DMA timeout error
hda: dma timeout error: status=0xd0 { Busy }
ide: failed opcode was: unknown
hda: DMA disabled
ide0: reset: success
Losing too many ticks!
TSC cannot be used as a timesource.
Possible reasons for this are:
You're running with Speedstep,
You don't have DMA enabled for your hard disk (see hdparm),
Incorrect TSC synchronization on an SMP system (see dmesg).
Falling back to a sane timesource now.
hda: dma_timer_expiry: dma status == 0x21
hda: DMA timeout error
hda: dma timeout error: status=0xd0 { Busy }
ide: failed opcode was: unknown
hda: DMA disabled
ide0: reset: success
after a stress activity of the hd (I can achieve this by unrar big
files, or using 'iozone -A').
I wanna make it clear: with 2.6.10, HD can work for days without
rest/poweroff/reboot.
It's enough to switch to another kernel 2.6.10 to have the
problem.
With some kernel, system simply freeze, with other it survive and
gives the DMA notice. Anyway, when it happens, I've got a big filesystem
corruption (I tried both ext2 and ext3).
It happen quickly if I do also something like this:
cd /proc/sys/vm
echo 100 dirty_background_ratio
echo 100 dirty_expire_centisecs
echo 100 dirty_ratio
echo 100 dirty_writeback_centisecs
It could be useful to apply all 2.6.11 patch to 2.6.10 *but* the
IDE layer?
Or, which are really useful information about it?
Thanks a lot for your time and work,
Andrea
---
[1] Sorry, I didn't find an official homepage. anyway:
(lspci)
:00:00.0 Host bridge: Intel Corp. 82865G/PE/P DRAM Controller/Host-Hub
Interface (rev 02)
:00:01.0 PCI bridge: Intel Corp. 82865G/PE/P PCI to AGP Controller (rev 02)
:00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1
(rev 02)
:00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2
(rev 02)
:00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3
(rev 02)
:00:1d.3 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4
(rev 02)
:00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI
Controller (rev 02)
:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2)
:00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02)
:00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100
Storage Controller (rev 02)
:00:1f.3 SMBus: Intel Corp. 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev
02)
:00:1f.5 Multimedia audio controller: Intel Corp. 82801EB/ER (ICH5/ICH5R)
AC'97 Audio Controller (rev 02)
:00:1f.6 Modem: Intel Corp. 82801EB/ER (ICH5/ICH5R) AC'97 Modem Controller
(rev 02)
:01:00.0 VGA compatible controller: nVidia Corporation NV34M [GeForce FX Go
5200] (rev a1)
:02:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000
Controller (PHY/Link)
:02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
:02:04.0 CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to
Cardbus Bridge with ZV Support (rev 32)
:02:04.1 CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to
Cardbus Bridge with ZV Support (rev 32)
:02:06.0 System peripheral: Toshiba America Info Systems SD TypA Controller
(rev 03)
(dmidecode)
Vendor: TOSHIBA
Version: V1.20
Release Date: 06/24/2003
Address: 0xE4DF0
Runtime Size: 20 bytes
ROM Size: 512 kB
Handle 0x0001
DMI type 1, 25 bytes.
System Information
Manufacturer: TOSHIBA
Product Name: Satellite P20
Processor Information
Socket Designation: NWD
Type: Central Processor
Family: Pentium 4
Manufacturer: Intel
ID: 29 0F 00 00 FF FB EB BF
Signature: Type 0, Family 15, Model 2, Stepping 9
DMI type 6, 12 bytes.
Memory Module Information
Socket Designation: M1
Bank Connections: 0 1
Current Speed: Unknown
Type:
Re: [PATCH] tpm_infineon: Bugfix in PNPACPI-handling
Marcel Selhorst [EMAIL PROTECTED] wrote:
This patch corrects the PNP-handling inside the tpm-driver
and some minor coding style bugs.
But the patch adds lots of new coding style bugs!
...
@@ -356,24 +356,26 @@ static const struct pnp_device_id tpm_pn
{IFX0102, 0},
{, 0}
};
+MODULE_DEVICE_TABLE(pnp, tpm_pnp_tbl);
-static int __devinit tpm_inf_acpi_probe(struct pnp_dev *dev,
+static int __devinit tpm_inf_pnp_probe(struct pnp_dev *dev,
const struct pnp_device_id *dev_id)
{
-TPM_INF_ADDR = (pnp_port_start(dev, 0) 0xff);
-TPM_INF_DATA = ((TPM_INF_ADDR + 1) 0xff);
-tpm_inf.base = pnp_port_start(dev, 1);
-dev_info(dev-dev, Found %s with ID %s\n,
+if (pnp_port_valid(dev, 0)) {
+TPM_INF_ADDR = (pnp_port_start(dev, 0) 0xff);
+TPM_INF_DATA = ((TPM_INF_ADDR + 1) 0xff);
+tpm_inf.base = pnp_port_start(dev, 1);
+dev_info(dev-dev, Found %s with ID %s\n,
dev-name, dev_id-id);
We use hard tabs for indentation at eight columns each, not four-spaces.
Fixed-up version:
diff -puN
drivers/char/tpm/tpm_infineon.c~tpm_infineon-bugfix-in-pnpacpi-handling
drivers/char/tpm/tpm_infineon.c
---
devel/drivers/char/tpm/tpm_infineon.c~tpm_infineon-bugfix-in-pnpacpi-handling
2005-08-07 09:50:06.0 -0700
+++ devel-akpm/drivers/char/tpm/tpm_infineon.c 2005-08-07 09:51:50.0
-0700
@@ -14,7 +14,6 @@
* License.
*/
-#include acpi/acpi_bus.h
#include linux/pnp.h
#include tpm.h
@@ -29,9 +28,10 @@
#defineTPM_MAX_TRIES 5000
#defineTPM_INFINEON_DEV_VEN_VALUE 0x15D1
-/* These values will be filled after ACPI-call */
+/* These values will be filled after PnP-call */
static int TPM_INF_DATA = 0;
static int TPM_INF_ADDR = 0;
+static int pnp_registered = 0;
/* TPM header definitions */
enum infineon_tpm_header {
@@ -356,24 +356,26 @@ static const struct pnp_device_id tpm_pn
{IFX0102, 0},
{, 0}
};
+MODULE_DEVICE_TABLE(pnp, tpm_pnp_tbl);
-static int __devinit tpm_inf_acpi_probe(struct pnp_dev *dev,
+static int __devinit tpm_inf_pnp_probe(struct pnp_dev *dev,
const struct pnp_device_id *dev_id)
{
- TPM_INF_ADDR = (pnp_port_start(dev, 0) 0xff);
- TPM_INF_DATA = ((TPM_INF_ADDR + 1) 0xff);
- tpm_inf.base = pnp_port_start(dev, 1);
- dev_info(dev-dev, Found %s with ID %s\n,
-dev-name, dev_id-id);
- if (!((tpm_inf.base 8) 0xff))
- tpm_inf.base = 0;
- return 0;
+ if (pnp_port_valid(dev, 0)) {
+ TPM_INF_ADDR = (pnp_port_start(dev, 0) 0xff);
+ TPM_INF_DATA = ((TPM_INF_ADDR + 1) 0xff);
+ tpm_inf.base = pnp_port_start(dev, 1);
+ dev_info(dev-dev, Found %s with ID %s\n,
+ dev-name, dev_id-id);
+ return 0;
+ }
+ return -ENODEV;
}
static struct pnp_driver tpm_inf_pnp = {
.name = tpm_inf_pnp,
.id_table = tpm_pnp_tbl,
- .probe = tpm_inf_acpi_probe,
+ .probe = tpm_inf_pnp_probe,
};
static int __devinit tpm_inf_probe(struct pci_dev *pci_dev,
@@ -386,19 +388,30 @@ static int __devinit tpm_inf_probe(struc
int productid[2];
char chipname[20];
- if (pci_enable_device(pci_dev))
- return -EIO;
+ rc = pci_enable_device(pci_dev);
+ if (rc)
+ return rc;
dev_info(pci_dev-dev, LPC-bus found at 0x%x\n, pci_id-device);
- /* read IO-ports from ACPI */
- pnp_register_driver(tpm_inf_pnp);
- pnp_unregister_driver(tpm_inf_pnp);
+ /* read IO-ports from PnP */
+ rc = pnp_register_driver(tpm_inf_pnp);
+ if (rc 0) {
+ dev_err(pci_dev-dev,
+ Error %x from pnp_register_driver!\n,rc);
+ goto error2;
+ }
+ if (!rc) {
+ dev_info(pci_dev-dev, No Infineon TPM found!\n);
+ goto error;
+ } else {
+ pnp_registered = 1;
+ }
/* Make sure, we have received valid config ports */
if (!TPM_INF_ADDR) {
- pci_disable_device(pci_dev);
- return -EIO;
+ dev_err(pci_dev-dev, No valid IO-ports received!\n);
+ goto error;
}
/* query chip for its vendor, its version number a.s.o. */
@@ -418,23 +431,21 @@ static int __devinit tpm_inf_probe(struc
switch ((productid[0] 8) | productid[1]) {
case 6:
- sprintf(chipname, (SLD 9630 TT 1.1));
+ snprintf(chipname, sizeof(chipname), (SLD 9630 TT 1.1));
break;
case 11:
- sprintf(chipname, (SLB 9635 TT 1.2));
+ snprintf(chipname, sizeof(chipname), (SLB 9635 TT 1.2));
break;
default:
- sprintf(chipname, (unknown chip));
+
Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 5
On Sun, Aug 07, 2005 at 03:12:21PM +1000, Con Kolivas wrote: Respin of the dynamic ticks patch for i386 by Tony Lindgen and Tuukka Tikkanen with further code cleanups. Are were there yet? Con, I am afraid until SMP correctness is resolved, then this is not in a position to go in (unless you want to enable it only for UP, which I think should not be our target). I am working on making this work correctly on SMP systems. Hopefully I will post a patch soon. Another observation I have made regarding dynamic tick patch is that PIT is being reprogrammed whenever the CPUs are coming out of sleep state (because of an interrupt say). This can happen at any arbitary time, not necessarily on jiffy boundaries. As a result, there will be an offset between when jiffy interrupts will now occur vs when they would have originally occured had PIT never been stopped. Not sure if having this offset is good, but atleast one necessary change that I foresee if zeroing delay_at_last_interrupt when disabling dynamic tick. For that matter, it may be easier to disable the PIT timer by just masking PIT interrupts (instead of changing its mode). Will keep you posted of my progress with dynamic tick patch. -- Thanks and Regards, Srivatsa Vaddagiri, Linux Technology Center, IBM Software Labs, Bangalore, INDIA - 560017 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lost Ticks on x86_64
It's most likely bad SMM code in the BIOS that blocks the CPU too long and is triggered in idle. Might a BIOS flash help, or is this something that's there to stay? No way to fix this, but you can work around it with very new kernels by compiling with a lower HZ than 1000. Actually, it was already running at 250Hz. I must have turned it down a while ago while I was trying to find the cause of the problem. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc5 seemed to kill a disk that rc4-mm1 likes. Also some X trouble.
Andrew Morton [EMAIL PROTECTED] wrote: Helge Hafting [EMAIL PROTECTED] wrote: 2.6.13-rc5 seemed to kill a scsi disk (sdb) for me, where 2.6.13-rc4-mm1 have no problems with the same disk. Sort of same with me: 2.6.12-mm1 runs for _weeks_ where others keep crashing: The latest -git kernel (or 2.6.13-rc6 if it's there) with APCI enabled is the one to test, please. no rc6 yet, i did however experience the following: reboot system boot 2.6.12-mm1 Sun Aug 7 18:20 (00:36) dth pts/1zaphod.dth.net Sun Aug 7 15:41 - crash (02:38) reboot system boot 2.6.13-rc5-git5 Sun Aug 7 14:04 (04:52) reboot system boot 2.6.13-rc5-git4 Sun Aug 7 10:05 (03:43) reboot system boot 2.6.13-rc5-git3 Fri Aug 5 16:55 (1+17:07) git3 lasted near 2 days git4 ran for nearly 5 hours than i upgraded to git5 didn't last longer than 2.5 hours Fortunatly some info was found in the log files. What i dont get is that ethernet also goes down when the scsi controller goes bezerk. I'm pretty sure it's not a hardware problem since 2.6.12-mm1 survives and brings this usenet host in the worldwide top 1000. From the log files: scsi1: Transmission error detected LQISTAT1[0x8]:(LQICRCI_NLQ) LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISIGI[0x60]:(P_DATAIN_DT) PERRDIAG[0x4]:(CRCERR) Dump Card State Begins scsi1: Dumping Card State at program address 0x11 Mode 0x33 Card was paused HS_MAILBOX[0x0] INTCTL[0xc0]:(SWTMINTEN|SWTMINTMASK) SEQINTSTAT[0x10]:(SEQ_SWTMRTO) SAVED_MODE[0x11] DFFSTAT[0x24]:(CURRFIFO_0|FIFO1FREE) SCSISIGI[0xb6]:(P_MESGOUT|REQI|BSYI|ATNI) SCSIPHASE[0x4]:(MSG_OUT_PHASE) SCSIBUS[0xff] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x0] SEQINTCTL[0x0] SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] SSTAT0[0x2]:(SPIORDY) SSTAT1[0x19]:(REQINIT|BUSFREE|PHASEMIS) SSTAT2[0x20]:(NONPACKREQ) SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x8]:(LQICRCI_NLQ) LQISTAT2[0xc0]:(LQIPHASE_OUTPKT|PACKETIZED) LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0xe1]:(LQOSTOP0|LQOPKT) SCB Count = 128 CMDS_PENDING = 2 LASTSCB 0x34 CURRSCB 0x8 NEXTSCB 0xffc0 qinstart = 15426 qinfifonext = 15426 QINFIFO: WAITING_TID_QUEUES: Pending list: 8 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x47] 66 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x47] Total 2 Kernel Free SCB list: 53 94 52 127 115 73 21 114 63 37 22 117 93 92 64 1 41 88 43 121 68 50 91 46 122 56 80 30 104 116 34 48 7 105 3 39 58 81 112 119 28 27 62 4 17 120 24 103 0 49 101 106 32 47 75 69 11 95 42 65 96 14 67 72 89 108 13 36 125 44 51 71 20 54 38 90 82 85 31 59 76 60 6 97 33 5 124 16 25 111 18 15 19 87 107 23 123 99 110 10 84 29 100 74 55 118 40 9 126 113 12 61 77 98 79 109 2 78 102 57 70 35 83 45 86 26 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: scsi1: FIFO0 Active, LONGJMP == 0x232, SCB 0x42 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x8]:(HDMAEN) DFSTATUS[0xc9]:(FIFOEMP|HDONE|PKT_PRELOAD_AVAIL|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x78] SG_STATE[0x3]:(SEGS_AVAIL|LOADING_NEEDED) DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x6]:(DATAINFIFO|DLZERO) SHADDR = 0x048b4000, SHCNT = 0x0 HADDR = 0x048b4000, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) scsi1: FIFO1 Free, LONGJMP == 0x8063, SCB 0x3 SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x0] LQIN: 0x4 0x0 0x0 0x42 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x28 0x0 0x0 0x0 0x2 0x0 scsi1: LQISTATE = 0x2b, LQOSTATE = 0x0, OPTIONMODE = 0x52 scsi1: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x0] scsi1: REG0 == 0x42, SINDEX = 0x178, DINDEX = 0x10a scsi1: SCBPTR == 0x35, SCB_NEXT == 0xff00, SCB_NEXT2 == 0xff39 CDB 28 0 c 80 70 a4 STACK: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 Dump Card State Ends DevQ(0:4:0): 0 waiting DevQ(0:5:0): 0 waiting DevQ(0:14:0): 0 waiting DevQ(0:15:0): 0 waiting LQICRC_NLQ eth0: Optical link DOWN eth0: Optical link UP (Full Duplex, Flow Control: TX RX) scsi1: Unexpected PKT busfree condition Dump Card State Begins scsi1: Dumping Card State at program address 0x11 Mode 0x33 Card was paused HS_MAILBOX[0x0] INTCTL[0xc0]:(SWTMINTEN|SWTMINTMASK) SEQINTSTAT[0x10]:(SEQ_SWTMRTO) SAVED_MODE[0x11] DFFSTAT[0x24]:(CURRFIFO_0|FIFO1FREE) SCSISIGI[0xb6]:(P_MESGOUT|REQI|BSYI|ATNI) SCSIPHASE[0x4]:(MSG_OUT_PHASE) SCSIBUS[0xff] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x0] SEQINTCTL[0x0] SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] SSTAT0[0x2]:(SPIORDY)
Re: Oops in 2.6.13-rc5-git-current (0d317fb72fe3cf0f611608cf3a3015bbe6cd2a66)
On Sat, Aug 06, 2005 at 11:56:30PM -0400 Ryan Anderson wrote:
Unable to handle kernel paging request at virtual address 6b6b6b6b
printing eip:
c0188d15
*pde =
Oops: [#1]
PREEMPT
Modules linked in: ppp_deflate bsd_comp ppp_async ppp_generic slhc radeon
esp6 ah6 wp512 tgr192 tea khazad michael_mic cast6 cast5 arc4 anubis nfsd
exportfs lp binfmt_misc ipv6 tsdev evdev analog parport_pc parport 8250_pnp
8250 serial_core via_agp serpent aes_i586 crypto_null snd_via82xx gameport
snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc
snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore uhci_hcd via_ircc
irda dm_mod r8169 raid5 xor tulip via drm agpgart cpuid smbfs usbkbd usbcore
trm290 triflex sc1200 ns87415 it821x cy82c693 cs5530 cs5520 atiixp raid1
md_mod
CPU:0
EIP:0060:[inotify_inode_queue_event+85/336]Not tainted VLI
EFLAGS: 00010206 (2.6.13-rc5-g0d317fb7)
EIP is at inotify_inode_queue_event+0x55/0x150
eax: 6b6b6b6b ebx: 6b6b6b63 ecx: edx: 0066
esi: c3effe34 edi: ce8c76ac ebp: d4bb864c esp: d8655eb0
ds: 007b es: 007b ss: 0068
Process nfsd (pid: 3750, threadinfo=d8654000 task=d6155020)
Stack: 0286 0286 0400 d4bb8760 d4bb8768
c3effe34
ce8c76ac d4bb864c c0170626 c3effe34 d6608ad4 db74b17c
c3effe34
e0cfe9a4 0013 e0d01b34 c0dd91b4 ce8c76ac c000 d66092dc
d66093c4
Call Trace:
[vfs_unlink+358/560] vfs_unlink+0x166/0x230
[pg0+544348580/1067586560] nfsd_unlink+0x104/0x230 [nfsd]
[pg0+544361268/1067586560] nfsd_cache_lookup+0x1c4/0x3c0 [nfsd]
[pg0+544371728/1067586560] nfsd3_proc_remove+0x80/0xc0 [nfsd]
[pg0+544381018/1067586560] nfs3svc_decode_diropargs+0x8a/0x100 [nfsd]
[pg0+544380880/1067586560] nfs3svc_decode_diropargs+0x0/0x100 [nfsd]
[pg0+544321698/1067586560] nfsd_dispatch+0x82/0x1f0 [nfsd]
[svc_authenticate+112/336] svc_authenticate+0x70/0x150
[svc_process+960/1648] svc_process+0x3c0/0x670
[pg0+544323105/1067586560] nfsd+0x1a1/0x350 [nfsd]
[ret_from_fork+6/20] ret_from_fork+0x6/0x14
[pg0+544322688/1067586560] nfsd+0x0/0x350 [nfsd]
[kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10
(the long-aged vfs veteran steps into the picture...)
It looks like the following sequence is done in the wrong order.
When vfs_unlink() is called from sys_unlink() it has taken a ref
on the inode and sys_unlink() does the last iput() but when called
from other callsites vfs_unlink() might do the last iput()
Can you reproduce with this patch? It should happen with some nfs
activity, I'll try to set up a scenario myself.
Index: mm/fs/namei.c
===
--- mm.orig/fs/namei.c 2005-08-07 12:06:16.0 +0200
+++ mm/fs/namei.c 2005-08-07 18:17:20.0 +0200
@@ -1869,8 +1869,8 @@
/* We don't d_delete() NFS sillyrenamed files--they still exist. */
if (!error !(dentry-d_flags DCACHE_NFSFS_RENAMED)) {
struct inode *inode = dentry-d_inode;
- d_delete(dentry);
fsnotify_unlink(dentry, inode, dir);
+ d_delete(dentry);
}
return error;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.13-rc4-mm1: iptables DROP crashes the computer
After execing iptables -A INPUT -j DROP my computer crashes hard. It dosent hang immediately, but after a couple of seconds. The machine is an amd64, running a clean x86_64 environment. uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44 CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux lspci: :00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge (rev 01) :00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] :00:09.0 Multimedia audio controller: Creative Labs SB Audigy (rev 04) :00:09.1 Input device controller: Creative Labs SB Audigy MIDI/Game port (rev 04) :00:09.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port (rev 04) :00:0a.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) :00:0e.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) :00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) :00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) :00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] :00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration :00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map :00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller :00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control :01:00.0 VGA compatible controller: ATI Technologies Inc R420 JK [Radeon X800] :01:00.1 Display controller: ATI Technologies Inc: Unknown device 4a6b .config is attached. -- Mvh / Best regards Espen Fjellvær Olsen [EMAIL PROTECTED] Norway .config Description: Binary data
Re: assertion (cnt = tp-packets_out) failed
John Bäckstrand [EMAIL PROTECTED] wrote: Someone asked if I could try to trigger this assertion again, and I'm afraid I probably cannot, I didnt do anything special at the time. But I've got something even better for you all, got a BUG from something tcp-related. Mind you, I am trying to find a possibly hardware-related issue here, so if this bug does not make any sense it might be my hardware! I would actually want to know it if this is likely hardware-related or not, since I have no idea if its RAM, CPU, motherboard or only a disk that is broken. I know _something_ is broken, due to lockups, and seeing a faulty disk indicated in a HDD diag, but only once, the disk is apparently fine 99% of the time. --- John Bäckstrand [148475.651000] [ cut here ] [148475.651050] kernel BUG at net/ipv4/tcp_output.c:918! I think we've seen a couple of reports of this. [148475.651078] invalid operand: [#1] [148475.651103] Modules linked in: sha256 aes_i586 dm_crypt ipt_state ipt_multiport ipt_MASQUERADE iptable_filter netconsole md5 ipv6 af_packet pdc202xx_new e1000 8139cp de2104x i2c_viapro via686a i2c_sensor i2c_core uhci_hcd usbcore 3c59x 8139too mii de4x5 crc32 parport_pc parport reiserfs dm_mod ip_nat_ftp iptable_nat ip_tables ip_conntrack_ftp ip_conntrack rtc unix [148475.651378] CPU:0 [148475.651380] EIP:0060:[c0286619]Not tainted VLI [148475.651383] EFLAGS: 00010287 (2.6.13-rc5sand4) Can you tell us exactly which kernel this is based on? If it's 2.6.13-rc5 then it would be better to be testing 2.6.13-rc5-gitlatest, because some net fixes have been recently merged. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc4-mm1: iptables DROP crashes the computer
On Sun, Aug 07, 2005 at 07:12:00PM +0200, Espen Fjellvær Olsen wrote: After execing iptables -A INPUT -j DROP my computer crashes hard. It dosent hang immediately, but after a couple of seconds. The machine is an amd64, running a clean x86_64 environment. uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44 CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD ... Is this reproducible or did it happen only once? Are there any messages that might give a hint where to search for the problem? You are reporting this against 2.6.13-rc4-mm1, but are attaching a .config of 2.6.13-rc5-mm1. Which kernels are affected, and which are not? Does it still happen if you compile your kernel with preemption disabled? Please send the output of ./scripts/ver_linux . Mvh / Best regards Espen Fjellvær Olsen 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/
Re: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Sun, 7 Aug 2005, Kyle Moffett wrote: On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote: Ah ! Interesting... I don't see why PREEMPT would affect radeonfb though ... Can you try something like wrapper radeon_write_mode() with preempt_disable()/preempt_enable() and tell me if it makes a difference ? Did not help. The values used to initialize the mode seem to be wrong. Copying the aty directory from 2.6.12 did not help, too. -- Never tell the Platoon Sergeant you have nothing to do. -Unknown Marine Recruit - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc5-mm1: oops when starting nscd on AMD64
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
I get the following Oops after trying to start nscd from YaST on an
Athlon64-based box
(compiled with CONFIG_DEBUG_SPINLOCK=y):
Unable to handle kernel NULL pointer dereference at 0008 RIP:
801664d8{kmem_cache_alloc+232}
PGD 1501a067 PUD 1501b067 PMD 0
Oops: [1] PREEMPT
CPU 0
Modules linked in: raw af_key usbserial thermal processor fan button battery
ac snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97t
Pid: 6570, comm: nscd Not tainted 2.6.13-rc5-mm1
RIP: 0010:[801664d8] 801664d8{kmem_cache_alloc+232}
RSP: 0018:81001506de88 EFLAGS: 00010202
RAX: RBX: 8010eb3e RCX:
RDX: RSI: 8100292bdd68 RDI: 810001c3f6c0
RBP: 81001506deb8 R08: R09: 8100292bdd70
R10: 0006 R11: R12: 810001c3f6c0
R13: 8100292bdd68 R14: 80d0 R15: 801abe5c
FS: 2b11cb00() GS:804f2840() knlGS:56abc320
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0008 CR3: 15019000 CR4: 06e0
Process nscd (pid: 6570, threadinfo 81001506c000, task 81001506b250)
Stack: 0246 81001569b5a0 8100155fe980
fff4 000a 81001506df78 801abe5c
40a05fff 81001569b5a0
Call Trace:801abe5c{sys_epoll_create+604}
80243579{add_preempt_count+105}
8010eb3e{system_call+126}
BUG: spinlock trylock failure on UP on CPU#0, nscd/6570
lock: 803bae80, .magic: dead4ead, .owner: nscd/6570, .owner_cpu: 0
Call Trace:80243579{add_preempt_count+105}
802431a3{spin_bug+211}
8011004b{show_trace+571}
8024328e{_raw_spin_trylock+62}
8035270e{_spin_trylock+30} 8010fc81{oops_begin+17}
803538ea{do_page_fault+1722} 801343de{vprintk+830}
801343de{vprintk+830}
801521f6{kallsyms_lookup+246}
8010f431{error_exit+0} 8011004b{show_trace+571}
80110047{show_trace+567} 80110168{show_stack+216}
80110207{show_registers+135} 8011050e{__die+142}
80353958{do_page_fault+1832}
802410c1{vsnprintf+1393}
801abe5c{sys_epoll_create+604}
8010f431{error_exit+0}
801abe5c{sys_epoll_create+604}
8010eb3e{system_call+126}
801664d8{kmem_cache_alloc+232}
801664c8{kmem_cache_alloc+216}
801abe5c{sys_epoll_create+604}
80243579{add_preempt_count+105}
8010eb3e{system_call+126}
---
| preempt count: 0002 ]
| 2 level deep critical section nesting:
.. [80352706] _spin_trylock+0x16/0x60
.[8010fc81] .. ( = oops_begin+0x11/0x60)
.. [80352706] _spin_trylock+0x16/0x60
.[8010fc81] .. ( = oops_begin+0x11/0x60)
I don't think it was supposed to do that.
Quite possibly it's something to do with the new debugging code - could you
please take a copy of the offending config, send it over and then try
removing debug options, see if the crash goes away? CONFIG_DEBUG_PREEMPT
would be the first to try..
Thanks.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc4-mm1: iptables DROP crashes the computer
On 07/08/05, Adrian Bunk [EMAIL PROTECTED] wrote: On Sun, Aug 07, 2005 at 07:12:00PM +0200, Espen Fjellvær Olsen wrote: After execing iptables -A INPUT -j DROP my computer crashes hard. It dosent hang immediately, but after a couple of seconds. The machine is an amd64, running a clean x86_64 environment. uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44 CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD ... Is this reproducible or did it happen only once? It is reproducible, happens each time when running iptables -A INPUT -j DROP, other rules like iptables -A INPUT -m --state ESTABLISHED,RELATED -p tcp --dport 22 -j ACCEPT works well tho. Are there any messages that might give a hint where to search for the problem? The kernel log dont give any messages before the crash, and since the computer crash hard i cant check for relevant messages after the crash ;) You are reporting this against 2.6.13-rc4-mm1, but are attaching a .config of 2.6.13-rc5-mm1. Which kernels are affected, and which are not? Im sorry about that glitch, recently compiled 2.6.13-rc5-mm1, but i got a kernel panic at boot, havent looked into that yet, but it might be related to ACPI. The config for rc4-mm1 and rc5-mm1 is similar. Does it still happen if you compile your kernel with preemption disabled? Havent tried this yet, but ill do it right away. Please send the output of ./scripts/ver_linux . If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44 CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux Gnu C 3.4.4 Gnu make 3.80 binutils 2.16.1 util-linux 2.12q mount 2.12q module-init-tools 3.2-pre7 e2fsprogs 1.38 reiserfsprogs line reiser4progs line xfsprogs 2.6.25 Linux C Library2.3.5 Dynamic linker (ldd) 2.3.5 Procps 3.2.5 Net-tools 1.60 Kbd1.12 Sh-utils 5.2.1 udev 065 Modules Loaded iptable_filter ip_tables snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_pcm_oss snd_mixer_oss rtc ntfs snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore usb_storage uhci_hcd usbcore -- Mvh / Best regards Espen Fjellvær Olsen [EMAIL PROTECTED] Norway - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: any update on the pcmcia bug blocking Audigy2 notebook sound card driver development
Raymond Lai [EMAIL PROTECTED] wrote: Hi all, I remember there's a kernel pcmcia bug preventing the development for the Audigy2 pcmcia notebook sound card driver. See http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-Creative_Labs#matrix Is there any new updates on the situation? Has the bug been fixed? or anyone working on it? Is it related to http://bugzilla.kernel.org/show_bug.cgi?id=4788 ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lost Ticks on x86_64
On Sun, Aug 07, 2005 at 01:36:01PM +0200, Andi Kleen wrote: Erick Turnquist [EMAIL PROTECTED] writes: Hi, I'm running an Athlon64 X2 4400+ (a dual core model) with an nVidia GeForce 6800 Ultra on a Gigabyte GA-K8NXP-SLI motherboard and getting nasty messages like these in my dmesg: warning: many lost ticks. Your time source seems to be instable or some driver is hogging interupts rip default_idle+0x20/0x30 It's most likely bad SMM code in the BIOS that blocks the CPU too long and is triggered in idle. You can verify that by using idle=poll (not recommended for production, just for testing) and see if it goes away. No way to fix this, but you can work around it with very new kernels by compiling with a lower HZ than 1000. Some BIOSes do not lock SMM, and you *could* turn it off at the chipset level. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA Rhine ethernet driver bug (reprise)
Hello, In january of this year I mentioned a problem with the Linux kernel driver for VIA Rhine ethernet chips. (see http://lkml.org/lkml/2005/1/15/47) In the mean time this bug was reproduced quite a number of times on my Fedora Core 3 (then)/4 (now) box (a VIA CL6000). An alternative driver by VIA was used (with kernel 2.6.1x, http://www.viaarena.com/downloads/Source/rhinefet.tgz); this VIA driver did not have the Oversized ethernet frame bug but consumes quite a lot of CPU when transfering a steady stream of a few 1000 KB/S, so it is no good solution. Since the ethernet connection goes down due to this bug I think I can mark the bug as critical. The bug is still present in 2.6.12. The maintainer of the driver cannot fix the bug. Who can? Please post here and/or email me with your thoughts about a solution, ways of fixing the bug. Would a small reward help? Kind regards, Udo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.13-rc5-git-current (0d317fb72fe3cf0f611608cf3a3015bbe6cd2a66)
(Snipping the oops down a bit in size) On Sun, Aug 07, 2005 at 07:08:05PM +0200, Alexander Nyberg wrote: On Sat, Aug 06, 2005 at 11:56:30PM -0400 Ryan Anderson wrote: Unable to handle kernel paging request at virtual address 6b6b6b6b EIP is at inotify_inode_queue_event+0x55/0x150 Call Trace: [vfs_unlink+358/560] vfs_unlink+0x166/0x230 [pg0+544348580/1067586560] nfsd_unlink+0x104/0x230 [nfsd] [pg0+544361268/1067586560] nfsd_cache_lookup+0x1c4/0x3c0 [nfsd] [pg0+544371728/1067586560] nfsd3_proc_remove+0x80/0xc0 [nfsd] [pg0+544381018/1067586560] nfs3svc_decode_diropargs+0x8a/0x100 [nfsd] [pg0+544380880/1067586560] nfs3svc_decode_diropargs+0x0/0x100 [nfsd] [pg0+544321698/1067586560] nfsd_dispatch+0x82/0x1f0 [nfsd] [svc_authenticate+112/336] svc_authenticate+0x70/0x150 [svc_process+960/1648] svc_process+0x3c0/0x670 [pg0+544323105/1067586560] nfsd+0x1a1/0x350 [nfsd] [ret_from_fork+6/20] ret_from_fork+0x6/0x14 [pg0+544322688/1067586560] nfsd+0x0/0x350 [nfsd] [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10 (the long-aged vfs veteran steps into the picture...) It looks like the following sequence is done in the wrong order. When vfs_unlink() is called from sys_unlink() it has taken a ref on the inode and sys_unlink() does the last iput() but when called from other callsites vfs_unlink() might do the last iput() Can you reproduce with this patch? It should happen with some nfs activity, I'll try to set up a scenario myself. I'll try after I get a new hard drive in and let the RAID rebuild. It seems like a very big coincidence that this happened *right* as a drive was failing though - or is that just a bizarre coincidence? -- 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/
EXPORT_SYMBOL generates is deprecated noise
I'm getting lots of errors like this nowadays: drivers/serial/8250.c:2651: warning: `register_serial' is deprecated (declared at drivers/serial/8250.c:2607) Which is just: EXPORT_SYMBOL(register_serial); Sorry, but that's just compile-time noise, not anything useful. Warning on real usages of it might be handy (we can go fix the users) but not EXPORT_SYMBOL - we can't kill the export until the function goes away. The more noise we have, the harder it is to see real errors and warnings. I took a quick poke around, but can't see what generates this stuff. What is doing these checks, and can we please make an exception for EXPORT_SYMBOL (and EXPORT_SYMBOL_GPL) somehow? 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/
Re: Fw: Re: Elitegroup K7S5A + usb_storage problem
On Sun, 7 Aug 2005 [EMAIL PROTECTED] wrote: Hi Alan, no. the stick doesn't have a write protection switch. Once when i tried to copy a file to the mp3 player i got a new file there on remount, but it consisted of incorrect data. (so writing seemed to be possible and just went wrong) (in that case the fat seemed to be damaged after i had tried this, so that windows wasn't able to read it correctly any more. (formatting from the mp3 players menu helped) Well, perhaps the device isn't consistently writing data to the correct locations. greetings Martin PS: just as an info - i sent a usbmon trace to Pete Zaitcev today, should I send it to you too? Pete is quite as competent at solving this kind of problem as I am. And he knows the ub driver much better, so I'm happy to bow out and let him worry about it! :-) Just out of curiosity, if you plug the player into a Windows system without installing any special drivers first, will Windows be able to read and write files okay? If it can, a USB packet trace may give Pete a clue as to where to look. Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXPORT_SYMBOL generates is deprecated noise
On Sun, Aug 07, 2005 at 11:07:59AM -0700, Martin J. Bligh wrote: I'm getting lots of errors like this nowadays: drivers/serial/8250.c:2651: warning: `register_serial' is deprecated (declared at drivers/serial/8250.c:2607) Which is just: EXPORT_SYMBOL(register_serial); Sorry, but that's just compile-time noise, not anything useful. Warning on real usages of it might be handy (we can go fix the users) but not EXPORT_SYMBOL - we can't kill the export until the function goes away. The more noise we have, the harder it is to see real errors and warnings. I took a quick poke around, but can't see what generates this stuff. What is doing these checks, and can we please make an exception for EXPORT_SYMBOL (and EXPORT_SYMBOL_GPL) somehow? This is generated by the __deprecated marker (#define'd to __attribute__((deprecated)) ) at the prototype in include/linux/serial.h. You could somehow #ifdef the warning away, but IMHO this would be more ugly than living with the warning until the last user is gone. M. 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/
Re: EXPORT_SYMBOL generates is deprecated noise
--Martin J. Bligh [EMAIL PROTECTED] wrote (on Sunday, August 07, 2005 11:07:59 -0700): I'm getting lots of errors like this nowadays: drivers/serial/8250.c:2651: warning: `register_serial' is deprecated (declared at drivers/serial/8250.c:2607) Which is just: EXPORT_SYMBOL(register_serial); Sorry, but that's just compile-time noise, not anything useful. Warning on real usages of it might be handy (we can go fix the users) but not EXPORT_SYMBOL - we can't kill the export until the function goes away. The more noise we have, the harder it is to see real errors and warnings. I took a quick poke around, but can't see what generates this stuff. What is doing these checks, and can we please make an exception for EXPORT_SYMBOL (and EXPORT_SYMBOL_GPL) somehow? Oh, I'm being an idiot and looking at the wrong tree. It's __deprecated, but I still can't think of a clean way to locally undefine that for just EXPORT_SYMBOL. 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/
Re: 2.6.13-rc4-mm1: iptables DROP crashes the computer
Adrian Bunk wrote:
On Sun, Aug 07, 2005 at 07:12:00PM +0200, Espen Fjellvær Olsen wrote:
After execing iptables -A INPUT -j DROP my computer crashes hard. It
dosent hang immediately, but after a couple of seconds.
The machine is an amd64, running a clean x86_64 environment.
uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44
CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD
...
Could be related to the refcnt underflow with conntrack event
notifications enabled. If you have CONFIG_IP_NF_CONNTRACK_EVENTS
enabled please try this patch.
[NETFILTER]: Fix multiple problems with the conntrack event cache
refcnt underflow: the reference count is decremented when a conntrack
entry is removed from the hash but it is not incremented when entering
new entries.
missing protection of process context against softirq context: all
cache operations need to locally disable softirqs to avoid races.
Additionally the event cache can't be initialized when a packet enteres
the conntrack code but needs to be initialized whenever we cache an event
and the stored conntrack entry doesn't match the current one.
incorrect flushing of the event cache in ip_ct_iterate_cleanup: without
real locking we can't flush the cache for different CPUs without incurring
races. The cache for different CPUs can only be flushed when no packets
are going through the code. ip_ct_iterate_cleanup doesn't need to drop
all references, so flushing is moved to the cleanup path.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit d20d18715b8425060334e879ebb4835202457b3e
tree 3279243f59162c14f8ac145473e1c3f4c586b2fa
parent df2e0392536ecdd6385f4319f746045fd6fae38f
author Patrick McHardy [EMAIL PROTECTED] Wed, 03 Aug 2005 20:33:25 +0200
committer Patrick McHardy [EMAIL PROTECTED] Wed, 03 Aug 2005 20:33:25 +0200
include/linux/netfilter_ipv4/ip_conntrack.h | 29 +++---
include/linux/netfilter_ipv4/ip_conntrack_core.h | 14 +--
net/ipv4/netfilter/ip_conntrack_core.c | 107 --
net/ipv4/netfilter/ip_conntrack_standalone.c |3 -
4 files changed, 58 insertions(+), 95 deletions(-)
diff --git a/include/linux/netfilter_ipv4/ip_conntrack.h
b/include/linux/netfilter_ipv4/ip_conntrack.h
--- a/include/linux/netfilter_ipv4/ip_conntrack.h
+++ b/include/linux/netfilter_ipv4/ip_conntrack.h
@@ -411,6 +411,7 @@ struct ip_conntrack_stat
#ifdef CONFIG_IP_NF_CONNTRACK_EVENTS
#include linux/notifier.h
+#include linux/interrupt.h
struct ip_conntrack_ecache {
struct ip_conntrack *ct;
@@ -445,26 +446,24 @@ ip_conntrack_expect_unregister_notifier(
return notifier_chain_unregister(ip_conntrack_expect_chain, nb);
}
+extern void ip_ct_deliver_cached_events(const struct ip_conntrack *ct);
+extern void __ip_ct_event_cache_init(struct ip_conntrack *ct);
+
static inline void
ip_conntrack_event_cache(enum ip_conntrack_events event,
const struct sk_buff *skb)
{
- struct ip_conntrack_ecache *ecache =
- __get_cpu_var(ip_conntrack_ecache);
-
- if (unlikely((struct ip_conntrack *) skb-nfct != ecache-ct)) {
- if (net_ratelimit()) {
- printk(KERN_ERR ctevent: skb-ct != ecache-ct !!!\n);
- dump_stack();
- }
- }
+ struct ip_conntrack *ct = (struct ip_conntrack *)skb-nfct;
+ struct ip_conntrack_ecache *ecache;
+
+ local_bh_disable();
+ ecache = __get_cpu_var(ip_conntrack_ecache);
+ if (ct != ecache-ct)
+ __ip_ct_event_cache_init(ct);
ecache-events |= event;
+ local_bh_enable();
}
-extern void
-ip_conntrack_deliver_cached_events_for(const struct ip_conntrack *ct);
-extern void ip_conntrack_event_cache_init(const struct sk_buff *skb);
-
static inline void ip_conntrack_event(enum ip_conntrack_events event,
struct ip_conntrack *ct)
{
@@ -483,9 +482,7 @@ static inline void ip_conntrack_event_ca
const struct sk_buff *skb) {}
static inline void ip_conntrack_event(enum ip_conntrack_events event,
struct ip_conntrack *ct) {}
-static inline void ip_conntrack_deliver_cached_events_for(
- struct ip_conntrack *ct) {}
-static inline void ip_conntrack_event_cache_init(const struct sk_buff *skb) {}
+static inline void ip_ct_deliver_cached_events(const struct ip_conntrack *ct)
{}
static inline void
ip_conntrack_expect_event(enum ip_conntrack_expect_events event,
struct ip_conntrack_expect *exp) {}
diff --git a/include/linux/netfilter_ipv4/ip_conntrack_core.h
b/include/linux/netfilter_ipv4/ip_conntrack_core.h
--- a/include/linux/netfilter_ipv4/ip_conntrack_core.h
+++ b/include/linux/netfilter_ipv4/ip_conntrack_core.h
@@ -44,18 +44,14 @@ static inline int ip_conntrack_confirm(s
Re: [Alsa-devel] Re: any update on the pcmcia bug blocking Audigy2 notebook sound card driver development
On Sun, 2005-08-07 at 10:43 -0700, Andrew Morton wrote: Raymond Lai [EMAIL PROTECTED] wrote: Hi all, I remember there's a kernel pcmcia bug preventing the development for the Audigy2 pcmcia notebook sound card driver. See http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-Creative_Labs#matrix Is there any new updates on the situation? Has the bug been fixed? or anyone working on it? Is it related to http://bugzilla.kernel.org/show_bug.cgi?id=4788 ? No, that was a known issue that is resolved in 2.6.13-rc*. This is the bug he's referring to: http://lkml.org/lkml/2005/7/11/265 Looks like James never followed up, probably due to OLS. 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: Lost Ticks on x86_64
Some BIOSes do not lock SMM, and you *could* turn it off at the chipset level. I don't see anything about SMM in my BIOS configuration even with the advanced options enabled... Turning it off at the chipset level sounds like a hardware hack - is it? The gettimeofday patch for 2.6.13-rc3 won't apply. My source tree has no ntp.h or ntp.c, and I get a malformed patch error at line 560. I'm using the patch Google found for me: http://lwn.net/Articles/143953/ on a 2.6.13-rc3 source tree. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.6.13-rc6: aic7xxx testers please..
James and gang found the aic7xxx slowdown that happened after 2.6.12, and we'd like to get particular testing that it's fixed, so if you have a relevant machine, please do test this. There are other fixes too, a number of them reverting (at least for now) patches that people had problems with. In general, anybody who has reported regressions since 2.6.12, please re-test with -rc6 and report back (even if, or perhaps _particularly_ if, no change to the regression). Apart from some reverts and the aic7xxx performance regression fix, there's arm and ppc updates, and some PCI resource allocation updates that hopefully will reduce the number of machines (especially laptopns) that have strange undocumented MB devices that clash in PCI IO space.. And various small one-liners. The appended shortlog/diffstat gives more some more specific insight.. Linus --- shortlog --- Alasdair G Kergon: dm-raid locking fix Alexander Nyberg: x86-64: use proper VM_FAULT_xxx macros Alexey Starikovskiy: [ACPI] restore /proc/acpi/button/ (ala 2.6.12) Andi Kleen: x86_64: ignore machine checks from boot time Andrew Morton: [SCSI] fc4 warning fix revert timer exit cleanup REPORTING-BUGS: track regressions __bio_clone() dead comment Aristeu Sergio Rozanski Filho: ppc32: 8xx: convert fec driver to use work_struct ppc32: 8xx: using dma_alloc_coherent() instead consistent_alloc() ppc32: 8xx: fec: fix interrupt handler prototypes ppc32: 8xx fix CPM ethernet description ppc32: 8xx restrict ENET_BIG_BUFFERS option ppc32: 8xx kill unused variable in commproc Ben Dooks: ARM: 2832/1: BAST - limit clock-rate for IIC bus Benjamin Herrenschmidt: Remove suspend() calls from shutdown path Catalin Marinas: ARM: 2841/1: Fix VFP +/-0 case for doubles addition Christoph Hellwig: [SPARC]: Fix up sleep_on() removal in vfc driver. Daniel Jacobowitz: x86_64: fix 32-bit thread debugging David Brownell: USB: ehci: microframe handling fix David Gibson: Fix hugepage crash on failing mmap() David Howells: Keys: Fix key management syscall interface bugs Error during attempt to join key management session can leave semaphore pinned Destruction of failed keyring oopses David S. Miller: tcp: fix TSO sizing bugs [IPV4]: Fix memory leak during fib_info hash expansion. David Shaohua Li: [ACPI] PCI interrupt link suspend/resume - revert to 2.6.12 behaviour [ACPI] S3 resume: avoid kmalloc() might_sleep oops symptom Deepak Saxena: ARM: 2839/1: Remove XScale cache and TLB locking code ARM: 2835/1: Add UPF_SKIP_TEST to IXP4xx serial ports Dominik Brodowski: pci and yenta: pcibios_bus_to_resource Dominik Hackl: crc32.c typo fix Eric W. Biederman: i386 voyager: Add machine_shutdown i386 visws: Add machine_shutdown and emergency_restart x86_64 bootmem: sparse_mem/kexec merge bug. Hal Rosenstock: [IPoIB] Handle sending of unicast RARP responses Haren Myneni: Xmon bug fix for soft-reset Herbert Xu: tcp: fix TSO cwnd caching bug Hugh Dickins: fix VmSize and VmData after mremap Ian Campbell: ARM: 2833/2: Remove support for WDIOF_MAGICCLOSE from sa1100-wdt Ingo Molnar: Fix semundo lock leakage Ivan Kokshaysky: increase PCIBIOS_MIN_IO on x86 ACPI: increase PCIBIOS_MIN_IO on x86 Fix restore of 64-bit PCI BAR's Jack Hammer: [SCSI] ServeRAID V7.12.02 James Bottomley: [SCSI] aic7xxx: fix bug in DT handing [SCSI] aic7xxx: final fixes for DT handling [SCSI] fix aic7xxx performance issues since 2.6.12-rc2 fix voyager compile after machine_emergency_restart breakage Jens Axboe: cfq-iosched: fix problem with barriers and max_depth == 1 Jim Keniston: Add Documentation/kprobes.txt John McCutchan: inotify delete race fix Clean up inotify delete race fix John W. Linville: PCI: restore BAR values after D3hot-D0 for devices that need it Kai Makisara: [SCSI] Fix SCSI tape oops at module removal Len Brown: [ACPI] fix 64-bit build warning in processor_idle.c /home/lenb/src/to-linus branch 'acpi-2.6.12' [ACPI] delete Warning: Encountered executable code at module level, [AE_NOT_CONFIGURED] /home/lenb/src/to-linus-stable branch 'acpi-2.6.12' Merge ../to-linus-stable Linda Xie: [SCSI] scsi/ibmvscsi/srp.h: Fix a wrong type code used for SRP_LOGIN_REJ Linus Torvalds: pci: make bus resource start address override minimum IO address Fix up recent get_user_pages() handling Merge master.kernel.org:/home/rmk/linux-2.6-arm Merge master.kernel.org:/.../lenb/to-linus It wasn't just x86-64 that had hardcoded VM_FAULT_xxx numbers Merge head 'for-linus' of master.kernel.org:/.../roland/infiniband Merge master.kernel.org:/home/rmk/linux-2.6-arm Merge master.kernel.org:/.../lenb/to-linus Merge master.kernel.org:/home/rmk/linux-2.6-arm Merge master.kernel.org:/.../jejb/scsi-for-linus-2.6 Merge master.kernel.org:/.../davem/sparc-2.6 Merge master.kernel.org:/.../davem/net-2.6 Add fakey 'deflateBound()' function
Re: Lost Ticks on x86_64
On Sun, 2005-08-07 at 13:36 +0200, Andi Kleen wrote: Erick Turnquist [EMAIL PROTECTED] writes: Hi, I'm running an Athlon64 X2 4400+ (a dual core model) with an nVidia GeForce 6800 Ultra on a Gigabyte GA-K8NXP-SLI motherboard and getting nasty messages like these in my dmesg: warning: many lost ticks. Your time source seems to be instable or some driver is hogging interupts rip default_idle+0x20/0x30 It's most likely bad SMM code in the BIOS that blocks the CPU too long and is triggered in idle. You can verify that by using idle=poll (not recommended for production, just for testing) and see if it goes away. WTF, since when do *desktops* use SMM? Are you telling me that we have to worry about these stupid ACPI/SMM hardware bugs on the desktop too? 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: 2.6.13-rc5-mm1
On 8/7/05, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc5/2.6.13-rc5-mm1/ I probably don't need/want phy stuff anyhow, but when I tried it: Problem: drivers/built-in.o: In function `phy_start_machine': : undefined reference to `phy_timer' drivers/built-in.o: In function `phy_stop_machine': : undefined reference to `phy_stop_interrupts' make: *** [.tmp_vmlinux1] Error 1 Config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.13-rc5-mm1 # Sun Aug 7 11:27:22 2005 # CONFIG_X86=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_PHYSICAL_START=0x10 # CONFIG_KEXEC is not set # # Performance-monitoring counters support # # CONFIG_PERFCTR is not set # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_DEBUG=y # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_SLEEP_PROC_SLEEP is not set # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=m CONFIG_ACPI_HOTKEY=y # CONFIG_ACPI_FAN is not set CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_DEBUG=y CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=y # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not
Re: Logitech Quickcam Express USB Address Aquisition Issues
On Sunday 07 Aug 2005 12:36, christos gentsis wrote: [snip] I searched up google a bit and recieved some warnings about acpi causing problems, so I disabled that, but was still unsucessful in getting that to work. Please let me know if any other information is required. Thanks ahead of time. Chris White does the drivers for the Phillips web cams come back to the kernel? because i thought that it was taken out... http://www.smcc.demon.nl/webcam/ check this site and see if your cam was one of the cams that supported from the driver that discontinue... so if is supported by this driver, download and install it... it works i try it with my cam ;) The in-kernel pwc driver doesn't work for me either. I highly recommend you try the above if this turns out to not be a hardware fault. -- Cheers, Alistair. 'No sense being pessimistic, it probably wouldn't work anyway.' Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] driver core: Add the ability to unbind drivers to devices from userspace
Hi! If we are going back to needing helper scripts then I should just remove the entire sysfs graphics interface and switch back to using ioctls and a helper app. Of could no one can ever find the helper app or remember how it works. I thought one of the main reasons behind the sysfs interface was to eliminate these helper apps. The point is that you _can_ do it with echo, not that it is _easy_. Nor is sysfs a solution in any case. Without doing whitespace cleanup there is a 100% probability that this will generate bug reports. I know this for a fact because I am already getting them. Stupid users are not a reason for kernel bloat. You have a very wrapped sense of kernel bloat. This is nine lines of code whose absence is guaranteed to generate a bunch of bug reports. Not having it is also causing various implementers to implement attribute processing differently. Some are stripping white space in their implementations and some are not. If you want to attack kernel Can you point place where we do strip whitespace in kernel sysfs handlers? 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] driver core: Add the ability to unbind drivers to devices from userspace
Hi! Could you tell me why you don't just fail the operation if malformed input is supplied? Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n. Please, NO! echo -n is the right thing to do, and users will eventually learn. We are not going to add such workarounds all over the kernel... It is not a work around. These are text attributes meant for human use. Humans have a hard time cleaning up things they can't see. And the failure mode for this is awful, your attribute won't set but everything on the screen looks fine. Kernel is not a place to be user friendly. Or do you propose stripping whitespace for open(), too? File called foo.txt certainly *is* going to be confusing, but it should be allowed at kernel level. Now... echo foo /sys/var does not properly report errors. Thats bad, but it needs to be fixed in bash. -- 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: EXPORT_SYMBOL generates is deprecated noise
--Adrian Bunk [EMAIL PROTECTED] wrote (on Sunday, August 07, 2005 20:23:12 +0200): On Sun, Aug 07, 2005 at 11:07:59AM -0700, Martin J. Bligh wrote: I'm getting lots of errors like this nowadays: drivers/serial/8250.c:2651: warning: `register_serial' is deprecated (declared at drivers/serial/8250.c:2607) Which is just: EXPORT_SYMBOL(register_serial); Sorry, but that's just compile-time noise, not anything useful. Warning on real usages of it might be handy (we can go fix the users) but not EXPORT_SYMBOL - we can't kill the export until the function goes away. The more noise we have, the harder it is to see real errors and warnings. I took a quick poke around, but can't see what generates this stuff. What is doing these checks, and can we please make an exception for EXPORT_SYMBOL (and EXPORT_SYMBOL_GPL) somehow? This is generated by the __deprecated marker (#define'd to __attribute__((deprecated)) ) at the prototype in include/linux/serial.h. You could somehow #ifdef the warning away, but IMHO this would be more ugly than living with the warning until the last user is gone. If it's going to spout crap when I'm not even using the deprecated function, it's worse than useless, I'm afraid. I tried some smart nested definitions to just wrap it inside EXPORT_SYMBOL, but the ordering of evaluation is all wrong. Bah ;-( 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/
Re: Logitech Quickcam Express USB Address Aquisition Issues
On Sunday 07 Aug 2005 19:54, Alistair John Strachan wrote: On Sunday 07 Aug 2005 12:36, christos gentsis wrote: [snip] I searched up google a bit and recieved some warnings about acpi causing problems, so I disabled that, but was still unsucessful in getting that to work. Please let me know if any other information is required. Thanks ahead of time. Chris White does the drivers for the Phillips web cams come back to the kernel? because i thought that it was taken out... http://www.smcc.demon.nl/webcam/ check this site and see if your cam was one of the cams that supported from the driver that discontinue... so if is supported by this driver, download and install it... it works i try it with my cam ;) The in-kernel pwc driver doesn't work for me either. I highly recommend you try the above if this turns out to not be a hardware fault. Sorry, I didn't even check the link. Try the driver from: http://www.saillard.org/linux/pwc/ Which seems to work better. -- Cheers, Alistair. 'No sense being pessimistic, it probably wouldn't work anyway.' Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FYI: device_suspend(...) in kernel_power_off().
Hi! There as been a fair amount of consensus that calling device_suspend(...) in the reboot path was inappropriate now, because the device suspend code was too immature. With this latest piece of evidence it seems to me that introducing device_suspend(...) in kernel_power_off, kernel_halt, kernel_reboot, or kernel_kexec can never be appropriate. Code is not ready now = it can never be fixed? Thats quite a strange conclusion to make. 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/
[PATCH] get rid of warning in aic7770.c:aic7770_config()
Get rid of unused variable warning:
drivers/scsi/aic7xxx/aic7770.c: In function `aic7770_config':
drivers/scsi/aic7xxx/aic7770.c:129: warning: unused variable `l'
Not used anywhere in the function, even under ifdef. Delete.
diff -aurpN -X /home/fletch/.diff.exclude virgin/drivers/scsi/aic7xxx/aic7770.c
aic_warning/drivers/scsi/aic7xxx/aic7770.c
--- virgin/drivers/scsi/aic7xxx/aic7770.c 2005-08-07 09:15:41.0
-0700
+++ aic_warning/drivers/scsi/aic7xxx/aic7770.c 2005-08-07 11:58:41.0
-0700
@@ -126,7 +126,6 @@ aic7770_find_device(uint32_t id)
int
aic7770_config(struct ahc_softc *ahc, struct aic7770_identity *entry, u_int io)
{
- u_long l;
int error;
int have_seeprom;
u_int hostconf;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] i386 Encapsulate copying of pgd entries
Hi! This helps complete the encapsulation of updates to page tables (or pages about to become page tables) into accessor functions rather than using memcpy() to duplicate them. This is both generally good for consistency and also necessary for running in a hypervisor which requires explicit updates to page table entries. Hmm, I'm not sure if this kind of hypervisor can reasonably work with swsusp; swsusp is just copying memory, it does not know which part of memory are page tables. 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: EXPORT_SYMBOL generates is deprecated noise
On Sun, Aug 07, 2005 at 11:55:16AM -0700, Martin J. Bligh wrote: --Adrian Bunk [EMAIL PROTECTED] wrote (on Sunday, August 07, 2005 20:23:12 +0200): On Sun, Aug 07, 2005 at 11:07:59AM -0700, Martin J. Bligh wrote: I'm getting lots of errors like this nowadays: drivers/serial/8250.c:2651: warning: `register_serial' is deprecated (declared at drivers/serial/8250.c:2607) Which is just: EXPORT_SYMBOL(register_serial); Sorry, but that's just compile-time noise, not anything useful. Warning on real usages of it might be handy (we can go fix the users) but not EXPORT_SYMBOL - we can't kill the export until the function goes away. The more noise we have, the harder it is to see real errors and warnings. I took a quick poke around, but can't see what generates this stuff. What is doing these checks, and can we please make an exception for EXPORT_SYMBOL (and EXPORT_SYMBOL_GPL) somehow? This is generated by the __deprecated marker (#define'd to __attribute__((deprecated)) ) at the prototype in include/linux/serial.h. You could somehow #ifdef the warning away, but IMHO this would be more ugly than living with the warning until the last user is gone. If it's going to spout crap when I'm not even using the deprecated function, it's worse than useless, I'm afraid. ... It's reminding us that we are still offering a deprecated function. ;-) M. 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/
Re: EXPORT_SYMBOL generates is deprecated noise
If it's going to spout crap when I'm not even using the deprecated function, it's worse than useless, I'm afraid. ... It's reminding us that we are still offering a deprecated function. ;-) Might be useful as an option. But not to irritate every poor sod who does a kernel compile, ever. 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/
Re: EXPORT_SYMBOL generates is deprecated noise
On Sun, Aug 07, 2005 at 11:07:59AM -0700, Martin J. Bligh wrote: I'm getting lots of errors like this nowadays: drivers/serial/8250.c:2651: warning: `register_serial' is deprecated (declared at drivers/serial/8250.c:2607) Which is just: EXPORT_SYMBOL(register_serial); Sorry, but that's just compile-time noise, not anything useful. Warning on real usages of it might be handy (we can go fix the users) but not EXPORT_SYMBOL - we can't kill the export until the function goes away. The more noise we have, the harder it is to see real errors and warnings. I don't know why I bother with __deprecated - I haven't seen much evidence of the users of these functions being cleaned up, so I think we might as well just delete the functions and _force_ people to fix their code. That unfortunately seems to be the only way to get things done in this day and age, which is rather sad if that's what it takes to kick people into action. -- 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/
[WATCHDOG] i8xx_tco.c - patch to arm watchdog only when started (Kernel Bug 4251)
Hi Linus,
Please add the following patch/bugfix:
i8xx_tco.c v0.08: only arm the watchdog when the watchdog has been started.
(Kernel Bug 4251: system reset when battery is read and i8xx_tco driver loaded)
Greetings,
Wim.
diff -Nru a/drivers/char/watchdog/i8xx_tco.c b/drivers/char/watchdog/i8xx_tco.c
--- a/drivers/char/watchdog/i8xx_tco.c 2005-08-07 20:33:01 +02:00
+++ b/drivers/char/watchdog/i8xx_tco.c 2005-08-07 20:41:25 +02:00
@@ -1,5 +1,5 @@
/*
- * i8xx_tco 0.07: TCO timer driver for i8xx chipsets
+ * i8xx_tco: TCO timer driver for i8xx chipsets
*
* (c) Copyright 2000 kernel concepts [EMAIL PROTECTED], All Rights
Reserved.
* http://www.kernelconcepts.de
@@ -63,6 +63,9 @@
* 20050128 Wim Van Sebroeck [EMAIL PROTECTED]
* 0.07 Added support for the ICH4-M, ICH6, ICH6R, ICH6-M, ICH6W and ICH6RW
* chipsets. Also added support for the undocumented ICH7 chipset.
+ * 20050807 Wim Van Sebroeck [EMAIL PROTECTED]
+ * 0.08 Make sure that the watchdog is only armed when started.
+ * (Kernel Bug 4251)
*/
/*
@@ -87,7 +90,7 @@
#include i8xx_tco.h
/* Module and version information */
-#define TCO_VERSION 0.07
+#define TCO_VERSION 0.08
#define TCO_MODULE_NAME i8xx TCO timer
#define TCO_DRIVER_NAME TCO_MODULE_NAME , v TCO_VERSION
#define PFX TCO_MODULE_NAME :
@@ -125,10 +128,18 @@
unsigned char val;
spin_lock(tco_lock);
+
+ /* disable chipset's NO_REBOOT bit */
+ pci_read_config_byte (i8xx_tco_pci, 0xd4, val);
+ val = 0xfd;
+ pci_write_config_byte (i8xx_tco_pci, 0xd4, val);
+
+ /* Bit 11: TCO Timer Halt - 0 = The TCO timer is enabled to count */
val = inb (TCO1_CNT + 1);
val = 0xf7;
outb (val, TCO1_CNT + 1);
val = inb (TCO1_CNT + 1);
+
spin_unlock(tco_lock);
if (val 0x08)
@@ -138,13 +149,20 @@
static int tco_timer_stop (void)
{
- unsigned char val;
+ unsigned char val, val1;
spin_lock(tco_lock);
+ /* Bit 11: TCO Timer Halt - 1 = The TCO timer is disabled */
val = inb (TCO1_CNT + 1);
val |= 0x08;
outb (val, TCO1_CNT + 1);
val = inb (TCO1_CNT + 1);
+
+ /* Set the NO_REBOOT bit to prevent later reboots, just for sure */
+ pci_read_config_byte (i8xx_tco_pci, 0xd4, val1);
+ val1 |= 0x02;
+ pci_write_config_byte (i8xx_tco_pci, 0xd4, val1);
+
spin_unlock(tco_lock);
if ((val 0x08) == 0)
@@ -155,6 +173,7 @@
static int tco_timer_keepalive (void)
{
spin_lock(tco_lock);
+ /* Reload the timer by writing to the TCO Timer Reload register */
outb (0x01, TCO1_RLD);
spin_unlock(tco_lock);
return 0;
@@ -417,9 +436,8 @@
printk (KERN_ERR PFX failed to get TCOBASE address\n);
return 0;
}
- /*
-* Check chipset's NO_REBOOT bit
-*/
+
+ /* Check chipset's NO_REBOOT bit */
pci_read_config_byte (i8xx_tco_pci, 0xd4, val1);
if (val1 0x02) {
val1 = 0xfd;
@@ -430,6 +448,10 @@
return 0; /* Cannot reset NO_REBOOT bit */
}
}
+ /* Disable reboots untill the watchdog starts */
+ val1 |= 0x02;
+ pci_write_config_byte (i8xx_tco_pci, 0xd4, val1);
+
/* Set the TCO_EN bit in SMI_EN register */
if (!request_region (SMI_EN + 1, 1, i8xx TCO)) {
printk (KERN_ERR PFX I/O address 0x%04x already in
use\n,
@@ -505,17 +527,10 @@
static void __exit watchdog_cleanup (void)
{
- u8 val;
-
/* Stop the timer before we leave */
if (!nowayout)
tco_timer_stop ();
- /* Set the NO_REBOOT bit to prevent later reboots, just for sure */
- pci_read_config_byte (i8xx_tco_pci, 0xd4, val);
- val |= 0x02;
- pci_write_config_byte (i8xx_tco_pci, 0xd4, val);
-
/* Deregister */
misc_deregister (i8xx_tco_miscdev);
unregister_reboot_notifier(i8xx_tco_notifier);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 warning about e1000_suspend
e1000_suspend is only used under #ifdef CONFIG_PM. Move the declaration
of it to be the same way, just like e1000_resume, otherwise gcc whines
on compile. I offer as evidence:
static struct pci_driver e1000_driver = {
.name = e1000_driver_name,
.id_table = e1000_pci_tbl,
.probe= e1000_probe,
.remove = __devexit_p(e1000_remove),
/* Power Managment Hooks */
#ifdef CONFIG_PM
.suspend = e1000_suspend,
.resume = e1000_resume
#endif
};
diff -aurpN -X /home/fletch/.diff.exclude virgin/drivers/net/e1000/e1000_main.c
e1000_suspend/drivers/net/e1000/e1000_main.c
--- virgin/drivers/net/e1000/e1000_main.c 2005-08-07 09:15:36.0
-0700
+++ e1000_suspend/drivers/net/e1000/e1000_main.c2005-08-07
12:10:42.0 -0700
@@ -162,8 +162,8 @@ static void e1000_vlan_rx_add_vid(struct
static void e1000_vlan_rx_kill_vid(struct net_device *netdev, uint16_t vid);
static void e1000_restore_vlan(struct e1000_adapter *adapter);
-static int e1000_suspend(struct pci_dev *pdev, uint32_t state);
#ifdef CONFIG_PM
+static int e1000_suspend(struct pci_dev *pdev, uint32_t state);
static int e1000_resume(struct pci_dev *pdev);
#endif
@@ -3641,6 +3641,7 @@ e1000_set_spd_dplx(struct e1000_adapter
return 0;
}
+#ifdef CONFIG_PM
static int
e1000_suspend(struct pci_dev *pdev, uint32_t state)
{
@@ -3733,7 +3734,6 @@ e1000_suspend(struct pci_dev *pdev, uint
return 0;
}
-#ifdef CONFIG_PM
static int
e1000_resume(struct pci_dev *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/
Re: [PATCH 1/1] i386 Encapsulate copying of pgd entries
Pavel Machek wrote:
Hi!
This helps complete the encapsulation of updates to page tables (or pages
about to become page tables) into accessor functions rather than using
memcpy() to duplicate them. This is both generally good for consistency
and also necessary for running in a hypervisor which requires explicit
updates to page table entries.
Hmm, I'm not sure if this kind of hypervisor can reasonably work with swsusp;
swsusp is just copying memory, it does not know which part of memory are page
tables.
Pavel
There are good and bad things about this. Everything with swap suspend
should be fine for the suspend portion of things; it is when resuming
back up that one must take care to call the hypervisor functions for
reloading control registers and updating page tables.
I'm not sure that Xen can cope with that scenario - it would have to go
into shadowed mode first, then after resume, go back from shadow mode
into direct page table mode. Otherwise, as you say, making swap suspend
aware of what pages are page tables would be quite difficult and
needlessly complicate the code.
Since most hypervisors will likely provide a suspend/resume mechanism
that is external to the guest, most of this is a moot point anyways.
But I wondered if you thought the pgd_clone() accessor would make this
cleaner or if it is just most confusing:
#ifdef CONFIG_SOFTWARE_SUSPEND
/*
* Swap suspend friends need this for resume because things like the
intel-agp
* driver might have split up a kernel 4MB mapping.
*/
char __nosavedata swsusp_pg_dir[PAGE_SIZE]
__attribute__ ((aligned (PAGE_SIZE)));
static inline void save_pg_dir(void)
{
memcpy(swsusp_pg_dir, swapper_pg_dir, PAGE_SIZE); --- could be
clone_pgd_range()
}
Zach
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Wireless support
Is the Linksys WUSB 54GS wireless adapter (FCCID Q87-WUSB54GS) supported? TIA, 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: [PATCH 1/1] i386 Encapsulate copying of pgd entries
Hi!
Since most hypervisors will likely provide a suspend/resume mechanism
that is external to the guest, most of this is a moot point anyways.
Ok.
But I wondered if you thought the pgd_clone() accessor would make this
cleaner or if it is just most confusing:
#ifdef CONFIG_SOFTWARE_SUSPEND
/*
* Swap suspend friends need this for resume because things like the
intel-agp
* driver might have split up a kernel 4MB mapping.
*/
char __nosavedata swsusp_pg_dir[PAGE_SIZE]
__attribute__ ((aligned (PAGE_SIZE)));
static inline void save_pg_dir(void)
{
memcpy(swsusp_pg_dir, swapper_pg_dir, PAGE_SIZE); --- could be
clone_pgd_range()
}
Yep, clone_pgd_range would make sense here...
Pavel
--
if you have sharp zaurus hardware you don't need... you know my address
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Wireless support
On Sun, 2005-08-07 at 15:22 -0400, Lee Revell wrote: Is the Linksys WUSB 54GS wireless adapter (FCCID Q87-WUSB54GS) supported? Wow, Google has really declined in quality. I got zero hits for Linksys WUSB 54G linux. Then I found this page on my own. (from http://ndiswrapper.sourceforge.net/mediawiki/index.php/List) Card: Linksys #[WUSB54G], 802.11b/g, USB 2.0 -- [link here|List#WUSB54G] * Chipset: Prism54 * usbid: 5041:2234 * Driver: Linksys Windows XP driver http://www.linksys.com/download/default.asp * Other: Works smoothly, of course ;) - this is the device the USB extension was originally developed for. WEP is running, WPA is supported using wpa_supplicant 0.2.5. No problems with both 1.1 and 2.0 host controllers. As with many other USB devices, no success with 2.4 kernels so far. Try to use 2.6.7 or better. There is a native driver for Prism54 that is working on USB support. View its status at Prism54.org Sorry for the WOB. And if anyone from Google is reading, WTF? 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: Lost Ticks on x86_64
On Sun, 7 Aug 2005, Lee Revell wrote: It's most likely bad SMM code in the BIOS that blocks the CPU too long and is triggered in idle. You can verify that by using idle=poll (not recommended for production, just for testing) and see if it goes away. WTF, since when do *desktops* use SMM? Are you telling me that we have to worry about these stupid ACPI/SMM hardware bugs on the desktop too? It's a general platform thing and has been around for ages now... Intel's ICH* definitely use it for example and those are on a lot of desktop systems. For example, turning on Legacy USB support will generate periodic SMIs. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.13-rc5-git-current (0d317fb72fe3cf0f611608cf3a3015bbe6cd2a66)
Unable to handle kernel paging request at virtual address 6b6b6b6b
printing eip:
c0188d15
*pde =
Oops: [#1]
PREEMPT
CPU:0
EIP:0060:[inotify_inode_queue_event+85/336]Not tainted VLI
EFLAGS: 00010206 (2.6.13-rc5-g0d317fb7)
EIP is at inotify_inode_queue_event+0x55/0x150
eax: 6b6b6b6b ebx: 6b6b6b63 ecx: edx: 0066
esi: c3effe34 edi: ce8c76ac ebp: d4bb864c esp: d8655eb0
ds: 007b es: 007b ss: 0068
Process nfsd (pid: 3750, threadinfo=d8654000 task=d6155020)
Stack: 0286 0286 0400 d4bb8760 d4bb8768
c3effe34
ce8c76ac d4bb864c c0170626 c3effe34 d6608ad4 db74b17c
c3effe34
e0cfe9a4 0013 e0d01b34 c0dd91b4 ce8c76ac c000 d66092dc
d66093c4
Call Trace:
[vfs_unlink+358/560] vfs_unlink+0x166/0x230
[pg0+544348580/1067586560] nfsd_unlink+0x104/0x230 [nfsd]
[pg0+544361268/1067586560] nfsd_cache_lookup+0x1c4/0x3c0 [nfsd]
[pg0+544371728/1067586560] nfsd3_proc_remove+0x80/0xc0 [nfsd]
[pg0+544381018/1067586560] nfs3svc_decode_diropargs+0x8a/0x100 [nfsd]
[pg0+544380880/1067586560] nfs3svc_decode_diropargs+0x0/0x100 [nfsd]
[pg0+544321698/1067586560] nfsd_dispatch+0x82/0x1f0 [nfsd]
[svc_authenticate+112/336] svc_authenticate+0x70/0x150
[svc_process+960/1648] svc_process+0x3c0/0x670
[pg0+544323105/1067586560] nfsd+0x1a1/0x350 [nfsd]
[ret_from_fork+6/20] ret_from_fork+0x6/0x14
[pg0+544322688/1067586560] nfsd+0x0/0x350 [nfsd]
[kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10
(akpm: a fix for this needs to go into 2.6.13, inotify + nfs
trivially oopses otherwise, even if inotify isn't actively used)
It looks like the following sequence is done in the wrong order.
When vfs_unlink() is called from sys_unlink() it has taken a ref
on the inode and sys_unlink() does the last iput() but when called
from other callsites vfs_unlink() might do the last iput() and
free inode, so inotify_inode_queue_event() will receive an already
freed object and dereference an already freed object.
Signed-off-by: Alexander Nyberg [EMAIL PROTECTED]
Index: mm/fs/namei.c
===
--- mm.orig/fs/namei.c 2005-08-07 12:06:16.0 +0200
+++ mm/fs/namei.c 2005-08-07 18:17:20.0 +0200
@@ -1869,8 +1869,8 @@
/* We don't d_delete() NFS sillyrenamed files--they still exist. */
if (!error !(dentry-d_flags DCACHE_NFSFS_RENAMED)) {
struct inode *inode = dentry-d_inode;
- d_delete(dentry);
fsnotify_unlink(dentry, inode, dir);
+ d_delete(dentry);
}
return error;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Lost Ticks on x86_64
On Sun, Aug 07, 2005 at 02:46:50PM -0400, Erick Turnquist wrote: Some BIOSes do not lock SMM, and you *could* turn it off at the chipset level. I don't see anything about SMM in my BIOS configuration even with the advanced options enabled... Turning it off at the chipset level sounds like a hardware hack - is it? No, it's usually just a PCI register you can change. Depends on your chipset, though. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] driver core: Add the ability to unbind drivers to devices from userspace
On 8/7/05, Pavel Machek [EMAIL PROTECTED] wrote: Hi! Could you tell me why you don't just fail the operation if malformed input is supplied? Leading/trailing white space should be allowed. For example echo appends '\n' unless you know to use -n. It is easier to fix the kernel than to teach everyone to use -n. Please, NO! echo -n is the right thing to do, and users will eventually learn. We are not going to add such workarounds all over the kernel... It is not a work around. These are text attributes meant for human use. Humans have a hard time cleaning up things they can't see. And the failure mode for this is awful, your attribute won't set but everything on the screen looks fine. Kernel is not a place to be user friendly. Or do you propose stripping whitespace for open(), too? File called foo.txt certainly *is* going to be confusing, but it should be allowed at kernel level. open is not made for human use, it is used by programs and only indirectly by humans. sysfs variables are used by directly humans. Now... echo foo /sys/var does not properly report errors. Thats bad, but it needs to be fixed in bash. It is going to take a lot more code to return an error that a parameter didn't match because of extra white space that it would take to simply remove the whitespace. -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms -- Jon Smirl [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: Linux-2.6.13-rc6: aic7xxx testers please..
Linus Torvalds wrote: In general, anybody who has reported regressions since 2.6.12, please re-test with -rc6 and report back ... Herbert Xu: tcp: fix TSO cwnd caching bug The tcp_output panic bug seems to be fixed. I'm referring to: http://lkml.org/lkml/2005/8/7/63 -- Heikki Orsila Barbie's law: [EMAIL PROTECTED] Math is hard, let's go shopping! http://www.iki.fi/shd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
synchronize_rcu vs. rcu_barrier
What's the difference between synchronize_rcu() and rcu_barrier() (new function used only by reiser4 code)? From the scant documentation it seems like they do the same thing. Keenan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.13-rc6: aic7xxx testers please..
On Sun, 2005-08-07 at 11:47 -0700, Linus Torvalds wrote: James and gang found the aic7xxx slowdown that happened after 2.6.12, and we'd like to get particular testing that it's fixed, so if you have a relevant machine, please do test this. There are other fixes too, a number of them reverting (at least for now) patches that people had problems with. In general, anybody who has reported regressions since 2.6.12, please re-test with -rc6 and report back (even if, or perhaps _particularly_ if, no change to the regression). It looks like CONFIG_4KSTACKS has gone away (IOW 8K stacks are no longer an option). But now I get this ominous warning when I compile ndiswrapper: *** WARNING: Kernel seems to have 4K size stack option (CONFIG_4KSTACKS) removed; many Windows drivers will need at least 8K size stacks. You should read wiki about 4K size stack issue. Don't complain about crashes until you resolve this As ndiswrapper seems to be the only option for many wireless chipsets, this certainly looks like it will lead to regressions. Why was this option removed? It's pretty clear that lots of out of tree drivers still require it. 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: Fw: Re: Elitegroup K7S5A + usb_storage problem
On Sunday, 7. August 2005 20:08, Alan Stern wrote: On Sun, 7 Aug 2005 [EMAIL PROTECTED] wrote: Hi Alan, no. the stick doesn't have a write protection switch. Once when i tried to copy a file to the mp3 player i got a new file there on remount, but it consisted of incorrect data. (so writing seemed to be possible and just went wrong) (in that case the fat seemed to be damaged after i had tried this, so that windows wasn't able to read it correctly any more. (formatting from the mp3 players menu helped) Well, perhaps the device isn't consistently writing data to the correct locations. greetings Martin PS: just as an info - i sent a usbmon trace to Pete Zaitcev today, should I send it to you too? Pete is quite as competent at solving this kind of problem as I am. And he knows the ub driver much better, so I'm happy to bow out and let him worry about it! :-) Just out of curiosity, if you plug the player into a Windows system without installing any special drivers first, will Windows be able to read and write files okay? If it can, a USB packet trace may give Pete a clue as to where to look. as far as i recall i didnt install any special drivers for my win 2k and win xp systems. (i got this mp3 player quite a while now...) How would I do such an packet trace ? Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ pgpEicsCRSKbU.pgp Description: PGP signature
Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Sun, 7 Aug 2005, Lee Revell wrote: It looks like CONFIG_4KSTACKS has gone away (IOW 8K stacks are no longer an option). But now I get this ominous warning when I compile ndiswrapper: It's still there, and it (still) depends on DEBUG_KERNEL. Nothing should have changed afaik.. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13-rc6: aic7xxx testers please..
On Sun, 2005-08-07 at 13:50 -0700, Linus Torvalds wrote: On Sun, 7 Aug 2005, Lee Revell wrote: It looks like CONFIG_4KSTACKS has gone away (IOW 8K stacks are no longer an option). But now I get this ominous warning when I compile ndiswrapper: It's still there, and it (still) depends on DEBUG_KERNEL. Nothing should have changed afaik.. OK, thanks, sorry for the noise. I remember there was talk recently of 4K stacks for everyone and was afraid it had already happened. 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: Fw: Elitegroup K7S5A + usb_storage problem
when i delete the files which are on the stick and do an umount/mount cycle,
the files are there again.
[... other mail ...]
I did the usbmon thing (hopefully correctly). Attached is the output.
Yes, that was perfect, thanks a lot. Unfortunately, I do not see a lot
of interesting things. The last write before the disconnect is a FAT
update:
c31650b8 1617078003 S Bo:006:01 -115 31 = 55534243 c600 0002 0a2a
3001 00
c31650b8 1617078987 C Bo:006:01 0 31
c31650b8 1617078997 S Bo:006:01 -115 512 = f8ff
c31650b8 1617080988 C Bo:006:01 0 512
c31650b8 1617080998 S Bi:006:02 -115 13
c31650b8 1617084987 C Bi:006:02 0 13 = 55534253 c600 00
Only one cluster was taken, when compared with the FAT that was read.
Everything seems to be in order. But the next trace (after replug -
see the device number changing from 6 to 7) shows FAT with old contents
being read (same block number 0x30):
cd6960b8 1874976301 S Bo:007:01 -115 31 = 55534243 0b00 0002 8a28
3001 00
cd6960b8 1874977274 C Bo:007:01 0 31
cd6960b8 1874977288 S Bi:007:02 -115 512
cd6960b8 1874979271 C Bi:007:02 0 512 = f8ff
cd6960b8 1874979282 S Bi:007:02 -115 13
cd6960b8 1874981271 C Bi:007:02 0 13 = 55534253 0b00 00
So, the device replies that writes were successful, but does not
actually commit them to the stable storage.
I suspect that this device may require some delays. I seem to recall
that we added delayes to usb-storage when we worked with Genesys
Logic. But ub contains no delays.
How about this:
--- linux-2.6.13-rc4/drivers/block/ub.c 2005-07-29 19:51:00.0 -0700
+++ linux-2.6.13-rc4-lem/drivers/block/ub.c 2005-08-07 13:48:11.0
-0700
@@ -1209,6 +1279,8 @@
return;
}
+ udelay(125);// XXX for Martin Maurer [EMAIL PROTECTED]
+
UB_INIT_COMPLETION(sc-work_done);
if (cmd-dir == UB_DIR_READ)
Please try this patchlet and let us know how it went.
-- Pete
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Alsa-devel] Re: any update on the pcmcia bug blocking Audigy2 notebook sound card driver development
Thanks, Lee. That's the bug I'm referring to. It would be great if laptop users can enjoy the higher sound quality the Audigy2 pcmcia sound card offers, which is way better than the builtin onboard sound. Raymond On 8/7/05, Lee Revell [EMAIL PROTECTED] wrote: On Sun, 2005-08-07 at 10:43 -0700, Andrew Morton wrote: Raymond Lai [EMAIL PROTECTED] wrote: Hi all, I remember there's a kernel pcmcia bug preventing the development for the Audigy2 pcmcia notebook sound card driver. See http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-Creative_Labs#matrix Is there any new updates on the situation? Has the bug been fixed? or anyone working on it? Is it related to http://bugzilla.kernel.org/show_bug.cgi?id=4788 ? No, that was a known issue that is resolved in 2.6.13-rc*. This is the bug he's referring to: http://lkml.org/lkml/2005/7/11/265 Looks like James never followed up, probably due to OLS. 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: Fw: Re: Elitegroup K7S5A + usb_storage problem
On Sun, 7 Aug 2005 22:47:40 +0200, Martin Maurer [EMAIL PROTECTED] wrote: Just out of curiosity, if you plug the player into a Windows system without installing any special drivers first, will Windows be able to read and write files okay? If it can, a USB packet trace may give Pete a clue as to where to look. as far as i recall i didnt install any special drivers for my win 2k and win xp systems. (i got this mp3 player quite a while now...) How would I do such an packet trace ? I have never run Snoopy on Windows myself and I did not want to subject you to it. Let's try my delay patch first. If that fails, I guess we have to get instructions from someone who knows how to run Snoopy. Maybe Windows issues some cache synchronization command when it commits FAT. Then the packet trace should show it. -- Pete - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] driver core: Add the ability to unbind drivers to devices from userspace
Hi! It is not a work around. These are text attributes meant for human use. Humans have a hard time cleaning up things they can't see. And the failure mode for this is awful, your attribute won't set but everything on the screen looks fine. Kernel is not a place to be user friendly. Or do you propose stripping whitespace for open(), too? File called foo.txt certainly *is* going to be confusing, but it should be allowed at kernel level. open is not made for human use, it is used by programs and only indirectly by humans. sysfs variables are used by directly humans. Both are kernel interfaces; I can use open() by hand just fine... Now... echo foo /sys/var does not properly report errors. Thats bad, but it needs to be fixed in bash. It is going to take a lot more code to return an error that a parameter didn't match because of extra white space that it would take to simply remove the whitespace. I believe we do correctly report errors in write() calls already. Bash not reporting them to the user is different problem. Pavel -- if you have sharp zaurus hardware you don't need... you know my address - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc5-mm1: oops when starting nscd on AMD64
On Sunday, 7 of August 2005 19:23, Andrew Morton wrote:
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
I get the following Oops after trying to start nscd from YaST on an
Athlon64-based box
(compiled with CONFIG_DEBUG_SPINLOCK=y):
Unable to handle kernel NULL pointer dereference at 0008 RIP:
801664d8{kmem_cache_alloc+232}
PGD 1501a067 PUD 1501b067 PMD 0
Oops: [1] PREEMPT
CPU 0
Modules linked in: raw af_key usbserial thermal processor fan button
battery ac snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97t
Pid: 6570, comm: nscd Not tainted 2.6.13-rc5-mm1
RIP: 0010:[801664d8] 801664d8{kmem_cache_alloc+232}
RSP: 0018:81001506de88 EFLAGS: 00010202
RAX: RBX: 8010eb3e RCX:
RDX: RSI: 8100292bdd68 RDI: 810001c3f6c0
RBP: 81001506deb8 R08: R09: 8100292bdd70
R10: 0006 R11: R12: 810001c3f6c0
R13: 8100292bdd68 R14: 80d0 R15: 801abe5c
FS: 2b11cb00() GS:804f2840()
knlGS:56abc320
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0008 CR3: 15019000 CR4: 06e0
Process nscd (pid: 6570, threadinfo 81001506c000, task
81001506b250)
Stack: 0246 81001569b5a0 8100155fe980
fff4 000a 81001506df78 801abe5c
40a05fff 81001569b5a0
Call Trace:801abe5c{sys_epoll_create+604}
80243579{add_preempt_count+105}
8010eb3e{system_call+126}
BUG: spinlock trylock failure on UP on CPU#0, nscd/6570
lock: 803bae80, .magic: dead4ead, .owner: nscd/6570, .owner_cpu: 0
Call Trace:80243579{add_preempt_count+105}
802431a3{spin_bug+211}
8011004b{show_trace+571}
8024328e{_raw_spin_trylock+62}
8035270e{_spin_trylock+30}
8010fc81{oops_begin+17}
803538ea{do_page_fault+1722}
801343de{vprintk+830}
801343de{vprintk+830}
801521f6{kallsyms_lookup+246}
8010f431{error_exit+0} 8011004b{show_trace+571}
80110047{show_trace+567}
80110168{show_stack+216}
80110207{show_registers+135} 8011050e{__die+142}
80353958{do_page_fault+1832}
802410c1{vsnprintf+1393}
801abe5c{sys_epoll_create+604}
8010f431{error_exit+0}
801abe5c{sys_epoll_create+604}
8010eb3e{system_call+126}
801664d8{kmem_cache_alloc+232}
801664c8{kmem_cache_alloc+216}
801abe5c{sys_epoll_create+604}
80243579{add_preempt_count+105}
8010eb3e{system_call+126}
---
| preempt count: 0002 ]
| 2 level deep critical section nesting:
.. [80352706] _spin_trylock+0x16/0x60
.[8010fc81] .. ( = oops_begin+0x11/0x60)
.. [80352706] _spin_trylock+0x16/0x60
.[8010fc81] .. ( = oops_begin+0x11/0x60)
I don't think it was supposed to do that.
Quite possibly it's something to do with the new debugging code - could you
please take a copy of the offending config, send it over and then try
removing debug options, see if the crash goes away? CONFIG_DEBUG_PREEMPT
would be the first to try..
The (offending) .config is attached and here's what happens without
CONFIG_DEBUG_PREEMPT
(the other debug options being unchanged):
Bootdata ok (command line is root=/dev/hdc6 vga=792 selinux=0 noapic
resume=/dev/hdc3 console=ttyS0,57600 console=tty0 debug)
Linux version 2.6.13-rc5-mm1 ([EMAIL PROTECTED]) (gcc version 3.3.5 20050117
(prerelease) (SUSE Linux)) #2 PREEMPT Sun Aug 7 21:10:38 CEST 2005
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
BIOS-e820: 0009fc00 - 000a (reserved)
BIOS-e820: 000e - 0010 (reserved)
BIOS-e820: 0010 - 2ff4 (usable)
BIOS-e820: 2ff4 - 2ff5 (ACPI data)
BIOS-e820: 2ff5 - 3000 (ACPI NVS)
BIOS-e820: fec0 - fec01000 (reserved)
BIOS-e820: fee0 - fee01000 (reserved)
ACPI: RSDP (v000 ACPIAM) @ 0x000f76e0
ACPI: RSDT (v001 A M I OEMRSDT 0x05000425 MSFT 0x0097) @
0x2ff4
ACPI: FADT (v001 A M I OEMFACP 0x05000425 MSFT 0x0097) @
0x2ff40200
ACPI: OEMB (v001 A M I OEMBIOS 0x05000425 MSFT 0x0097) @
0x2ff50040
ERROR: Invalid checksum
ACPI: DSDT (v001 L5DK8 L5DK8014 0x0014 INTL 0x02002026) @
Re: FYI: device_suspend(...) in kernel_power_off().
Hi! There as been a fair amount of consensus that calling device_suspend(...) in the reboot path was inappropriate now, because the device suspend code was too immature. With this latest piece of evidence it seems to me that introducing device_suspend(...) in kernel_power_off, kernel_halt, kernel_reboot, or kernel_kexec can never be appropriate. Code is not ready now = it can never be fixed? Thats quite a strange conclusion to make. It seems there is an fundamental incompatibility with ACPI power off. As best as I can tell the normal case of device_suspend(PMSG_SUSPEND) works reasonably well in 2.6.x. Powerdown is going to have the same problems as the powerdown at the end of suspend-to-disk. Can you ask people reporting broken shutdown to try suspend-to-disk? From what I can tell there are some fairly fundamental semantic differences, on that code path. The most peculiar problem I tracked is someone had a machine that would go into power off state and then wake right back up because of the device_suspend(PMSG_SUSPEND) change. So something is wrong with ACPI wakeup GPEs. It would hurt in suspend-to-disk case, too. I won't call it impossible to resolve the problems, but the people Good. So yes without a darn good argument as to why it should work. I will go with the experimental evidence that it fails miserably and trivially because of semantic incompatibility and can therefore never be fixed. I do not think any semantic issues exist. We need to pass detailed info down to the drivers that care, and we need to fix all the bugs in the drivers. That should be pretty much it. Pavel -- if you have sharp zaurus hardware you don't need... you know my address - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sluggish/very slow usb mouse on hp nx6110 notebook = acpi problem
On Fri, Aug 05, 2005 at 08:56:51PM +0200 JG wrote: hm, i currently have acpi=off noacpi noapic reboot=b as kernel parameter. if i remove the acpi stuff and enable acpi, the usb mouse works fine.. but after some time (5-10min) the kacpid process goes havoc and eats all cpu and the whole system is unresponsive- that's the reason i added those acpi=off parameters the first time when installing gentoo.. i tested with gentoo-2.6.12-r7 and vanilla-2.6.13rc5 Indicates a bug in kacpid or similar. Could you make sure you compile in Magic SysRq key under Kernel Hacking and boot the vanilla-2.6.13-rc6 (some recent acpi changes have gone in) and then wait for kacpid to go nuts and do Alt+Sysrq+t 4 times and then run 'dmesg -s 10 logfile' and send logfile over here so that we can see what kacpid is up to. If the box becomes so unresponsive you can't extract the log information it would be good if you could use either network console Documentation/networking/netconsole.txt or serial console at Documentation/serial-console.txt, both require an extra computer though... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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.13-rc6: aic7xxx testers please..
În data de Du, 07-08-2005 la 11:47 -0700, Linus Torvalds a scris: Luming Yu: [ACPI] revert Embedded Controller to polling-mode by default (ala 2.6.12) [ACPI] CONFIG_ACPI_HOTKEY is now n by default IMHO you really need then to make acpi_specific_hotkey the default or at least mention it in the release notes or you'll have tons of people screaming that the specific module does not work anymore. I found out about it after my toshiba_acpi module stopped working and I noticed a small change in the development acpi tree documentation mentioning acpi_specific_hotkey ... -- Cioby - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lockups with netconsole on e1000 on media insertion
Steven Rostedt wrote: I don't have the card, so I can't test it. But if this works (after removing the previous patch) then this is the better solution. I can confirm that this alone does not work for the simple unplug/re-plug cycle I described, it still locks up hard. Tried this alone on -rc6. --- John Bäckstrand - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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 with 2.6.13-rc5 on webserver with raid
On Fri, Aug 05, 2005 at 11:52:15AM +0200 Martin Braun wrote: Hi, I've been trying to upgrade kernel to 2.6.13-rc5. The server boots normally w/o errors, but after while (from 5 minutes up to 2 hours) the Kernel hangs (no keyboard input possible). As I am a newbie I cannot figure out who will be concerned with this error. Please don't run ksymoops on 2.6 kernels, it makes the output look weird and isn't necessary anymore. EIP; c0324afd tcp_tso_should_defer+fd/110 = Should be fixed in 2.6.13-rc6, if problem persists please report back. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
