Re: [2.6 patch] SCSI_QLA2ABC mustn't select SCSI_FC_ATTRS
On Sat, 2005-07-16 at 21:04 -0700, randy_dunlap wrote: > On Sat, 16 Jul 2005 23:11:26 -0400 Lee Revell wrote: > > > On Sun, 2005-07-17 at 04:38 +0200, Adrian Bunk wrote: > > > SCSI_QLA2XXX is automatically enabled for (SCSI && PCI). > > > > This has bugged me for a while. Why does this one SCSI driver default > > to Y in the first place? > > It's not a driver, it's a subdirectory. Ah, ok. Thanks. 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 patch] SCSI_QLA2ABC mustn't select SCSI_FC_ATTRS
On Sat, 16 Jul 2005 23:11:26 -0400 Lee Revell wrote: > On Sun, 2005-07-17 at 04:38 +0200, Adrian Bunk wrote: > > SCSI_QLA2XXX is automatically enabled for (SCSI && PCI). > > This has bugged me for a while. Why does this one SCSI driver default > to Y in the first place? It's not a driver, it's a subdirectory. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] V4L CX88 patch - against 2.6.12-mm2
On Tue, 28 Jun 2005, Mauro Carvalho Chehab wrote: - Add remove for MSI [EMAIL PROTECTED] You mean of course "Add remote" not "Add remove"... - D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] i386: Selectable Frequency of the Timer Interrupt
On Sat, 2005-07-16 at 19:35 -0700, Nish Aravamudan wrote:
> As you've seen, I think it depends on the timesource: for the PIT, it
> would be arch/i386/kernel/timers/timer_pit.c::setup_pit_timer().
That one looks pretty straightforward.
arch/i386/kernel/timers/timer_tsc.c really looks like fun. So many
corner cases...
BTW shouldn't this code from mark_offset_tsc():
402 if (pit_latch_buggy) {
403 /* get center value of last 3 time lutch */
404 if ((count2 >= count && count >= count1)
405 || (count1 >= count && count >= count2)) {
406 count2 = count1; count1 = count;
407 } else if ((count1 >= count2 && count2 >= count)
408|| (count >= count2 && count2 >= count1)) {
409 countmp = count;count = count2;
410 count2 = count1;count1 = countmp;
411 } else {
412 count2 = count1; count1 = count; count = count1;
413 }
414 }
use an ifdef? It only applies to cyrix_55x0, and mark_offset_tsc is a
pretty hot path.
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/
[PATCH 2.6.13-rc3] pcmcia: pcmcia_request_irq for !IRQ_HANDLE_PRESENT
Between 2.6.10 and 2.6.11, the kernel began to print this message when I
inserted my IBM Home and Away adapter (pcnet_cs) into an i82365 slot:
1.0: RequestIRQ: Unknown error code 0xffea
Initialization of the device then aborted; no `eth0' appeared. Another user
recently reported the same problem:
http://lists.infradead.org/pipermail/linux-pcmcia/2005-July/002151.html
I believe this change to pcmcia_request_irq brought about the problem:
http://linus.bkbits.net:8080/linux-2.5/diffs/drivers/pcmcia/[EMAIL
PROTECTED]|src/|src/drivers|src/drivers/pcmcia|hist/drivers/pcmcia/cs.c
When a driver calls pcmcia_request_irq with IRQ_HANDLE_PRESENT unset, it looks
for an open IRQ by request_irq()ing with a dummy handler and NULL dev_info.
free_irq uses dev_info as a key for identifying the handler to free among those
sharing an IRQ, so request_irq returns -EINVAL if dev_info is NULL and the IRQ
may be shared. That unknown error code is the -EINVAL.
It looks like only pcnet_cs and axnet_cs are affected. Most other drivers let
pcmcia_request_irq install their interrupt handlers. sym53c500_cs requests its
IRQ manually, but it cannot share an IRQ.
The appended patch changes pcmcia_request_irq to pass an arbitrary, unique,
non-NULL dev_info with the dummy handler.
Signed-off-by: Noah Misch <[EMAIL PROTECTED]>
--- pristine-linux-2.6.13-rc3/drivers/pcmcia/pcmcia_resource.c 2005-07-16
16:57:21.0 -0400
+++ rc3dbg/drivers/pcmcia/pcmcia_resource.c 2005-07-16 22:53:00.0
-0400
@@ -800,7 +800,7 @@ int pcmcia_request_irq(struct pcmcia_dev
} else {
int try;
u32 mask = s->irq_mask;
- void *data = NULL;
+ int data;
for (try = 0; try < 64; try++) {
irq = try % 32;
@@ -822,10 +822,10 @@ int pcmcia_request_irq(struct pcmcia_dev
(s->functions > 1) ||
(irq == s->pci_irq)) ? SA_SHIRQ : 0,
p_dev->dev.bus_id,
- (req->Attributes &
IRQ_HANDLE_PRESENT) ? req->Instance : data);
+ (req->Attributes &
IRQ_HANDLE_PRESENT) ? req->Instance : );
if (!ret) {
if (!(req->Attributes & IRQ_HANDLE_PRESENT))
- free_irq(irq, data);
+ free_irq(irq, );
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/
[PATCH 2.6.12.3] libata: add support for Promise SATA 300 TX2plus PDC40775
I'm using this card in a RAID1 with 2 new SATA drives with no problems.
Card - SATA 300 TX2plus PDC40775 (3d73)
Signed-off-by: Ed Kear <[EMAIL PROTECTED]>
diff -urN a/drivers/scsi/sata_promise.c b/drivers/scsi/sata_promise.c
--- a/drivers/scsi/sata_promise.c 2005-07-15 17:18:57.0 -0400
+++ b/drivers/scsi/sata_promise.c 2005-07-16 10:03:56.316189832 -0400
@@ -164,6 +164,8 @@
board_2037x },
{ PCI_VENDOR_ID_PROMISE, 0x3d75, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_2037x },
+ { PCI_VENDOR_ID_PROMISE, 0x3d73, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ board_2037x },
{ PCI_VENDOR_ID_PROMISE, 0x3318, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] char: Add Dell Systems Management Base driver
On Tue, Jul 12, 2005 at 06:17:29PM -0500, Doug Warzecha wrote: > Because the hardware interfaces on those systems and the Dell > systems management software that access the interfaces are > proprietary, I can't provide specifications for the interfaces or > source code for the software. So you want a driver merged which nobody except Dell can write code for? > The systems that are supported by the dcdbas driver contain the > following Dell proprietary hardware systems management interfaces: > Temperature Voltage Monitor (TVM) and Calling Interface. These > interfaces are supported by older Dell PowerEdge systems. What's so special here that you can't give more details? I personally find it a little unfair to ask to have a driver merged into mainline to facilitate some proprietary userland where you refuse to give protocol level details to create a viable alternative. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] make SPEAKUP_DEFAULT depend on SPEAKUP
When running `make oldconfig' with my 2.6.13-rc3 config on 2.6.13-rc3-mm1 I got a bit surprised when I answered `N'o to CONFIG_SPEAKUP but then still got prompted for CONFIG_SPEAKUP_DEFAULT - that didn't make sense, why would I want to select a default synthesizer for speakup if I have disabled speakup alltogether in the first place? The patch below makes SPEAKUP_DEFAULT depend on SPEAKUP. I believe that's the sane thing to do :) Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/char/speakup/Kconfig |1 + 1 files changed, 1 insertion(+) --- linux-2.6.13-rc3-mm1-orig/drivers/char/speakup/Kconfig 2005-07-17 04:39:45.0 +0200 +++ linux-2.6.13-rc3-mm1/drivers/char/speakup/Kconfig 2005-07-17 05:15:05.0 +0200 @@ -204,6 +204,7 @@ endif config SPEAKUP_DEFAULT + depends on SPEAKUP string "Choose Default synthesizer for Speakup" default "none" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] SCSI_QLA2ABC mustn't select SCSI_FC_ATTRS
On Sun, 2005-07-17 at 04:38 +0200, Adrian Bunk wrote: > SCSI_QLA2XXX is automatically enabled for (SCSI && PCI). This has bugged me for a while. Why does this one SCSI driver default to Y in the first place? 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/
[2.6 patch] SCSI_QLA2ABC mustn't select SCSI_FC_ATTRS
[ The subject was adapted to linux-kernel spam filters... ] On Fri, Jul 15, 2005 at 07:40:37AM -0700, Andrew Vasquez wrote: > On Fri, 15 Jul 2005, Adrian Bunk wrote: > > > On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote: > > >... > > > Changes since 2.6.13-rc2-mm2: > > >... > > > git-scsi-misc.patch > > >... > > > Subsystem trees > > >... > > > ... > > +obj-$(CONFIG_SCSI_QLA24XX) += qla2xxx.o > > > > > > I don't know what exactly you want to achieve, but this is so horribly > > wrong. > > > Yes, quite. How about the following to correct the intention. >... It looks good (except that you used spaces instead of a tab in the "select" line, but that's only a minor nitpick). Below is another fix for a different issue that was already present. cu Adrian <-- snip --> SCSI_QLA2XXX is automatically enabled for (SCSI && PCI). It therefore mustn't select SCSI_FC_ATTRS, since it otherwise unconditionally enables SCSI_FC_ATTRS for all users with (SCSI && PCI) enabled, even when they don't need any support for QLogic hardware. This patch also does a cosmetic change for making the "default" look more like in other kernel code. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.13-rc3-mm1-full/drivers/scsi/qla2xxx/Kconfig.old 2005-07-15 22:05:19.0 +0200 +++ linux-2.6.13-rc3-mm1-full/drivers/scsi/qla2xxx/Kconfig 2005-07-15 22:07:42.0 +0200 @@ -1,8 +1,7 @@ config SCSI_QLA2XXX tristate - default (SCSI && PCI) depends on SCSI && PCI - select SCSI_FC_ATTRS + default y config SCSI_QLA21XX tristate "QLogic ISP2100 host adapter family support" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] i386: Selectable Frequency of the Timer Interrupt
On 7/16/05, Jesper Juhl <[EMAIL PROTECTED]> wrote: > On 7/15/05, Jesper Juhl <[EMAIL PROTECTED]> wrote: > > On 7/15/05, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > > > On Fri, 15 Jul 2005, Jesper Juhl wrote: > > > > > > > > It's buggy, that I know. setting kernel_hz (the new boot parameter) to > > > > 250 causes my system clock to run at something like 4-5 times normal > > > > speed > > > > > > 4 times normal. You don't actually make the timer interrupt happen at > > > 250Hz, so the timer will be programmed to run at the full 1kHz. > > > > > Right, that's the basic problem. I increase jiffies at a higher rate > > but didn't slow the timer interrupt down at the same time. > > > > > You also need to actually change the LATCH define (in > > > include/linux/jiffies.h) to take this into account (there might be > > > something else too). > > > > > [...] > > > and you might be getting closer. > > > > > > Of course, you need to make sure that LATCH is used only after > > > jiffies_increment is set up. See "setup_pit_timer(void)" in > > > arch/i386/kernel/timers/timer_pit.c for more details. > > > > > > > Thank you for all the pointers and hints. This is a new area of code > > for me, so I'll need some time to poke around - the above helps a lot. > > Unfortunately I won't have any time to work on this today, but I'll > > see if I can get a working implementation together tomorrow. > > > > Ok, I'm afraid I'm going to need another hint or two. > > I've been looking at the timer code and getting thoroughly confused. > I've tried to find out where we actually program the interrupt > controller to say "this is the frequency I want you to interrupt me > at", but I can't seem to find it. > I'm aware that there are multiple possible time sources, and I've been > looking at the 8259 code, the ioapic code, the hpet code and various > other bits in arch/i386/kernel/ and arch/i386/kernel/timers/ , but I > seem to end up getting confused about all the different defines like > CLOCK_TICK_RATE, ACTHZ, TICK_NSEC, TICK_USEC, etc... > > Where do we actually program the tick rate we want? As you've seen, I think it depends on the timesource: for the PIT, it would be arch/i386/kernel/timers/timer_pit.c::setup_pit_timer(). In that function, you'll notice we outb() the LATCH value. I think there are similar functions in the other timesources, e.g. the arch/i386/kernel/apic.c::setup_APIC_timer(). Does that help some? Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] i386: Selectable Frequency of the Timer Interrupt
On Sun, 2005-07-17 at 04:13 +0200, Jesper Juhl wrote:
> Where do we actually program the tick rate we want?
>
In arch/i386/kernel/timers/timer_pit.c:
166 void setup_pit_timer(void)
167 {
168 unsigned long flags;
169
170 spin_lock_irqsave(_lock, flags);
171 outb_p(0x34,PIT_MODE); /* binary, mode 2, LSB/MSB, ch
0 */
172 udelay(10);
173 outb_p(LATCH & 0xff , PIT_CH0); /* LSB */
174 udelay(10);
175 outb(LATCH >> 8 , PIT_CH0); /* MSB */
176 spin_unlock_irqrestore(_lock, flags);
177 }
178
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.12 vs. /sbin/cardmgr
On Sat, 16 Jul 2005 11:36:45 -0500 (CDT), [EMAIL PROTECTED] (Bob Tracy) wrote: >rct wrote: >> Dominik Brodowski wrote: >> > On Sun, Jul 10, 2005 at 03:37:22PM -0500, Bob Tracy wrote: >> > > Dominik Brodowski wrote: >> > > > On Sat, Jul 09, 2005 at 12:12:17AM -0500, Bob Tracy wrote: >> > > > > (/sbin/cardmgr chewing up lots of CPU cycles with 2.6.12 kernel) >> > > > >> > > > Please post the output of "lspci" and "lsmod" as I'd like to know which >> > > > kind of PCMCIA bridge is in your notebook. >> > >> > OK, it's a plain TI1225. Could you try whether the bug is still existent in >> > 2.6.13-rc3, please? >> >> 2.6.13-rc3 works fine here. The "cardmgr" process is no longer chewing >> up lots of CPU time, and otherwise seems to be working correctly. Thanks! > >I spoke too soon :-(. The first boot on 2.6.13-rc3 was fine. Every >boot since then has reflected no change relative to the 2.6.12 behavior. >The "cardmgr" process racks up CPU time almost as fast as time >elapses: it's at the top of the "top" list. I turned off cardmgr for 2.6, CardBus works without it on slackware 'cos pciutils is patched to provide a helper, what is 'correct' way to test this? Toshiba laptop with ToPIC100 bridge, currently not working for PCCard 16-bit things because I turned off cardmgr. CardBus NIC works in 2.4 + 2.6 series. --Grant. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] remove CONFIG_PCI_NAMES
This patch removes CONFIG_PCI_NAMES. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- Due to it's size, the patch is available at http://www.fs.tum.de/~bunk/kernel/patch-remove-CONFIG_PCI_NAMES Documentation/feature-removal-schedule.txt |9 MAINTAINERS|7 arch/alpha/kernel/sys_marvel.c |5 arch/ppc64/kernel/eeh.c| 31 arch/ppc64/kernel/iSeries_VpdInfo.c|5 arch/ppc64/kernel/pci.c|1 drivers/char/drm/drmP.h|4 drivers/infiniband/hw/mthca/mthca_main.c |8 drivers/infiniband/hw/mthca/mthca_reset.c |8 drivers/net/irda/vlsi_ir.h |6 drivers/pci/Kconfig| 17 drivers/pci/Makefile | 18 drivers/pci/gen-devlist.c | 132 drivers/pci/names.c| 137 drivers/pci/pci.ids|10180 - drivers/pci/probe.c|2 drivers/pci/proc.c | 12 drivers/usb/core/hcd-pci.c |4 drivers/video/nvidia/nvidia.c |4 drivers/video/riva/fbdev.c |4 include/linux/pci.h| 14 21 files changed, 32 insertions(+), 10576 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] i386: Selectable Frequency of the Timer Interrupt
On 7/15/05, Jesper Juhl <[EMAIL PROTECTED]> wrote: > On 7/15/05, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > On Fri, 15 Jul 2005, Jesper Juhl wrote: > > > > > > It's buggy, that I know. setting kernel_hz (the new boot parameter) to > > > 250 causes my system clock to run at something like 4-5 times normal > > > speed > > > > 4 times normal. You don't actually make the timer interrupt happen at > > 250Hz, so the timer will be programmed to run at the full 1kHz. > > > Right, that's the basic problem. I increase jiffies at a higher rate > but didn't slow the timer interrupt down at the same time. > > > You also need to actually change the LATCH define (in > > include/linux/jiffies.h) to take this into account (there might be > > something else too). > > > [...] > > and you might be getting closer. > > > > Of course, you need to make sure that LATCH is used only after > > jiffies_increment is set up. See "setup_pit_timer(void)" in > > arch/i386/kernel/timers/timer_pit.c for more details. > > > > Thank you for all the pointers and hints. This is a new area of code > for me, so I'll need some time to poke around - the above helps a lot. > Unfortunately I won't have any time to work on this today, but I'll > see if I can get a working implementation together tomorrow. > Ok, I'm afraid I'm going to need another hint or two. I've been looking at the timer code and getting thoroughly confused. I've tried to find out where we actually program the interrupt controller to say "this is the frequency I want you to interrupt me at", but I can't seem to find it. I'm aware that there are multiple possible time sources, and I've been looking at the 8259 code, the ioapic code, the hpet code and various other bits in arch/i386/kernel/ and arch/i386/kernel/timers/ , but I seem to end up getting confused about all the different defines like CLOCK_TICK_RATE, ACTHZ, TICK_NSEC, TICK_USEC, etc... Where do we actually program the tick rate we want? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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][PCMCIA] - iounmap: bad address f1d62000
On Sat, Jul 16, 2005 at 05:12:58PM +0200, Dominik Brodowski wrote: > Could you check whether this patch helps, please? > > Index: 2.6.13-rc3-git2/drivers/pcmcia/cistpl.c > === > --- 2.6.13-rc3-git2.orig/drivers/pcmcia/cistpl.c > +++ 2.6.13-rc3-git2/drivers/pcmcia/cistpl.c > @@ -88,31 +88,38 @@ EXPORT_SYMBOL(release_cis_mem); > static void __iomem * This patch appears to have cured it! Good job. Just in case it is of use to use, I've also responded to your first request below. > Hi, > > Could you send me the output of /proc/iomem on both a working kernel and on > 2.6.13-rc3-APM, please? > > Thanks, > Dominik First is as fails, second is same kernel with your patch applied, where it seems to work just fine. Let me know if you would like it from 2.6.12.2 or 2.6.11.4-21.7 (SuSE 9.3) kernel. Linux X31 2.6.13-rc3-APM #13 Fri Jul 15 23:55:12 EDT 2005 i686 i686 i386 GNU/Linux -0009efff : System RAM 0009f000-0009 : reserved 000a-000b : Video RAM area 000c-000c : Video ROM 000d-000d0fff : Adapter ROM 000d1000-000d1fff : Adapter ROM 000d2000-000d3fff : reserved 000e-000e : Extension ROM 000f-000f : System ROM 0010-2ff5 : System RAM 0010-00361cfc : Kernel code 00361cfd-004083e7 : Kernel data 2ff6-2ff76fff : ACPI Tables 2ff77000-2ff78fff : ACPI Non-volatile Storage 2ff8-2fff : reserved 3000-33ff : :00:1f.1 b000-bfff : :02:00.0 b000-bfff : yenta_socket b100-b1000fff : :02:00.1 b100-b1000fff : yenta_socket c000-c3ff : :00:1d.7 c000-c3ff : ehci_hcd c800-c8ff : :00:1f.5 c800-c8ff : Intel 82801DB-ICH4 cc00-cdff : :00:1f.5 cc00-cdff : Intel 82801DB-ICH4 c010-c01f : PCI Bus #01 c010-c010 : :01:00.0 c010-c010 : radeonfb c012-c013 : :01:00.0 c020-cfff : PCI Bus #02 c020-c020 : :02:01.0 c021-c021 : :02:02.0 c021-c021 : ath c022-c023 : :02:01.0 c024-c02407ff : :02:00.2 c024-c02407ff : ohci1394 c120-c1200fff : pcmcia_socket1 c200-c3ff : PCI CardBus #03 c400-c5ff : PCI CardBus #07 d000-dfff : :00:00.0 e000-e7ff : PCI Bus #01 e000-e7ff : :01:00.0 e000-e7ff : radeonfb e800-efff : PCI Bus #02 e800-e9ff : PCI CardBus #03 ea00-ebff : PCI CardBus #07 ec00-ec00 : :02:01.0 ff80- : reserved == Linux X31 2.6.13-rc3-APM #14 Sat Jul 16 10:19:10 EDT 2005 i686 i686 i386 GNU/Linux -0009efff : System RAM 0009f000-0009 : reserved 000a-000b : Video RAM area 000c-000c : Video ROM 000d-000d0fff : Adapter ROM 000d1000-000d1fff : Adapter ROM 000d2000-000d3fff : reserved 000e-000e : Extension ROM 000f-000f : System ROM 0010-2ff5 : System RAM 0010-00359af0 : Kernel code 00359af1-003fe3e7 : Kernel data 2ff6-2ff76fff : ACPI Tables 2ff77000-2ff78fff : ACPI Non-volatile Storage 2ff8-2fff : reserved 3000-33ff : :00:1f.1 b000-bfff : :02:00.0 b000-bfff : yenta_socket b100-b1000fff : :02:00.1 b100-b1000fff : yenta_socket c000-c3ff : :00:1d.7 c000-c3ff : ehci_hcd c800-c8ff : :00:1f.5 c800-c8ff : Intel 82801DB-ICH4 cc00-cdff : :00:1f.5 cc00-cdff : Intel 82801DB-ICH4 c010-c01f : PCI Bus #01 c010-c010 : :01:00.0 c010-c010 : radeonfb c012-c013 : :01:00.0 c020-cfff : PCI Bus #02 c020-c020 : :02:01.0 c021-c021 : :02:02.0 c021-c021 : ath c022-c023 : :02:01.0 c024-c02407ff : :02:00.2 c024-c02407ff : ohci1394 c120-c1200fff : pcmcia_socket1 c200-c3ff : PCI CardBus #03 c400-c5ff : PCI CardBus #07 d000-dfff : :00:00.0 e000-e7ff : PCI Bus #01 e000-e7ff : :01:00.0 e000-e7ff : radeonfb e800-efff : PCI Bus #02 e800-e9ff : PCI CardBus #03 ea00-ebff : PCI CardBus #07 ec00-ec00 : :02:01.0 ff80- : reserved -- Dr. Vincent C. Jones, PE Expert advice and a helping hand Computer Network Consultant for those who want to manage and Networking Unlimited, Inc.control their networking destiny Phone: +1 201 568-7810 14 Dogwood Lane, Tenafly, NJ 07670 [EMAIL PROTECTED] http://www.networkingunlimited.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: 2.6.13-rc3-mm1
On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ > +suspend-update-documentation.patch > +swsusp-fix-printks-and-cleanups.patch > +swsusp-fix-remaining-u32-vs-pm_message_t-confusion.patch > +swsusp-switch-pm_message_t-to-struct.patch > +swsusp-switch-pm_message_t-to-struct-pmac_zilog-fix.patch > +swsusp-switch-pm_message_t-to-struct-ppc32-fixes.patch > +fix-pm_message_t-stuff-in-mm-tree-netdev.patch I'm getting this (on ppc32, though I don't think it matters): CC drivers/video/chipsfb.o drivers/video/chipsfb.c: In function `chipsfb_pci_suspend': drivers/video/chipsfb.c:465: error: invalid operands to binary == drivers/video/chipsfb.c:467: error: invalid operands to binary != make[3]: *** [drivers/video/chipsfb.o] Error 1 make[2]: *** [drivers/video] Error 2 make[1]: *** [drivers] Error 2 make[1]: Leaving directory `/usr/src/linux-ctesiphon/linux-2.6.13-rc3-mm1' make: *** [stamp-build] Error 2 The above-quoted patches seem to be the culprit, but my feeble attempts at making a patch didn't work out. While I'm complaining: > Q: Why we cannot suspend to a swap file? > A: Because accessing swap file needs the filesystem mounted, and > filesystem might do something wrong (like replaying the journal) > during mount. [Probably could be solved by modifying every filesystem > to support some kind of "really read-only!" option. Patches welcome.] I seem to recall that swsusp2 can do this. I don't hold out much hope that suspend will ever work on my laptop, with its i815 video chipset, at least not from X (and then there's no point). The i81x and the linux video architecture just don't get along, even if I do away with i810fb and DRM support. But I can't help but notice that every linux-suspend HOWTO tells you to patch in swsusp2 as a first step -- the consensus seems to be that it you want clean and conservative code, use swsusp1; if you want suspending to *work*, use swsusp2. How many people are actually able to make use of swsusp1? Is anyone testing it besides Mr. Machek? This is a case in point; every time I partition a system for Linux, I have to consider whether or not I'm ever going to want swsusp to work on that box. The performance penalty for swap files went away in 2.6, so this is sort of a regression. I know I'm not going to be writing any of those patches, but I'd sure be nice if Linux got around to having usable suspend support without being beholden to the whatever patches Mr. Cunningham gets around to putting out. -- Joseph Fannin [EMAIL PROTECTED] /* So there I am, in the middle of my `netfilter-is-wonderful' talk in Sydney, and someone asks `What happens if you try to enlarge a 64k packet here?'. I think I said something eloquent like `fuck'. - RR */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] VIDEO_SAA7134 must depend on SOUND
VIDEO_SAA7134=y and SOUND=n results in the following compile error: <-- snip --> ... LD .tmp_vmlinux1 drivers/built-in.o(.text+0x4fafcb): In function `saa7134_initdev': : undefined reference to `unregister_sound_dsp' drivers/built-in.o(.text+0x4fb141): In function `saa7134_initdev': : undefined reference to `register_sound_dsp' drivers/built-in.o(.text+0x4fb17c): In function `saa7134_initdev': : undefined reference to `register_sound_mixer' drivers/built-in.o(.text+0x4fb339): In function `saa7134_finidev': : undefined reference to `unregister_sound_mixer' drivers/built-in.o(.text+0x4fb341): In function `saa7134_finidev': : undefined reference to `unregister_sound_dsp' make: *** [.tmp_vmlinux1] Error 1 <-- snip --> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 2 Jul 2005 --- linux-2.6.13-rc1-mm1-full/drivers/media/video/Kconfig.old 2005-07-02 19:57:04.0 +0200 +++ linux-2.6.13-rc1-mm1-full/drivers/media/video/Kconfig 2005-07-02 20:01:33.0 +0200 @@ -249,7 +249,7 @@ config VIDEO_SAA7134 tristate "Philips SAA7134 support" - depends on VIDEO_DEV && PCI && I2C + depends on VIDEO_DEV && PCI && I2C && SOUND select VIDEO_BUF select VIDEO_IR select VIDEO_TUNER - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/4] new human-time soft-timer subsystem
On 15.07.2005 [00:28:44 +0200], Roman Zippel wrote: > Hi, > > On Thu, 14 Jul 2005, Nishanth Aravamudan wrote: > > > We no longer use jiffies (the variable) as the basis for determining > > what "time" a timer should expire or when it should be added. Instead, > > we use a new function, do_monotonic_clock(), which is simply a wrapper > > for getnstimeofday(). > > And suddenly a simple 32bit integer becomes a complex 64bit integer, which > requires hardware access to read a timer and additional conversion into ns. > Why is suddenly everyone so obsessed with molesting something simple and > cute as jiffies? Thanks for the feedback, Roman. I know the 64-bit operations are critical from a performance perspective and may be excessive from a pragmatic perspective. Maybe an alternative would be to only provide *microsecond* resolution in the software, which I currently assume is storable in an unsigned long (a little over an hour?). We could then provide a supplemental interface for those sleeps which would exceed this time, either via looping or a 64-bit parameter for this special interface. Would that perhaps be a better alternative from the 64-bit perspective? We could do this one better, perhaps, by basically doing exactly what jiffies does now, but storing a time value (in microseconds) instead of a count of the number of ticks (jiffies' current interpretation). This would perhaps be a 64-bit op, but that is the case current with jiffies_64++ (or jiffies_64 += jiffies_increment). I will work on some patches to do something to this effect and will bring it up during the time/timer talk (Saturday at 13h30). Thanks again, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/4] add jiffies_to_nsecs() helper and fix up size of usecs
On 15.07.2005 [14:14:25 +0200], Pavel Machek wrote:
> Hi!
>
> > > > +static inline u64 jiffies_to_nsecs(const unsigned long j)
> > > > +{
> > > > +#if HZ <= NSEC_PER_SEC && !(NSEC_PER_SEC % HZ)
> > > > + return (NSEC_PER_SEC / HZ) * (u64)j;
> > > > +#elif HZ > NSEC_PER_SEC && !(HZ % NSEC_PER_SEC)
> > > > + return ((u64)j + (HZ / NSEC_PER_SEC) - 1)/(HZ / NSEC_PER_SEC);
> > > > +#else
> > > > + return ((u64)j * NSEC_PER_SEC) / HZ;
> > > > +#endif
> > > > +}
> > >
> > > That might look a little better something like:
> > >
> > > static inline u64 jiffies_to_nsecs(const unsigned long __j)
> > > {
> > > u64 j = __j;
> > >
> > > if (HZ <= NSEC_PER_SEC && !(NSEC_PER_SEC % HZ))
> > > return (NSEC_PER_SEC / HZ) * j;
> > > else if (HZ > NSEC_PER_SEC && !(HZ % NSEC_PER_SEC))
> > > return (j + (HZ / NSEC_PER_SEC) - 1)/(HZ / NSEC_PER_SEC);
> > > else
> > > return (j * NSEC_PER_SEC) / HZ;
> > > }
> > >
> > > Compilers are smart :)
> >
> > Well, I was trying to keep it similar to the other conversion functions.
> > I guess the compiler can evaluate the conditional full of constants at
> > compile-time regardless of whether it is #if or if ().
> >
> > I can make these changes if others would like them as well.
>
> Yes, please. And feel free to convert nearby functions, too ;-).
I have a patch to make this change for all the jiffies <--> human-time
functions, but have a problem. I noticed that these functions, in the
if/else form (as opposed to #if/#else) will warn about division-by-zero
problems, as (HZ / MSEC_PER_SEC), (HZ / USEC_PER_SEC) & (HZ /
NSEC_PER_SEC) are all 0 if HZ < 1000 (which, of course, is the default
now :) ). Any suggestions? Just leave the functions as is? Even then,
I'm going to update this patch to use USEC_PER_SEC and MSEC_PER_SEC in
the other conversion functions like I use NSEC_PER_SEC in the first
version.
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: relayfs documentation sucks?
bert hubert writes:
> Ok, I'm working furiously on my OLS presentation (Wednesday, 3pm, be
> there), but I'm running into a wall with relayfs, which I intend to use to
> convey large amounts of disk statistics towards userspace.
>
> Now, I've read Documentation/filesystems/relayfs.txt many times over, and I
> don't get it.
>
> It appears there is relayfs, and 'klog' on top of that. It also appears that
> to access relayed data from the kernel in userspace there is librelay.c.
>
> On reading librelay.c, I find code sending and receiving netlink
> messages, but relayfs.txt doesn't even contain the word netlink!
Hi,
relayfs itself only provides the buffering and file operations along
with the kernel API for clients as documented in
Documentation/filesystems/relayfs.txt. Applications still need some
kind of communication between the kernel and user space in order to
know when data is ready and how much is ready - the relay-apps stuff
tries to make this easy to do by allowing clients to ignore all those
details. It happens to use netlink for this, but clients can use
whatever they want to do this communication.
The klog patch just makes a couple of utility logging functions
available for use from anywhere within the kernel which allow the
client to not have to worry about whether or not there's a relayfs
channel ready to receive the data - you could just as well use
relay_write directly in say the IO function you want to trace, but
you'd have to do something like if(relay_channel) relay_write(). It
just allows you to uncondionally log regardless of whether there's a
channel ready or not.
If you just want to get something up and running without worrying
about the netlink channel and all that stuff, you can just modify the
kleak example as follows:
- apply the klog.patch
- in kleak.c, change init_relay_app("kleak", "cpu", NULL) to
init_relay_app("diskstat", "cpu", NULL). The relayfs files will be
created as /mnt/relay/diskstat/cpu0...cpuX, if you've mounted relayfs
at /mnt/relay.
- in kleak-app.c, change
static char *kleak_filebase = "/mnt/relay/kleak/cpu";
to
static char *kleak_filebase = "/mnt/relay/diskstat/cpu";
- log the data from the kernel functions using klog() or
klog_printk(). The kleak.patch file shows how to do this for
kmalloc/kfree, just do something similar in the functions you actually
want to instrument. You can also use klog_printk() if you want to log
as text.
Then just run the kleak app, and when it finishes, you should have a
set of files, cpu0l...cpuX in your current directory containing all
the data you've logged.
If you still have problems and would be willing to share your code,
I'd be happy to get it going myself. Just let me know.
>
> I then launched the 'kleak-app' sample program, but told it to look at
> /relay/diskstat* instead of its own file, but it gives me unspecified
> netlink errors.
Can you give me more details about these errors?
>
> Things I need to know, and which I hope to find documented somewhere:
>
> 1) Do I need to do the netlink thing?
No, the example code uses netlink, but you could use anything you want
to communicate between the kernel and daemon.
> 2) What kind of messages do I need to send/receive?
Basically, the daemon needs to know, for a given per-cpu buffer, how
many sub-buffers have been produced and consumed, in order to know
which sections of the mmapped buffer to read. It also needs to notify
the kernel client of how many sub-buffers it's consumed. Basically
that's it - the rest is application management e.g. the buffer sizes
to use, when to start/stop logging, etc.
> 3) What is the exact format userspace sees in the relayfs file? Iow, can I
>access that file w/o using librelay.c?
The format is whatever the client writes into it - relayfs itself
doesn't impose any format at all. The client doesn't need librelay.c
to read the data itself - librelay.c is for managing the daemon side
of the application and writing ready data to disk as it becomes
available. It doesn't know anything about the actual data being written.
> 4) What are the semantics for reading from that file?
The file is a buffer broken up into sub-buffers. The client reads the
sub-buffers it knows are ready directly from the mmapped buffer.
The file can only be mmap()ed - there is no read() available.
> 5) When using klog, is there only one channel?
There is only one channel, which is represented in the filesytem as a
set of per-cpu files.
> 6) does librelay.c talk to regular relayfs or to klog?
librelay.c talks to the client code in relay-app.h, which in turn uses
the relayfs kernel API to talk to relayfs.
BTW, there's also documentation in relay-app.h, don't know if you saw
that.
Hope that helps,
Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
RE: 2.6.9 chrdev_open: serial_core: uart_open
Hi, Alan Cox wrote:
> A good rule of thumb
> is to trace the sequence of calls and assume that the last sane sequence
> is the one that occurred before the failure.
Note also that gcc does sibling optimization, i.e. it will happily
reduce the code at the end of
int bar(a,b) { [...] return baz(x,y); }
into something like
overwrite 'a' with 'x', and 'b' with 'y'
pop local stack frame, if present
jump to baz
which saves some stack space and is faster, but makes you wonder
how in hell the
baz
foo
stack dump you're seeing in your crash dump came about.
(2.6.13 will turn that off when debugging.)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
There is a vast difference between putting your nose in other people's
business and putting your heart in other people's problems.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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][PCMCIA] - iounmap: bad address f1d62000
On Sat, Jul 16, 2005 at 04:21:44PM +0100, Russell King wrote:
> On Sat, Jul 16, 2005 at 05:12:58PM +0200, Dominik Brodowski wrote:
> > Could you send me the output of /proc/iomem on both a working kernel and on
> > 2.6.13-rc3-APM, please?
>
> Dominik, I'd suggest looking elsewhere. The memory regions must be
> free to be able to call into readable(), and therefore pccard_validate_cis().
>
> What seems to be happening is that s->ops->set_mem_map in set_cis_map
> is returning an error, causing it to free the ioremapped region
> multiple times. Maybe the card has an invalid CIS causing an out
> of range card_start to be requested?
Could you check whether this patch helps, please?
Index: 2.6.13-rc3-git2/drivers/pcmcia/cistpl.c
===
--- 2.6.13-rc3-git2.orig/drivers/pcmcia/cistpl.c
+++ 2.6.13-rc3-git2/drivers/pcmcia/cistpl.c
@@ -88,31 +88,38 @@ EXPORT_SYMBOL(release_cis_mem);
static void __iomem *
set_cis_map(struct pcmcia_socket *s, unsigned int card_offset, unsigned int
flags)
{
-pccard_mem_map *mem = >cis_mem;
-int ret;
+ pccard_mem_map *mem = >cis_mem;
+ int ret;
-if (!(s->features & SS_CAP_STATIC_MAP) && mem->res == NULL) {
- mem->res = pcmcia_find_mem_region(0, s->map_size, s->map_size, 0, s);
- if (mem->res == NULL) {
- printk(KERN_NOTICE "cs: unable to map card memory!\n");
- return NULL;
- }
- s->cis_virt = ioremap(mem->res->start, s->map_size);
-}
-mem->card_start = card_offset;
-mem->flags = flags;
-ret = s->ops->set_mem_map(s, mem);
-if (ret) {
- iounmap(s->cis_virt);
- return NULL;
-}
-
-if (s->features & SS_CAP_STATIC_MAP) {
- if (s->cis_virt)
- iounmap(s->cis_virt);
- s->cis_virt = ioremap(mem->static_start, s->map_size);
-}
-return s->cis_virt;
+ if (!(s->features & SS_CAP_STATIC_MAP) && (mem->res == NULL)) {
+ mem->res = pcmcia_find_mem_region(0, s->map_size, s->map_size,
0, s);
+ if (mem->res == NULL) {
+ printk(KERN_NOTICE "cs: unable to map card memory!\n");
+ return NULL;
+ }
+ s->cis_virt = NULL;
+ }
+
+ if (!(s->features & SS_CAP_STATIC_MAP) && (!s->cis_virt))
+ s->cis_virt = ioremap(mem->res->start, s->map_size);
+
+ mem->card_start = card_offset;
+ mem->flags = flags;
+
+ ret = s->ops->set_mem_map(s, mem);
+ if (ret) {
+ iounmap(s->cis_virt);
+ s->cis_virt = NULL;
+ return NULL;
+ }
+
+ if (s->features & SS_CAP_STATIC_MAP) {
+ if (s->cis_virt)
+ iounmap(s->cis_virt);
+ s->cis_virt = ioremap(mem->static_start, s->map_size);
+ }
+
+ return s->cis_virt;
}
/*==
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Kconfig: lxdialog: Enable UTF8
On Sat, 16 Jul 2005, Ken Moffat wrote: > On Sat, 16 Jul 2005, Sam Ravnborg wrote: > > > > > > > OK, I'll bite - non utf8 here, and no libncursesw : a quick google > > > suggests I can get it if I recompile ncurses with --enable-widec, but > > > why would I want to do that ? > > Could you try if specifying both libraries works for you. the 'w' > > version first. Then we can use the 'w' version when available but > > fall-back to the normal case if not. > > > > Sam > > > > Didn't work, I get the not unexpected "cannot find -lncursesw". I > think some sort of pre-test will be needed to see which one exists. > I'm weak on doing this in a Makefile, but I'll have a look tonight or > tomorrow. > Hmm, I can repeatedly test by linking against candidate libraries by converting the current if...else test to nested if..else (adding -lcurses while I'm at it), but I can't crack setting HOST_LOADLIBES from that - if the link succeeded, I'm into the shell code to tidy up and from there I can't set a variable in the Makefile . I don't want to attempt to build a configure script in a Makefile - even if it's possible, I think it would be nasty. So unless I've misunderstood your question, no, I can't specify both libraries. Note that I originally asked why on a system that doesn't use utf8, I should rebuild ncurses. A sufficiently compelling reason would make me rebuild. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-mm1 : oops in dnotify_parent
Le 15.07.2005 10:36, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
Hello,
I just got this oops :
Unable to handle kernel NULL pointer dereference at virtual address 0104
printing eip:
c016c7c4
*pde =
Oops: [#1]
last sysfs file:
Modules linked in: isofs pktcdvd autofs4 lp parport_pc parport snd_seq_oss
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_ens1371 gameport
snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd
soundcore af_packet floppy ne2k_pci 8390 ide_cd cdrom ohci1394 ieee1394 loop
aes_i586 dm_crypt nls_iso8859_1 nls_cp850 vfat fat reiser4 zlib_deflate
zlib_inflate reiserfs pcspkr via_agp agpgart dm_mod joydev usbhid uhci_hcd
usbcore video hotkey configfs
CPU:0
EIP:0060:[dnotify_parent+19/67]Not tainted VLI
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202 (2.6.13-rc3-mm1)
EIP is at dnotify_parent+0x13/0x43
eax: c5d13f70 ebx: cffddfd8 ecx: edx: 0002
esi: c6f22504 edi: c5d13f70 ebp: c712ff0c esp: c712ff08
ds: 007b es: 007b ss: 0068
Process gnome-settings- (pid: 5078, threadinfo=c712e000 task=c708d050)
Jul 16 23:36:30 antares gconfd (laurent-4942): Sortie
Stack: 0002 c712ff7c c0147dcf 0001 080afdf0 000c c712ff30
c6e62b60 0001 080afdfc c712ff5c c015a7d5 c712ff40 c712ff40
cff8 c02217e7 0008 c63afc60 c712ff64 c015a810 c712ff84
Call Trace:
[show_stack+118/126] show_stack+0x76/0x7e
[] show_stack+0x76/0x7e
[show_registers+234/338] show_registers+0xea/0x152
[] show_registers+0xea/0x152
[die+194/316] die+0xc2/0x13c
[] die+0xc2/0x13c
[do_page_fault+916/1344] do_page_fault+0x394/0x540
[] do_page_fault+0x394/0x540
[error_code+79/84] error_code+0x4f/0x54
[] error_code+0x4f/0x54
[do_readv_writev+514/572] do_readv_writev+0x202/0x23c
[] do_readv_writev+0x202/0x23c
[vfs_writev+64/71] vfs_writev+0x40/0x47
[] vfs_writev+0x40/0x47
[sys_writev+59/147] sys_writev+0x3b/0x93
[] sys_writev+0x3b/0x93
[sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75
[] sysenter_past_esp+0x54/0x75
Code: 85 db 75 be 83 7d ec 00 74 07 89 f8 e8 ba fd ff ff 58 5a 5b 5e 5f c9 c3
83 3d 94 a1 2b c0 00 55 89 e5 53 74 30 8b 58 0c 8b 4b 08 <85> 91 04 01 00 00 74
22 85 db 74 10 8b 03 85 c0 75 08 0f 0b 27
<1>Unable to handle kernel NULL pointer dereference at virtual address 0099
printing eip:
c015a51b
*pde =
Oops: [#2]
last sysfs file:
Modules linked in: isofs pktcdvd autofs4 lp parport_pc parport snd_seq_oss
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_ens1371 gameport
snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd
soundcore af_packet floppy ne2k_pci 8390 ide_cd cdrom ohci1394 ieee1394 loop
aes_i586 dm_crypt nls_iso8859_1 nls_cp850 vfat fat reiser4 zlib_deflate
zlib_inflate reiserfs pcspkr via_agp agpgart dm_mod joydev usbhid uhci_hcd
usbcore video hotkey configfs
CPU:0
EIP:0060:[dcache_shrinker_add+16/52]Not tainted VLI
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202 (2.6.13-rc3-mm1)
EIP is at dcache_shrinker_add+0x10/0x34
eax: 0001 ebx: c712fdb0 ecx: c5d13f70 edx: cffddfd8
esi: cffddfd8 edi: c6e62b60 ebp: c712fda8 esp: c712fda4
ds: 007b es: 007b ss: 0068
Process gnome-settings- (pid: 5078, threadinfo=c712e000 task=c708d050)
Stack: c5d13f70 c712fdcc c015a776 c712fdb8 c026b5cc cffddfd8 c02217e7 0008
c6e62b60 c712fdd4 c015a810 c712fdf4 c0148546 c6f22504 cffe04e0
c5d13f70 c6e62b60 c131f040 c712fe00 c0148422 c6e62b60 c712fe14
Call Trace:
[show_stack+118/126] show_stack+0x76/0x7e
[] show_stack+0x76/0x7e
[show_registers+234/338] show_registers+0xea/0x152
[] show_registers+0xea/0x152
[die+194/316] die+0xc2/0x13c
[] die+0xc2/0x13c
[do_page_fault+916/1344] do_page_fault+0x394/0x540
[] do_page_fault+0x394/0x540
[error_code+79/84] error_code+0x4f/0x54
[] error_code+0x4f/0x54
[dput_recursive+326/466] dput_recursive+0x146/0x1d2
[] dput_recursive+0x146/0x1d2
[dput+14/16] dput+0xe/0x10
[] dput+0xe/0x10
[__fput+287/354] __fput+0x11f/0x162
[] __fput+0x11f/0x162
[fput+46/51] fput+0x2e/0x33
[] fput+0x2e/0x33
[filp_close+78/88] filp_close+0x4e/0x58
[] filp_close+0x4e/0x58
[put_files_struct+132/183] put_files_struct+0x84/0xb7
[] put_files_struct+0x84/0xb7
[do_exit+376/844] do_exit+0x178/0x34c
[] do_exit+0x178/0x34c
[do_divide_error+0/153] do_divide_error+0x0/0x99
[] do_divide_error+0x0/0x99
[do_page_fault+916/1344] do_page_fault+0x394/0x540
[] do_page_fault+0x394/0x540
[error_code+79/84] error_code+0x4f/0x54
[] error_code+0x4f/0x54
[do_readv_writev+514/572] do_readv_writev+0x202/0x23c
[] do_readv_writev+0x202/0x23c
[vfs_writev+64/71] vfs_writev+0x40/0x47
[] vfs_writev+0x40/0x47
[sys_writev+59/147] sys_writev+0x3b/0x93
[] sys_writev+0x3b/0x93
[sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75
[] sysenter_past_esp+0x54/0x75
Re: 2.6.13-rc3-mm1: a regression
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > On Friday, 15 of July 2005 10:36, Andrew Morton wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/ > > > > (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until > > kernel.org syncs up) > > There seems to be a regression wrt 2.6.13-rc3 which causes my box (Asus L5D, > Athlon 64 + nForce3) to hang solid during resume from disk on battery power. > > First, 2.6.13-rc3-mm1 is affected by the problems described at: > http://bugzilla.kernel.org/show_bug.cgi?id=4416 > http://bugzilla.kernel.org/show_bug.cgi?id=4665 > These problems go away after applying the two attached patches. Then, the > box resumes on AC power but hangs solid during resume on battery power. > The problem is 100% reproducible and I think it's related to ACPI. That recent acpi merge seems to have damaged a number of people... Are you able to test Linus's latest -git spanshot? See if there's a difference between -linus and -mm behaviour? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.4 hotfix] Linux-2.4.31-hf2, Linux-2.4.30-hf5, Linux-2.4.29-hf12
Hi, Here is a new 2.4 hotfix. Nothing alarming, though. I reverted the netlink socket hashing bug fix that I took from Davem's tree and introduced in 2.4.31-hf1 because Marcelo informed me that Davem says it's broken and a better fix is needed. It was also a right moment to merge Julien Tinnes' NULL dereference patches for serial drivers. Strictly speaking, those missing checks do not seem immediately exploitable, but a more complete audit of the callers would be necessary to prove that. And it is clearly possible that external patches expect those functions to do the check themselves. Older kernels 2.4.29 and 2.4.30 are still maintained because they're still downloaded (for reference, 2.4.29-hf11=10%, 2.4.30-hf4=6%, 2.4.31-hf1=84%). Please find the changelog appended to this mail. Incremental patches and tarballs for 2.4.29-hf12, 2.4.30-hf5 and 2.4.31-hf2 are available from the usual place : http://linux.exosec.net/kernel/2.4-hf/ I've only built 2.4.31-hf2 with all modules enabled to ensure that patches were correct. Grant Coady regularly builds, and runs recent updates and reports results here : http://scatter.mine.nu/linux-2.4-hotfix/ Regards, Willy --- Changelog From 2.4.31-hf1 to 2.4.31-hf2 (semi-automated) --- '+' = added ; '-' = removed - 2.4.31-sparc64-solaris-emu-check-cmsg-len-1 (David S. Miller) David told Marcelo this patch was not correct and that a better fix will follow later. + 2.4.31-null-deref-cyclades-1 (Julien Tinnes) Fix two potential NULL dereferences in drivers/char/cyclades.c + 2.4.31-null-deref-esp-1 (Julien Tinnes) Fix two potential NULL dereferences in drivers/char/esp.c + 2.4.31-null-deref-isicom-1(Julien Tinnes) Fix two potential NULL dereferences in drivers/char/isicom.c + 2.4.31-null-deref-mxser-1 (Julien Tinnes) Fix two potential NULL dereferences in drivers/char/mxser.c + 2.4.31-null-deref-riscom8-1 (Julien Tinnes) Fix two potential NULL dereferences in drivers/char/riscom8.c + 2.4.31-null-deref-specialix-1 (Julien Tinnes) Fix two potential NULL dereferences in drivers/char/specialix.c --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] forcedeth: TX handler changes (experimental)
Daniel Drake wrote: So, you want this instead: #define DEV_HAS_LARGEDESC0x0004 Autsch. Yes, you are right. Sorry for that, I should have reread the patch once more. I've fixed it on my website. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-mm1: a regression
On Friday, 15 of July 2005 10:36, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
>
> (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until
> kernel.org syncs up)
There seems to be a regression wrt 2.6.13-rc3 which causes my box (Asus L5D,
Athlon 64 + nForce3) to hang solid during resume from disk on battery power.
First, 2.6.13-rc3-mm1 is affected by the problems described at:
http://bugzilla.kernel.org/show_bug.cgi?id=4416
http://bugzilla.kernel.org/show_bug.cgi?id=4665
These problems go away after applying the two attached patches. Then, the
box resumes on AC power but hangs solid during resume on battery power.
The problem is 100% reproducible and I think it's related to ACPI.
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"
--- linux-2.6.13-rc3-mm1/drivers/acpi/pci_link.c 2005-07-15 13:18:24.0 +0200
+++ new/drivers/acpi/pci_link.c 2005-07-15 13:19:30.0 +0200
@@ -72,12 +72,10 @@
u8 active; /* Current IRQ */
u8 edge_level; /* All IRQs */
u8 active_high_low; /* All IRQs */
+ u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
- u8 initialized:1;
- u8 suspend_resume:1;
- u8 reserved:6;
};
struct acpi_pci_link {
@@ -532,10 +530,6 @@
ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");
- if (link->irq.suspend_resume) {
- acpi_pci_link_set(link, link->irq.active);
- link->irq.suspend_resume = 0;
- }
if (link->irq.initialized)
return_VALUE(0);
@@ -719,21 +713,34 @@
return_VALUE(result);
}
-static int irqrouter_suspend(struct sys_device *dev, pm_message_t state)
+
+static int acpi_pci_link_resume(struct acpi_pci_link *link)
+{
+ ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
+
+ if (link->irq.active && link->irq.initialized)
+ return_VALUE(acpi_pci_link_set(link, link->irq.active));
+ else
+ return_VALUE(0);
+}
+
+
+static int irqrouter_resume(struct sys_device *dev)
{
struct list_head*node = NULL;
struct acpi_pci_link*link = NULL;
- ACPI_FUNCTION_TRACE("irqrouter_suspend");
+ ACPI_FUNCTION_TRACE("irqrouter_resume");
list_for_each(node, _link.entries) {
+
link = list_entry(node, struct acpi_pci_link, node);
if (!link) {
ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid link context\n"));
continue;
}
- if (link->irq.active && link->irq.initialized)
- link->irq.suspend_resume = 1;
+
+ acpi_pci_link_resume(link);
}
return_VALUE(0);
}
@@ -848,7 +855,7 @@
static struct sysdev_class irqrouter_sysdev_class = {
set_kset_name("irqrouter"),
-.suspend = irqrouter_suspend,
+.resume = irqrouter_resume,
};
--- 2.6.12-rc3-mm2-old/drivers/acpi/ec.c 2005-05-01 13:13:43.0 +0200
+++ linux-2.6.12-rc3-mm2/drivers/acpi/ec.c 2005-05-01 14:08:12.0 +0200
@@ -31,7 +31,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -50,19 +49,17 @@ ACPI_MODULE_NAME ("acpi_ec")
#define ACPI_EC_FLAG_OBF 0x01 /* Output buffer full */
#define ACPI_EC_FLAG_IBF 0x02 /* Input buffer full */
-#define ACPI_EC_FLAG_BURST 0x10 /* burst mode */
#define ACPI_EC_FLAG_SCI 0x20 /* EC-SCI occurred */
#define ACPI_EC_EVENT_OBF 0x01 /* Output buffer full */
#define ACPI_EC_EVENT_IBE 0x02 /* Input buffer empty */
-#define ACPI_EC_DELAY 50 /* Wait 50ms max. during EC ops */
+#define ACPI_EC_UDELAY 100 /* Poll @ 100us increments */
+#define ACPI_EC_UDELAY_COUNT 1000 /* Wait 10ms max. during EC ops */
#define ACPI_EC_UDELAY_GLK 1000 /* Wait 1ms max. to get global lock */
#define ACPI_EC_COMMAND_READ 0x80
#define ACPI_EC_COMMAND_WRITE 0x81
-#define ACPI_EC_BURST_ENABLE 0x82
-#define ACPI_EC_BURST_DISABLE 0x83
#define ACPI_EC_COMMAND_QUERY 0x84
static int acpi_ec_add (struct acpi_device *device);
@@ -90,11 +87,7 @@ struct acpi_ec {
struct acpi_generic_address command_addr;
struct acpi_generic_address data_addr;
unsigned long global_lock;
- unsigned int expect_event;
- atomic_t leaving_burst; /* 0 : No, 1 : Yes, 2: abort*/
- atomic_t pending_gpe;
- struct semaphore sem;
- wait_queue_head_t wait;
+ spinlock_t lock;
};
/* If we find an EC via the ECDT, we need to keep a ptr to its context */
@@ -107,138 +100,59 @@ static struct acpi_device *first_ec;
Transaction Management
-- */
-static inline u32 acpi_ec_read_status(struct acpi_ec *ec)
-{
- u32 status = 0;
-
- acpi_hw_low_level_read(8, , >status_addr);
- return status;
-}
-
-static int acpi_ec_wait(struct acpi_ec *ec, unsigned int event)
+static int
+acpi_ec_wait (
+ struct acpi_ec *ec,
+ u8 event)
{
- int result = 0;
-
- ACPI_FUNCTION_TRACE("acpi_ec_wait");
+ u32 acpi_ec_status = 0;
+ u32
Re: 2.6.12 vs. /sbin/cardmgr
Hi! On Sat, Jul 16, 2005 at 11:36:45AM -0500, Bob Tracy wrote: > rct wrote: > > Dominik Brodowski wrote: > > > On Sun, Jul 10, 2005 at 03:37:22PM -0500, Bob Tracy wrote: > > > > Dominik Brodowski wrote: > > > > > On Sat, Jul 09, 2005 at 12:12:17AM -0500, Bob Tracy wrote: > > > > > > (/sbin/cardmgr chewing up lots of CPU cycles with 2.6.12 kernel) > > > > > > > > > > Please post the output of "lspci" and "lsmod" as I'd like to know > > > > > which > > > > > kind of PCMCIA bridge is in your notebook. > > > > > > OK, it's a plain TI1225. Could you try whether the bug is still existent > > > in > > > 2.6.13-rc3, please? > > > > 2.6.13-rc3 works fine here. The "cardmgr" process is no longer chewing > > up lots of CPU time, and otherwise seems to be working correctly. Thanks! > > I spoke too soon :-(. The first boot on 2.6.13-rc3 was fine. Every > boot since then has reflected no change relative to the 2.6.12 behavior. > The "cardmgr" process racks up CPU time almost as fast as time > elapses: it's at the top of the "top" list. Can you send me a dmesg of 2.6.13-rc3, please? Thanks, Dominik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] forcedeth: TX handler changes (experimental)
Daniel Drake wrote: After applying the v0.38 patch, I can't get any network at all. DHCP fails to get an IP. v0.37 works fine. Tracked it down. (sorry for linewraps) +#define DEV_NEED_TIMERIRQ 0x0001 /* set the timer irq flag in the irq mask */ +#define DEV_NEED_LINKTIMER 0x0002 /* poll link settings. Relies on the timer irq */ +#define DEV_HAS_LARGEDESC 0x0003 /* device supports jumbo frames and needs packet format 2 */ My hardware is NEED_TIMERIRQ|NEED_LINKTIMER, however, by this logic, it'll also be DEV_HAVE_LARGEDESC, which isn't true. So, you want this instead: #define DEV_HAS_LARGEDESC 0x0004 After making that change, all is working fine, but then again, I've never run into the hangs you are debugging. I'll follow up in a couple of days time to confirm I'm not getting any problems with the new code. Thanks, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
relayfs documentation sucks?
Ok, I'm working furiously on my OLS presentation (Wednesday, 3pm, be there), but I'm running into a wall with relayfs, which I intend to use to convey large amounts of disk statistics towards userspace. Now, I've read Documentation/filesystems/relayfs.txt many times over, and I don't get it. It appears there is relayfs, and 'klog' on top of that. It also appears that to access relayed data from the kernel in userspace there is librelay.c. On reading librelay.c, I find code sending and receiving netlink messages, but relayfs.txt doesn't even contain the word netlink! I then launched the 'kleak-app' sample program, but told it to look at /relay/diskstat* instead of its own file, but it gives me unspecified netlink errors. Things I need to know, and which I hope to find documented somewhere: 1) Do I need to do the netlink thing? 2) What kind of messages do I need to send/receive? 3) What is the exact format userspace sees in the relayfs file? Iow, can I access that file w/o using librelay.c? 4) What are the semantics for reading from that file? 5) When using klog, is there only one channel? 6) does librelay.c talk to regular relayfs or to klog? Don't get me wrong, relayfs sure looks nice for what I'm trying to do but from userspace it is sort of a black box right now.. Thanks! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel Panic: VFS cannot open a root device
> Hi , i have kernel 2.4.29 at slack 10.1 and when I upgrade my kernel to > 2.6.11 I get these erros on booting > > VFS: Cannot open a root device "301" or unknow block > please append a correct "root" boot option > KERNEL PANIC : not syncing; VFS; Unable to mount root fs on unknown-block > (3,1) > > I have compiled my kernel with my IDE support and also with my file system > support with built-in option. > > My LILO.CONF > image = /boot/vmlinuz-2.6.11 > root = /dev/hda1 > label = 2.6.11 > initrd = /boot/initrd.gz > read-only > > I googled this problem, and I think is a kind of bug, and i tryed to patch > the kernel with Alan Cox patch 2.6.11-ac7.bzip and I get these :: > bzip2 -dc /usr/src/patch-2.6.11.ac7.bzip | patch -p1 -s > 1 out of hunk FAILED --saving rejects to file Makefike.rej > > and I cat the file Makefile.rej > > *** > *** 1,8 > VERSION = 2 > PATCHLEVEL = 6 > SUBLEVEL = 11 > - EXTRAVERSION = > - NAME=Woozy Numbat > > # *DOCUMENTATION* > # To see a list of typical targets execute "make help" > --- 1,8 > VERSION = 2 > PATCHLEVEL = 6 > SUBLEVEL = 11 > + EXTRAVERSION = ac7 > + NAME=AC > > # *DOCUMENTATION* > # To see a list of typical targets execute "make help" > > I'm stuck! The patch dont work fine ( I think the patch is not installed > succesfully on my kernel ) > I'm booting with my image of kernel 2.4.29. i'm 5 days tryng to solve > this problem ... > any kind of help is wellcome... sorry for my english. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS and fifos.
On 7/16/05, Willy Tarreau <[EMAIL PROTECTED]> wrote: > On Sat, Jul 16, 2005 at 11:25:01PM +0530, Dhruv Matani wrote: > > On 7/16/05, Jesper Juhl <[EMAIL PROTECTED]> wrote: > > > On 7/16/05, Dhruv Matani <[EMAIL PROTECTED]> wrote: > > > > On 7/16/05, Arvind Kalyan <[EMAIL PROTECTED]> wrote: > > > > > On 7/16/05, Dhruv Matani <[EMAIL PROTECTED]> wrote: > > > > > > Hello, > > > > > > I can't seem to be able to use fifos on an NFS mount. Is there any > > > > > > reason why this is disallowed, or is this is a bug? v.2.4.20. > > > > > > > > > > Are both the processes (reader/writer) on the same machine? FIFOs are > > > > > local objects. > > > > > > > > Yes, but I'm accessing them through my remote[public] IP address. > > > > The idea behind it is to have a fifo that works across the network > > > > through an NFS mount. Is that possible? > > > > > > > > I serched google for 'socket file', and all that I got was 'fifo', but > > > > they are to be used only on a singl machine for communication between > > > > 2 or more applications, but couldn't find any file abstraction for > > > > communication for processes on distinct machines. Do you know of any > > > > such thing, cause I couldn't find any. > > > > > > > > > > sockets. > > > > Are sockets named files? > > Unix sockets, yes. Look at /dev/log or /tmp/.X11-unix/X0 for example. > But they are local anyway, you cannot use them between two systems. > And for communicating between two systems TCP or UDP sockets work just fine. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] lib/int_sqrt.c: speedup compilation
It uses only EXPORT_SYMBOL, so... Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> --- lib/int_sqrt.c |2 -- 1 files changed, 2 deletions(-) --- linux-vanilla/lib/int_sqrt.c2005-07-16 02:05:11.0 +0400 +++ linux-int_sqrt/lib/int_sqrt.c 2005-07-16 03:11:38.0 +0400 @@ -1,5 +1,3 @@ - -#include #include /** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Interbench v0.20 - Interactivity benchmark
On Thu, 2005-07-14 at 09:57 +1000, Con Kolivas wrote:
> On Thu, 14 Jul 2005 03:34, Lee Revell wrote:
> > On Wed, 2005-07-13 at 13:27 +0200, szonyi calin wrote:
> > > I have the following problem with audio:
> > > Xmms is running with threads for audio and spectrum
> > > analyzer(OpenGL).
> > > The audio eats 5% cpu, the spectrum analyzer about 80 %. The
> > > problem is that sometimes the spectrum analyzer is eating all of
> > > the cpu while the audio is skipping. Xmms is version 1.2.10
> > > kernel is vanilla, latest "stable" version 2.6.12, suid root.
> > >
> > > Does your benchmark simultes this kind of behaviour ?
> >
> > That's just a broken app, the kernel can't do anything about it. XMMS
> > should not be running the spectrum analyzer thread at such a high
> > priority as to interfere with the audio thread.
>
> I agree; optimising for this is just silly.
I took a closer look and it's indeed quite broken. If XMMS is run in
realtime mode, and multithreading is enabled, it runs everything
SCHED_RR - GUI, audio, spectrum analyzer. (And since it relies on new
threads inheriting RT scheduling when pthread_create()'d, the threads
will fail to get SCHED_RR on buggy NPTL versions like the one in Debian
Sarge).
This untested patch should enable RT scheduling for only the (ALSA)
audio thread. Make sure NOT to run in realtime mode.
Lee
--- ../xmms-1.2.10+cvs20050209.orig/Output/alsa/audio.c 2005-01-31
17:45:08.0 -0500
+++ Output/alsa/audio.c 2005-07-16 16:06:06.0 -0400
@@ -962,6 +962,7 @@
/* open callback */
int alsa_open(AFormat fmt, int rate, int nch)
{
+ struct sched_param sparam;
debug("Opening device");
inputf = snd_format_from_xmms(fmt, rate, nch);
effectf = snd_format_from_xmms(fmt, rate, nch);
@@ -1010,6 +1011,9 @@
flush_request = -1;
pthread_create(_thread, NULL, alsa_loop, NULL);
+ sparam.sched_priority = sched_get_priority_max(SCHED_FIFO);
+ if (pthread_setschedparam (audio_thread, SCHED_FIFO, ) )
+ fprintf(stderr, "Error %s getting SCHED_FIFO for audio
thread\n", strerror (errno));
}
return 1;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Sandisk Compact Flash
So then you will have to reboot sometimes. BTW, IDE can be hot swapped if you are carefull: Umount the device, unplug it. Plug in the same device (same model) Remount. A bit risky to your hardware, but I have used this way for harddisks several time when a system has to keep running. Never used it for compact flash though. Another option: Buy an USB card controller or a pcmcia controller for in your pc. Costs about $10,- Op zaterdag 16 juli 2005 18:31, schreef u: > On Sat, Jul 16, 2005 at 03:04:54AM -0400, Michael Krufky wrote: > > I recommend picking up a CF-to-IDE adapter, such as this: > > > > http://www.acscontrol.com/Index_ACS.asp?Page=/Pages/Products/CompactFlash > >/IDE_To_CF_Adapter.htm > > That's fine if you have a spare IDE port, but unlikely if you're > using a laptop. Also these do not support hot swapping. > > -- Dave > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] forcedeth: TX handler changes (experimental)
Hi, Manfred Spraul wrote: Attached is a patch that modifies the tx interrupt handling of the nForce nic. It's part of the attempts to figure out what causes the nic hangs (see bug 4552). The change is experimental: It affects all nForce versions. I've tested it on my nForce 250-Gb. Please test it. And especially: If you experince a nic hang, please send me the debug output. That's the block starting with << NETDEV WATCHDOG: eth1: transmit timed out eth1: Got tx_timeout. irq: eth1: Ring at ... << After applying the v0.38 patch, I can't get any network at all. DHCP fails to get an IP. v0.37 works fine. I enabled debugging, and I get this failure for every packet being transmitted: ( i masked out part of my MAC addr with XX ) Jul 16 20:06:28 dsd eth0: nv_start_xmit: packet packet 3 queued for transmission. Jul 16 20:06:28 dsd Jul 16 20:06:28 dsd 000: ff ff ff ff ff ff 00 50 8d XX XX XX 08 00 45 00 Jul 16 20:06:28 dsd 010: 02 40 75 a0 00 00 40 11 03 0e 00 00 00 00 ff ff Jul 16 20:06:28 dsd 020: ff ff 00 44 00 43 02 2c 13 0a 01 01 06 00 d2 76 Jul 16 20:06:28 dsd 030: bc 10 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 Jul 16 20:06:28 dsd eth0: nv_nic_irq Jul 16 20:06:28 dsd eth0: irq: 0008 Jul 16 20:06:28 dsd eth0: nv_tx_done: looking at packet 3, Flags 0x624d. Jul 16 20:06:28 dsd eth0: received irq with events 0x8. Probably TX fail. Jul 16 20:06:28 dsd eth0: irq: Jul 16 20:06:28 dsd eth0: nv_nic_irq completed My hardware: :00:04.0 Class 0200: 10de:0066 (rev a1) :00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet Controller (rev a1) Subsystem: ABIT Computer Corp.: Unknown device 1c00 Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 17 Memory at e0087000 (32-bit, non-prefetchable) [size=4K] I/O ports at b000 [size=8] Capabilities: [44] Power Management version 2 Here's the start of the logs: Jul 16 20:05:27 dsd forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.38. Jul 16 20:05:27 dsd ACPI: PCI Interrupt :00:04.0[A] -> Link [APCH] -> GSI 21 (level, high) -> IRQ 17 Jul 16 20:05:27 dsd PCI: Setting latency timer of device :00:04.0 to 64 Jul 16 20:05:27 dsd :00:04.0: resource 0 start e0087000 len 4096 flags 0x0200. Jul 16 20:05:27 dsd :00:04.0: MAC Address 00:50:8d:XX:XX:XX Jul 16 20:05:27 dsd :00:04.0: link timer on. Jul 16 20:05:27 dsd eth%d: mii_rw read from reg 2 at PHY 1: 0x0. Jul 16 20:05:27 dsd eth%d: mii_rw read from reg 3 at PHY 1: 0x8201. Jul 16 20:05:27 dsd :00:04.0: open: Found PHY :0020 at address 1. Jul 16 20:05:27 dsd eth%d: mii_rw read from reg 4 at PHY 1: 0x1e1. Jul 16 20:05:27 dsd eth%d: mii_rw wrote 0xde1 to reg 4 at PHY 1 Jul 16 20:05:27 dsd eth%d: mii_rw read from reg 1 at PHY 1: 0x786d. Jul 16 20:05:27 dsd eth%d: mii_rw read from reg 0 at PHY 1: 0x3100. Jul 16 20:05:27 dsd eth%d: mii_rw wrote 0xb100 to reg 0 at PHY 1 Jul 16 20:05:28 dsd eth%d: mii_rw read from reg 0 at PHY 1: 0x3000. Jul 16 20:05:28 dsd eth%d: mii_rw read from reg 0 at PHY 1: 0x3000. Jul 16 20:05:28 dsd eth%d: mii_rw wrote 0x3200 to reg 0 at PHY 1 Jul 16 20:05:28 dsd eth0: forcedeth.c: subsystem: 0147b:1c00 bound to :00:04.0 Jul 16 20:05:28 dsd rc-scripts: Configuration not set for eth0 - assuming dhcp Jul 16 20:05:28 dsd nv_open: begin Jul 16 20:05:28 dsd eth0: nv_alloc_rx: Packet 0 marked as Available Jul 16 20:05:28 dsd eth0: nv_alloc_rx: Packet 1 marked as Available Jul 16 20:05:28 dsd eth0: nv_alloc_rx: Packet 2 marked as Available Jul 16 20:05:28 dsd eth0: nv_alloc_rx: Packet 125 marked as Available Jul 16 20:05:28 dsd eth0: nv_alloc_rx: Packet 126 marked as Available Jul 16 20:05:28 dsd eth0: nv_alloc_rx: Packet 127 marked as Available Jul 16 20:05:28 dsd eth0: nv_txrx_reset Jul 16 20:05:28 dsd startup: got 0x0010. Jul 16 20:05:28 dsd eth0: mii_rw read from reg 1 at PHY 1: 0x7849. Jul 16 20:05:28 dsd eth0: mii_rw read from reg 1 at PHY 1: 0x7849. Jul 16 20:05:28 dsd eth0: no link detected by phy - falling back to 10HD. Jul 16 20:05:28 dsd eth0: nv_start_rx Jul 16 20:05:28 dsd eth0: nv_start_rx to duplex 0, speed 0x000103e8. Jul 16 20:05:28 dsd eth0: nv_start_tx Jul 16 20:05:28 dsd eth0: no link during initialization. Jul 16 20:05:28 dsd eth0: nv_stop_rx Jul 16 20:05:28 dsd eth0: reconfiguration for multicast lists. Jul 16 20:05:28 dsd eth0: nv_start_rx Jul 16 20:05:28 dsd eth0: nv_start_rx to duplex 0, speed 0x000103e8. Jul 16 20:05:28 dsd eth0: nv_stop_rx Jul 16 20:05:28 dsd eth0: reconfiguration for multicast lists. Jul 16 20:05:28 dsd eth0: nv_start_rx Jul 16 20:05:28 dsd eth0: nv_start_rx to duplex 0, speed 0x000103e8. Jul 16 20:05:28 dsd eth0: nv_stop_rx Jul 16 20:05:28 dsd eth0: reconfiguration for multicast lists. Jul 16 20:05:28 dsd eth0: nv_start_rx Jul 16 20:05:28 dsd eth0: nv_start_rx to duplex 0, speed 0x000103e8. Let me know if full logs would be useful (they are big, and it just shows a lot of interrupts, some packets being
Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
* Karsten Wiese <[EMAIL PROTECTED]> wrote: > This is it. Apply it on top of -51-30 and 'make oldconfig'. You'll be > asked about the new CONFIG_ONE_IOAPIC. Answering yes, io_apic_one.c > will be used, which is ((io_apic.c minus quirks) minus > multi_io_apic_capability) . It'll propably crash some machines, as the > quirks are there for some reason... With CONFIG_ONE_IOAPIC unset, > you'll get the same kernel as with my previously sent patch. have fun > :-) this could only be offered if it's merged into the existing io_apic.c. The current IOAPIC_FAST option will go away eventually, but ONE_IOAPIC would/could be intentionally incompatible. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Ingo Molnar wrote: > * Karsten Wiese <[EMAIL PROTECTED]> wrote: > > >>Have I corrected the other path of ioapic early initialization, which >>had lacked virtual-address setup before ioapic_data[ioapic] was to be >>filled in -51-28? Please test attached patch on top of -51-29 or >>later. Also on Systems that liked -51-28. > > > thanks - i've applied it to my tree and have released the -51-31 patch. > It looks good on my testboxes. > > Ingo > I have booted this on my older SMP system (the one that wouldn't boot -51-28) as well as an older duron box and thus far all is well. -- kr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Volatile vs Non-Volatile Spin Locks on SMP.
[EMAIL PROTECTED] wrote: Hello, By using volatile keyword for spin lock defined by in spinlock_t, it seems Linux choose to always reload the value of spin locks from cache instead of using the content from registers. This may be helpful for synchronization between multithreads in a single CPU. I use two Xeon cpus with HyperThreading being disabled on both cpus. I think the MESI protocol will enforce the cache coherency and update the spin lock value automatically between these two cpus. So maybe we don't need to use the volatile any more, right? The value must always be loaded from memory. If the value is cached in a register it will not update when another CPU changes it. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: init 0 stopped working
Hi, On 7/16/05, Martin Mokrejs <[EMAIL PROTECTED]> wrote: > Hi, > I used to shutdown my P4 machine based on ASUS P4C800E-Deluxe > with simple "init 0" command. That somehow broke between 2.6.12-rc6-git2 > and 2.6.13-rc1. The machines makes the sound like shutdown but it > immediately turns the power on again. I used acpi and the kernel > configs should be almost identical in all cases, as I just recopy > previously used .config and run "make oldconfig". > > Any clues? I still happens even with 2.6.13-rc3-git2. > Please Cc: me in replies. > Martin I have the same problem. System: Debian 3.1 Hardware: motherboard P4P800 (with bios 1019) It may be problem around acpi in asus board. But 2.6.12.1 works good. Regards, Michal Piotrowski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sandisk Compact Flash
On Sat, Jul 16, 2005 at 03:04:54AM -0400, Michael Krufky wrote: > I recommend picking up a CF-to-IDE adapter, such as this: > > http://www.acscontrol.com/Index_ACS.asp?Page=/Pages/Products/CompactFlash/IDE_To_CF_Adapter.htm That's fine if you have a spare IDE port, but unlikely if you're using a laptop. Also these do not support hot swapping. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS and fifos.
On Sat, Jul 16, 2005 at 11:25:01PM +0530, Dhruv Matani wrote: > On 7/16/05, Jesper Juhl <[EMAIL PROTECTED]> wrote: > > On 7/16/05, Dhruv Matani <[EMAIL PROTECTED]> wrote: > > > On 7/16/05, Arvind Kalyan <[EMAIL PROTECTED]> wrote: > > > > On 7/16/05, Dhruv Matani <[EMAIL PROTECTED]> wrote: > > > > > Hello, > > > > > I can't seem to be able to use fifos on an NFS mount. Is there any > > > > > reason why this is disallowed, or is this is a bug? v.2.4.20. > > > > > > > > Are both the processes (reader/writer) on the same machine? FIFOs are > > > > local objects. > > > > > > Yes, but I'm accessing them through my remote[public] IP address. > > > The idea behind it is to have a fifo that works across the network > > > through an NFS mount. Is that possible? > > > > > > I serched google for 'socket file', and all that I got was 'fifo', but > > > they are to be used only on a singl machine for communication between > > > 2 or more applications, but couldn't find any file abstraction for > > > communication for processes on distinct machines. Do you know of any > > > such thing, cause I couldn't find any. > > > > > > > sockets. > > Are sockets named files? Unix sockets, yes. Look at /dev/log or /tmp/.X11-unix/X0 for example. But they are local anyway, you cannot use them between two systems. Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS and fifos.
On 7/16/05, Jesper Juhl <[EMAIL PROTECTED]> wrote: > On 7/16/05, Dhruv Matani <[EMAIL PROTECTED]> wrote: > > On 7/16/05, Arvind Kalyan <[EMAIL PROTECTED]> wrote: > > > On 7/16/05, Dhruv Matani <[EMAIL PROTECTED]> wrote: > > > > Hello, > > > > I can't seem to be able to use fifos on an NFS mount. Is there any > > > > reason why this is disallowed, or is this is a bug? v.2.4.20. > > > > > > Are both the processes (reader/writer) on the same machine? FIFOs are > > > local objects. > > > > Yes, but I'm accessing them through my remote[public] IP address. > > The idea behind it is to have a fifo that works across the network > > through an NFS mount. Is that possible? > > > > I serched google for 'socket file', and all that I got was 'fifo', but > > they are to be used only on a singl machine for communication between > > 2 or more applications, but couldn't find any file abstraction for > > communication for processes on distinct machines. Do you know of any > > such thing, cause I couldn't find any. > > > > sockets. Are sockets named files? > > -- > Jesper Juhl <[EMAIL PROTECTED]> > Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html > Plain text mails only, please http://www.expita.com/nomime.html > -- -Dhruv Matani. http://www.geocities.com/dhruvbird/ The race of quality has no finish line. ~Anon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] latency logger for realtime-preempt-2.6.12-final-V0.7.51-30
* yangyi <[EMAIL PROTECTED]> wrote: > Hi, Ingo > > This patch can record interrupt-off latency, preemption-off latency > and wakeup latency in a big history array, in the meanwhile, it > dummies up printks produced by these latency timing. looks pretty good! I'll look at merging your patch after KS/OLS. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm1: horribly drivers/scsi/qla2xxx/Makefile
Andrew Vasquez wrote: > Yes, quite. How about the following to correct the intention. > > > > Add correct Kconfig option for ISP24xx support. > > Signed-off-by: Andrew Vasquez <[EMAIL PROTECTED]> > --- > > diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig > --- a/drivers/scsi/qla2xxx/Kconfig > +++ b/drivers/scsi/qla2xxx/Kconfig > @@ -39,3 +39,11 @@ config SCSI_QLA6312 > ---help--- > This driver supports the QLogic 63xx (ISP6312 and ISP6322) host > adapter family. > + > +config SCSI_QLA24XX > + tristate "QLogic ISP24xx host adapter family support" > + depends on SCSI_QLA2XXX > +select SCSI_FC_ATTRS there should be also "select FW_LOADER", as it uses request_firmware & release_firmware > + ---help--- > + This driver supports the QLogic 24xx (ISP2422 and ISP2432) host > + adapter family. -- Jindrich Makovicka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: compiling Kernel Modules with debugging information enabled
Le 16.07.2005 19:11, k8 s a écrit : > To be more clear, say I have selected CONFIG_XFRM=y in .config file > I want to make a change such that net/xfrm/Makefile has an entry > CFLAGS += -g so that it generates debugging information for all the > modules in that directory Look at Documentation/kbuild/makefiles.txt: You can add some CFLAGS for a single object file with: CFLAGS_foo.o += -g For all objects defined in a Makefile: EXTRA_CFLAGS = +g Brice - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Realtime Preemption, 2.6.12, Beginners Guide?
* Karsten Wiese <[EMAIL PROTECTED]> wrote: > Have I corrected the other path of ioapic early initialization, which > had lacked virtual-address setup before ioapic_data[ioapic] was to be > filled in -51-28? Please test attached patch on top of -51-29 or > later. Also on Systems that liked -51-28. thanks - i've applied it to my tree and have released the -51-31 patch. It looks good on my testboxes. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
* Daniel Walker <[EMAIL PROTECTED]> wrote: > On Tue, 2005-07-12 at 07:56 -0700, Daniel Walker wrote: > > On Tue, 2005-07-12 at 16:46 +0200, Ingo Molnar wrote: > > > * Daniel Walker <[EMAIL PROTECTED]> wrote: > > > > > > > I haven't tested it recently . This was on an older version of RT > > > > though . I could try it if it's interesting ? Or do you think it's > > > > already fixed? > > > > > > it would be definitely interesting to see how robust the latest IO-APIC > > > code is. > > > > I'm sure you test that all the time, but I'll try it .. > > I tried it, and it appears to be fixed in current RT .. cool, thanks. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
compiling Kernel Modules with debugging information enabled
Hello, How can I compile a kernel module ,that is statically compiled at the kernel compilation time, with debugging information. To be more clear, say I have selected CONFIG_XFRM=y in .config file I want to make a change such that net/xfrm/Makefile has an entry CFLAGS += -g so that it generates debugging information for all the modules in that directory I successfully did it for dynamically compiled modules that are insmod'ed. How can I do it for statically linked modules. The idea is to do the following objdump -DS xyz.o so that I know the source lines and their assembly translations. This is useful in crashdump analysis where we get the information of S Kartikeyan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.12.3
On Fri, Jul 15, 2005 at 09:48:16PM -0700, Greg KH wrote: >... > Summary of changes from v2.6.12.2 to v2.6.12.3 > == >... > Ralf Baechle: > SMP fix for 6pack driver >... Will this patch [1] also be forward-ported to Linus' tree, or will 2.6.12.3 stay the _only_ 2.6 kernel that ever offered this driver for SMP configs? cu Adrian [1] "fix" is a wrong patch description since all it does is to remove the BROKEN_ON_SMP dependency -- "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: Module option for compiled-in parts
>> I have added a module_param() to a component that is compiled in >> (drivers/char/vt.c). Since it's not a module, will it still show a >> /sys/module/WhatGoesHere/parameters/myvariablename file? What will be put as >> "WhatGoesHere" as vt.c does not become vt.ko? I actually done it, and a /sys/module/vt popped up, as expected. >Interesting question. > >Are you adding one/some module parameters to vt.c ? Yes >I don't see any there. It's my first. >I have usbcore built-in (not a loadable module), and I still see >in /sys/module/usbcore/parameters these files: > >blinkenlights >old_scheme_first >usbfs_snoop >use_both_schemes > >but usbcore is "defined" as containing a list of .o files >in drivers/usb/core/Makefile. I don't know who's deciding what the * in /sys/module/* will be, but it seems that the module name will become the one that is listed in obj-y or obj-m, respectively. In your usb case, this would be: obj-y := usbcore usbcore-objs := blinkenlights usbfs_snoop otherfiles uhci-hcd Seems fine for me. And vt.c is one that applies to obj-y Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] forcedeth: TX handler changes (experimental)
Daniel Drake wrote:
Hi,
Manfred Spraul wrote:
Attached is a patch that modifies the tx interrupt handling of the
nForce nic. It's part of the attempts to figure out what causes the
nic hangs (see bug 4552).
The change is experimental: It affects all nForce versions. I've
tested it on my nForce 250-Gb.
This patch doesn't apply to 2.6.13-rc3:
patching file drivers/net/forcedeth.c
Hunk #1 FAILED at 87.
Hunk #2 FAILED at 100.
Hunk #3 FAILED at 135.
Hunk #4 succeeded at 145 (offset -3 lines).
Hunk #5 succeeded at 295 (offset -3 lines).
Hunk #6 succeeded at 305 (offset -3 lines).
Hunk #7 succeeded at 995 (offset -20 lines).
Hunk #8 succeeded at 1502 (offset -87 lines).
Hunk #9 succeeded at 2112 (offset -133 lines).
Hunk #10 FAILED at 2221.
4 out of 10 hunks FAILED -- saving rejects to file
drivers/net/forcedeth.c.rej
I think this is because 2.6.13-rc3 has forcedeth 0.35.
I can't find the patch for 0.35 --> 0.36. (Is this when the netdev
archives were in limbo?)
Either that, or I just forgot to cc netdev.
I've uploaded all recent patches to
http://www.colorfullife.com/~manfred/Linux-kernel/forcedeth/
0.36 is attached.
--
Manfred
--- 2.6/drivers/net/forcedeth.c 2005-06-28 22:51:26.0 +0200
+++ build-2.6/drivers/net/forcedeth.c 2005-06-28 22:51:40.0 +0200
@@ -85,6 +85,7 @@
* 0.33: 16 May 2005: Support for MCP51 added.
* 0.34: 18 Jun 2005: Add DEV_NEED_LINKTIMER to all nForce nics.
* 0.35: 26 Jun 2005: Support for MCP55 added.
+ * 0.36: 28 Jul 2005: Add jumbo frame support.
*
* Known bugs:
* We suspect that on some hardware no TX done interrupts are generated.
@@ -96,7 +97,7 @@
* DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few
* superfluous timer interrupts from the nic.
*/
-#define FORCEDETH_VERSION "0.35"
+#define FORCEDETH_VERSION "0.36"
#define DRV_NAME "forcedeth"
#include
@@ -379,9 +380,13 @@
#define TX_LIMIT_START 62
/* rx/tx mac addr + type + vlan + align + slack*/
-#define RX_NIC_BUFSIZE (ETH_DATA_LEN + 64)
-/* even more slack */
-#define RX_ALLOC_BUFSIZE (ETH_DATA_LEN + 128)
+#define NV_RX_HEADERS (64)
+/* even more slack. */
+#define NV_RX_ALLOC_PAD(64)
+
+/* maximum mtu size */
+#define NV_PKTLIMIT_1 ETH_DATA_LEN/* hard limit not known */
+#define NV_PKTLIMIT_2 9100/* Actual limit according to NVidia: 9202 */
#define OOM_REFILL (1+HZ/20)
#define POLL_WAIT (1+HZ/100)
@@ -473,6 +478,7 @@
struct sk_buff *rx_skbuff[RX_RING];
dma_addr_t rx_dma[RX_RING];
unsigned int rx_buf_sz;
+ unsigned int pkt_limit;
struct timer_list oom_kick;
struct timer_list nic_poll;
@@ -792,7 +798,7 @@
nr = refill_rx % RX_RING;
if (np->rx_skbuff[nr] == NULL) {
- skb = dev_alloc_skb(RX_ALLOC_BUFSIZE);
+ skb = dev_alloc_skb(np->rx_buf_sz + NV_RX_ALLOC_PAD);
if (!skb)
break;
@@ -805,7 +811,7 @@
PCI_DMA_FROMDEVICE);
np->rx_ring[nr].PacketBuffer = cpu_to_le32(np->rx_dma[nr]);
wmb();
- np->rx_ring[nr].FlagLen = cpu_to_le32(RX_NIC_BUFSIZE |
NV_RX_AVAIL);
+ np->rx_ring[nr].FlagLen = cpu_to_le32(np->rx_buf_sz |
NV_RX_AVAIL);
dprintk(KERN_DEBUG "%s: nv_alloc_rx: Packet %d marked as
Available\n",
dev->name, refill_rx);
refill_rx++;
@@ -831,19 +837,31 @@
enable_irq(dev->irq);
}
-static int nv_init_ring(struct net_device *dev)
+static void nv_init_rx(struct net_device *dev)
{
struct fe_priv *np = get_nvpriv(dev);
int i;
- np->next_tx = np->nic_tx = 0;
- for (i = 0; i < TX_RING; i++)
- np->tx_ring[i].FlagLen = 0;
-
np->cur_rx = RX_RING;
np->refill_rx = 0;
for (i = 0; i < RX_RING; i++)
np->rx_ring[i].FlagLen = 0;
+}
+
+static void nv_init_tx(struct net_device *dev)
+{
+ struct fe_priv *np = get_nvpriv(dev);
+ int i;
+
+ np->next_tx = np->nic_tx = 0;
+ for (i = 0; i < TX_RING; i++)
+ np->tx_ring[i].FlagLen = 0;
+}
+
+static int nv_init_ring(struct net_device *dev)
+{
+ nv_init_tx(dev);
+ nv_init_rx(dev);
return nv_alloc_rx(dev);
}
@@ -1207,15 +1225,82 @@
}
}
+static void set_bufsize(struct net_device *dev)
+{
+ struct fe_priv *np = netdev_priv(dev);
+
+ if (dev->mtu <= ETH_DATA_LEN)
+ np->rx_buf_sz = ETH_DATA_LEN + NV_RX_HEADERS;
+ else
+ np->rx_buf_sz = dev->mtu + NV_RX_HEADERS;
+}
+
/*
* nv_change_mtu: dev->change_mtu function
* Called with dev_base_lock held for read.
*/
static int nv_change_mtu(struct net_device *dev, int new_mtu)
{
- if
Re: [RFC][PATCH 1/6] new timeofday core subsystem
On 16.07.2005 [02:32:14 -0600], Frank Sorenson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> > +extern nsec_t do_monotonic_clock(void);
> This looks okay ...
>
> > +/**
> > + * do_monotonic_clock - Returns monotonically increasing nanoseconds
> > + *
> > + * Returns the monotonically increasing number of nanoseconds
> > + * since the system booted via __monotonic_clock()
> > + */
> > +nsec_t do_monotonic_clock(void)
> > +{
> > + nsec_t ret;
> > + unsigned long seq;
> > +
> > + /* atomically read __monotonic_clock() */
> > + do {
> > + seq = read_seqbegin(_time_lock);
> > +
> > + ret = __monotonic_clock();
> > +
> > + } while (read_seqretry(_time_lock, seq));
> > +
> > + return ret;
> > +}
>
> ... but this conflicts with Nish's softtimer patches, which is
> implemented slightly differently. For those of us who are real gluttons
> for punishment, and want both sets of patches, are there problems just
> removing one of the do_monotonic_clock definitions?
No, in fact, that would be expected. If you are going to apply John's
patches and mine, then you can remove the definition I put in time.c
(technically, I probably should have put that definition in a #ifndef
CONFIG_NEWTOD/#endif block).
My version is basically a non-NEWTOD attempt to get nanosecond uptime.
But, if you have John's timesources, then use them :)
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 ACPI regression and hang on x86-64
-=> Mikael Pettersson wrote to All <=- MP> With the i386 kernel, 2.6.13-rc3 mostly works, but MP> it fails to detect the CPU's C2 state. This kernel fails to boot, occasionally, stopping at the system BIOS check successful message, but got C2 back with the recent patch here. LILO version 22.5.9 and Cyrix/VIA e-machines '99. I might be able to provide more information. ... Mars' surface air pressure is less than where high-altitude jets fly here. --- MultiMail/Linux v0.46 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.12 vs. /sbin/cardmgr
rct wrote: > Dominik Brodowski wrote: > > On Sun, Jul 10, 2005 at 03:37:22PM -0500, Bob Tracy wrote: > > > Dominik Brodowski wrote: > > > > On Sat, Jul 09, 2005 at 12:12:17AM -0500, Bob Tracy wrote: > > > > > (/sbin/cardmgr chewing up lots of CPU cycles with 2.6.12 kernel) > > > > > > > > Please post the output of "lspci" and "lsmod" as I'd like to know which > > > > kind of PCMCIA bridge is in your notebook. > > > > OK, it's a plain TI1225. Could you try whether the bug is still existent in > > 2.6.13-rc3, please? > > 2.6.13-rc3 works fine here. The "cardmgr" process is no longer chewing > up lots of CPU time, and otherwise seems to be working correctly. Thanks! I spoke too soon :-(. The first boot on 2.6.13-rc3 was fine. Every boot since then has reflected no change relative to the 2.6.12 behavior. The "cardmgr" process racks up CPU time almost as fast as time elapses: it's at the top of the "top" list. -- --- Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org [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: Module option for compiled-in parts
On Sat, 16 Jul 2005 10:45:17 +0200 (MEST) Jan Engelhardt wrote: > Hi, > > > I have added a module_param() to a component that is compiled in > (drivers/char/vt.c). Since it's not a module, will it still show a > /sys/module/WhatGoesHere/parameters/myvariablename file? What will be put as > "WhatGoesHere" as vt.c does not become vt.ko? Interesting question. Are you adding one/some module parameters to vt.c ? I don't see any there. I have usbcore built-in (not a loadable module), and I still see in /sys/module/usbcore/parameters these files: blinkenlights old_scheme_first usbfs_snoop use_both_schemes but usbcore is "defined" as containing a list of .o files in drivers/usb/core/Makefile. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] forcedeth: TX handler changes (experimental)
Hi, Manfred Spraul wrote: Attached is a patch that modifies the tx interrupt handling of the nForce nic. It's part of the attempts to figure out what causes the nic hangs (see bug 4552). The change is experimental: It affects all nForce versions. I've tested it on my nForce 250-Gb. This patch doesn't apply to 2.6.13-rc3: patching file drivers/net/forcedeth.c Hunk #1 FAILED at 87. Hunk #2 FAILED at 100. Hunk #3 FAILED at 135. Hunk #4 succeeded at 145 (offset -3 lines). Hunk #5 succeeded at 295 (offset -3 lines). Hunk #6 succeeded at 305 (offset -3 lines). Hunk #7 succeeded at 995 (offset -20 lines). Hunk #8 succeeded at 1502 (offset -87 lines). Hunk #9 succeeded at 2112 (offset -133 lines). Hunk #10 FAILED at 2221. 4 out of 10 hunks FAILED -- saving rejects to file drivers/net/forcedeth.c.rej I think this is because 2.6.13-rc3 has forcedeth 0.35. I can't find the patch for 0.35 --> 0.36. (Is this when the netdev archives were in limbo?) I found the patch for 0.36 --> 0.37 here : http://marc.theaimsgroup.com/?l=linux-netdev=112101962422678=2 Are the earlier changes a prerequisite, or can I just fix the TX handler rejects manually? Thanks, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS and fifos.
On 7/16/05, Dhruv Matani <[EMAIL PROTECTED]> wrote: > On 7/16/05, Arvind Kalyan <[EMAIL PROTECTED]> wrote: > > On 7/16/05, Dhruv Matani <[EMAIL PROTECTED]> wrote: > > > Hello, > > > I can't seem to be able to use fifos on an NFS mount. Is there any > > > reason why this is disallowed, or is this is a bug? v.2.4.20. > > > > Are both the processes (reader/writer) on the same machine? FIFOs are > > local objects. > > Yes, but I'm accessing them through my remote[public] IP address. > The idea behind it is to have a fifo that works across the network > through an NFS mount. Is that possible? > > I serched google for 'socket file', and all that I got was 'fifo', but > they are to be used only on a singl machine for communication between > 2 or more applications, but couldn't find any file abstraction for > communication for processes on distinct machines. Do you know of any > such thing, cause I couldn't find any. > sockets. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS and fifos.
On 7/16/05, Arvind Kalyan <[EMAIL PROTECTED]> wrote: > On 7/16/05, Dhruv Matani <[EMAIL PROTECTED]> wrote: > > Hello, > > I can't seem to be able to use fifos on an NFS mount. Is there any > > reason why this is disallowed, or is this is a bug? v.2.4.20. > > Are both the processes (reader/writer) on the same machine? FIFOs are > local objects. Yes, but I'm accessing them through my remote[public] IP address. The idea behind it is to have a fifo that works across the network through an NFS mount. Is that possible? I serched google for 'socket file', and all that I got was 'fifo', but they are to be used only on a singl machine for communication between 2 or more applications, but couldn't find any file abstraction for communication for processes on distinct machines. Do you know of any such thing, cause I couldn't find any. > > -- > Arvind Kalyan > http://www.devforge.net/~arv > -- -Dhruv Matani. http://www.geocities.com/dhruvbird/ The race of quality has no finish line. ~Anon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA_SOCKET unable to apply filter after Ram Upgrade
Hi, On Sat, Jul 16, 2005 at 05:14:36PM +0200, Frederic Gaus wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi folks! > > I've recently done a RAM upgrade on my IBM Thinkpad R40 (2722). > > 1. Ram-Chip: pc2100 cl 2.5 512 MB > 2. Ram-Chip: pc2700 cl 2.5 1024 MB > > When booting with only one Chip inside, everything works perfecly. > (Never mind in which slot). But when using both, I get this error > message every few seconds: > > kernel: cs: pcmcia_socket0: unable to apply power. > > Changing the slots does't fix the problem. High Memory Support is enabled. > > Who can help? Or do you need more information? Probably a BIOS bug which we need to work around. Please send me the output of dmesg and /proc/iomem with 1GB RAM. Dominik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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][PCMCIA] - iounmap: bad address f1d62000
On Sat, Jul 16, 2005 at 05:12:58PM +0200, Dominik Brodowski wrote: > Could you send me the output of /proc/iomem on both a working kernel and on > 2.6.13-rc3-APM, please? Dominik, I'd suggest looking elsewhere. The memory regions must be free to be able to call into readable(), and therefore pccard_validate_cis(). What seems to be happening is that s->ops->set_mem_map in set_cis_map is returning an error, causing it to free the ioremapped region multiple times. Maybe the card has an invalid CIS causing an out of range card_start to be requested? -- 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: init 0 stopped working
On Saturday, 16 July 2005, at 02:09:47 +0200, Martin Mokrejs wrote: > Any clues? I still happens even with 2.6.13-rc3-git2. > Check message with subject: [2.6.12-git8] ACPI shutdown fails to power off machine http://marc.theaimsgroup.com/?l=linux-kernel=112094139204799=2 So it seems there are more boxes out there suffering from the same problem I reported some days ago . Greetings, -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.13-rc2) signature.asc Description: Digital signature
PCMCIA_SOCKET unable to apply filter after Ram Upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks! I've recently done a RAM upgrade on my IBM Thinkpad R40 (2722). 1. Ram-Chip: pc2100 cl 2.5 512 MB 2. Ram-Chip: pc2700 cl 2.5 1024 MB When booting with only one Chip inside, everything works perfecly. (Never mind in which slot). But when using both, I get this error message every few seconds: kernel: cs: pcmcia_socket0: unable to apply power. Changing the slots does't fix the problem. High Memory Support is enabled. Who can help? Or do you need more information? Thanks Freddy - -- Frederic Gaus pgp-key: 93E6903C fingerprint: 0C55 4517 CC1E 5F7F 9059 3535 AB54 D8E8 93E6 903C -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC2SUwq1TY6JPmkDwRAuemAKDR3fAysip0ZyvSCeiV/6nxDHzcwwCgxC03 S1IyObIqnjyN2ZzMo20PSBY= =D1lj -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PCMCIA_SOCKET unable to apply filter after Ram Upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks! I've recently done a RAM upgrade on my IBM Thinkpad R40 (2722). 1. Ram-Chip: pc2100 cl 2.5 512 MB 2. Ram-Chip: pc2700 cl 2.5 1024 MB When booting with only one Chip inside, everything works perfecly. (Never mind in which slot). But when using both, I get this error message every few seconds: kernel: cs: pcmcia_socket0: unable to apply power. Changing the slots does't fix the problem. High Memory Support is enabled. Who can help? Or do you need more information? Thanks Freddy - -- Frederic Gaus street: Klappacher Straße 6 city:64285 Darmstadt phone: 06151 - 353 246 3 mobile: 0173 - 1993 224 email: [EMAIL PROTECTED] pgp-key: 93E6903C fingerprint: 0C55 4517 CC1E 5F7F 9059 3535 AB54 D8E8 93E6 903C -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC2SRcq1TY6JPmkDwRAjNQAJwN4FMEZYb01YzPv9LRcdubVUoJTQCg2Vfb Lq5fDK6Gbvf/qqERP20cJ8o= =CB5o -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.13-rc3][PCMCIA] - iounmap: bad address f1d62000
Hi, Could you send me the output of /proc/iomem on both a working kernel and on 2.6.13-rc3-APM, please? Thanks, Dominik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS/2 Keyboard is dead after resume.
On 7/16/05, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > Ok, so you start with IRQ 12 disabled.. You don't have a PS/2 mouse, > do you? Nope :). > > serio: i8042 AUX port at 0x60,0x64 irq 12 > > serio: i8042 KBD port at 0x60,0x64 irq 1 > > You did not select PNP support (but as far as keyboard controller settings > go we don't trust it anyway on i386). I've never ever found it to work, so I usually disable it. > And here you have a bunch of hardware gets assigned to IRQ 12... > Hmm, I tought ACPI would try not use 12 unless it is absolutely > necessary. What appens if you use "pci=routeirq" boot option? The keyboard was still dead after resume. > You can try working around this with "i8042.noaux" kernel boot option, > but we should probably teach i8042 driver to not touch AUX port on resume > if it was disabled. This worked. Strangely enough, after googling for i8042 and suspend last night, I found the 2.6.12 kernel boot options file. I tried i8042.nomux, i8042.direct, and some others, but nothing worked. Just for fun, I tried booting without any kernel boot options (just the suspend2 option) and with a PS/2 mouse plugged in. On suspend, the keyboard worked. Maybe this could/should be added to the suspend2 code as well? Whatever. It works for now. If you'd like any more information, just let me know. Thanks! -Andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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][PCMCIA] - iounmap: bad address f1d62000
Testing 2.6.13-rc3 and getting nasty output during bootup from yenta socket initialization. dmesg output follows: Linux version 2.6.13-rc3-APM ([EMAIL PROTECTED]) (gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)) #13 Fri Jul 15 23:55:12 EDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000d2000 - 000d4000 (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 2ff6 (usable) BIOS-e820: 2ff6 - 2ff77000 (ACPI data) BIOS-e820: 2ff77000 - 2ff79000 (ACPI NVS) BIOS-e820: 2ff8 - 3000 (reserved) BIOS-e820: ff80 - 0001 (reserved) 767MB LOWMEM available. On node 0 totalpages: 196448 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 192352 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 DMI present. Allocating PCI resources starting at 3000 (gap: 3000:cf80) Built 1 zonelists Kernel command line: auto BOOT_IMAGE=Test_9.3 ro root=307 selinux=0 desktop video=1024x768 i8042.nomux PROFILE=NUI Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to d000 (01601000) Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 1398.858 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 774732k/785792k available (2439k kernel code, 10604k reserved, 665k data, 156k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 2800.29 BogoMIPS (lpj=14001494) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: a7e9f9bf 0180 CPU: After vendor identify, caps: a7e9f9bf 0180 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 1024K CPU: After all inits, caps: a7e9f9bf 0040 0180 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) CPU: Intel(R) Pentium(R) M processor 1400MHz stepping 05 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfd8d6, last bus=8 PCI: Using configuration type 1 Linux Plug and Play Support v0.97 (c) Adam Belay PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 Boot video device is :01:00.0 PCI: Transparent bridge - :00:1e.0 PCI: Discovered primary peer bus 09 [IRQ] PCI: Using IRQ router PIIX/ICH [8086/24cc] at :00:1f.0 PCI: IRQ 0 for device :00:1f.1 doesn't match PIRQ mask - try pci=usepirqmask PCI: Found IRQ 11 for device :00:1f.1 PCI: Sharing IRQ 11 with :00:1d.2 PCI: Sharing IRQ 11 with :02:00.2 PCI: Sharing IRQ 11 with :02:02.0 PCI: Bridge: :00:01.0 IO window: 3000-3fff MEM window: c010-c01f PREFETCH window: e000-e7ff PCI: Bus 3, cardbus bridge: :02:00.0 IO window: 4000-4fff IO window: 5000-5fff PREFETCH window: e800-e9ff MEM window: c200-c3ff PCI: Bus 7, cardbus bridge: :02:00.1 IO window: 6000-6fff IO window: 7000-7fff PREFETCH window: ea00-ebff MEM window: c400-c5ff PCI: Bridge: :00:1e.0 IO window: 4000-8fff MEM window: c020-cfff PREFETCH window: e800-efff PCI: Setting latency timer of device :00:1e.0 to 64 PCI: Found IRQ 11 for device :02:00.0 PCI: Sharing IRQ 11 with :00:1d.0 PCI: Sharing IRQ 11 with :01:00.0 PCI: Sharing IRQ 11 with :02:01.0 PCI: Found IRQ 11 for device :02:00.1 PCI: Sharing IRQ 11 with :00:1f.3 PCI: Sharing IRQ 11 with :00:1f.5 PCI: Sharing IRQ 11 with :00:1f.6 audit: initializing netlink socket (disabled) audit(1121522265.240:1): initialized Total HugeTLB memory allocated, 0 inotify syscall VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API PCI: Found IRQ 11 for device :01:00.0 PCI: Sharing IRQ 11 with :00:1d.0 PCI: Sharing IRQ 11 with :02:00.0 PCI: Sharing IRQ 11 with :02:01.0 radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=144.00 Mhz, System=144.00 MHz radeonfb: PLL min 12000 max 35000 Non-DDC laptop panel detected radeonfb: Monitor 1 type LCD found radeonfb: Monitor 2 type no found radeonfb: panel ID string: 1024x768
Re: NFS and fifos.
On 7/16/05, Dhruv Matani <[EMAIL PROTECTED]> wrote: > Hello, > I can't seem to be able to use fifos on an NFS mount. Is there any > reason why this is disallowed, or is this is a bug? v.2.4.20. Are both the processes (reader/writer) on the same machine? FIFOs are local objects. -- Arvind Kalyan http://www.devforge.net/~arv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs+acl makes processes hang?
>You made one mistake, the last echo "1" >blah should not be >to the file you created earlier.. the echo is meant to Right. Hangs now. If someone wants a stack trace, below is one. However, I wonder why my traces have become so distorted -- e.g. the proc_lookup in the last one should not be there at all. But I think the problem is simple: Reiserfs implements ACLs/Xattrs using files, and obviously, creating the ACL for the file cannot succeed because there's no space left. Don't know what reiser does in case _an acl file_ can't be created... : bash D C39335D0 0 4252 4195 (NOTLB) : c3de3cb8 0082 c39335d0 c0128a60 c3de3cbc bf1ff5dc 00fd :c39335d0 cdc01b84 c3de3cc8 c39335d0 c7101208 c02852a5 c3de3cbc cdc01b88 :c2d17e0c cdc01b88 c39335d0 0001 c7101208 c71011bc c71011cc c7101208 : Call Trace: : [] autoremove_wake_function+0x0/0x50 : [] rwsem_down_read_failed+0x75/0x150 : [] .text.lock.xattr+0x55/0x23d : [] reiserfs_delete_inode+0x70/0x110 : [] reiserfs_set_acl+0x167/0x1a0 : [] reiserfs_delete_inode+0x0/0x110 : [] generic_delete_inode+0x9c/0x140 : [] iput+0x4c/0x70 : [] reiserfs_new_inode+0x149/0x700 : [] reiserfs_find_entry+0xad/0x120 : [] wake_queued_writers+0x30/0x40 : [] reiserfs_create+0xe7/0x210 : [] reiserfs_permission+0xf/0x20 : [] permission+0xb6/0xe0 : [] vfs_create+0xc6/0x190 : [] open_namei+0x5fa/0x740 : [] filp_open+0x27/0x50 : [] get_unused_fd+0x20/0xa0 : [] getname+0x67/0xb0 : [] sys_open+0x49/0xd0 : [] syscall_call+0x7/0xb : lsD C2D17E60 0 20215 14083 (NOTLB) : c2d17dfc 0086 c01ad123 c2d17e60 c2d17eb0 b1b8700c 0134 :c3933ac0 cdc01b84 c2d17e0c c3933ac0 c02852a5 c3933ac0 cdc01b88 :cdc01b88 c3de3cc8 c3933ac0 0001 c02c7be0 c7c7c4b4 c2d17e58 : Call Trace: : [] journal_mark_dirty+0x113/0x250 : [] rwsem_down_read_failed+0x75/0x150 : [] .text.lock.xattr+0xc7/0x23d : [] getxattr+0xdc/0x170 : [] reiserfs_permission+0x0/0x20 : [] reiserfs_permission+0xf/0x20 : [] permission+0xb6/0xe0 : [] __link_path_walk+0x4a4/0xed0 : [] handle_mm_fault+0x138/0x190 : [] link_path_walk+0xab/0x1a0 : [] __user_walk+0x3d/0x60 : [] sys_getxattr+0x4b/0x70 : [] syscall_call+0x7/0xb : lsD C0180493 0 22554 22493 (NOTLB) : ce079dfc 0082 cffec560 c0180493 ffea ced0fb00 08b060f1 0170 :c478aa20 cdc01b84 ce079e0c c478aa20 c02852a5 c0135316 cdc01b88 :cdc01b88 c2d17e0c c478aa20 0001 c02c7be0 c82d7f54 ce079e58 : Call Trace: : [] proc_lookup+0xa3/0xb0 : [] rwsem_down_read_failed+0x75/0x150 : [] prep_new_page+0x46/0x60 : [] .text.lock.xattr+0xc7/0x23d : [] getxattr+0xdc/0x170 : [] reiserfs_permission+0x0/0x20 : [] reiserfs_permission+0xf/0x20 : [] permission+0xb6/0xe0 : [] __link_path_walk+0x4a4/0xed0 : [] handle_mm_fault+0x138/0x190 : [] link_path_walk+0xab/0x1a0 : [] __user_walk+0x3d/0x60 : [] sys_getxattr+0x4b/0x70 : [] syscall_call+0x7/0xb Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.13-rc3] Add support for Netcell Revolution to pci-ide generic driver
Description: Adds support for Netcell Revolution to pci-ide generic
driver by including it in the list of devices matched. Includes the
Revolution in the list of simplex devices forced into DMA mode.
Signed-off-by: Matt Gillette <[EMAIL PROTECTED]>
---
diff -purN linux-2.6.13-rc3/drivers/ide/pci/generic.c
linux/drivers/ide/pci/generic.c
--- linux-2.6.13-rc3/drivers/ide/pci/generic.c 2005-07-14
18:02:17.0 -0700
+++ linux/drivers/ide/pci/generic.c 2005-07-15 15:33:00.0 -0700
@@ -173,7 +173,13 @@ static ide_pci_device_t generic_chipsets
.channels = 2,
.autodma= NOAUTODMA,
.bootable = ON_BOARD,
- }
+ },{ /* 14 */
+ .name = "Revolution",
+.init_hwif = init_hwif_generic,
+.channels = 2,
+.autodma= AUTODMA,
+.bootable = OFF_BOARD,
+}
};
/**
@@ -231,6 +237,7 @@ static struct pci_device_id generic_pci_
{ PCI_VENDOR_ID_TOSHIBA,PCI_DEVICE_ID_TOSHIBA_PICCOLO,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 11},
{ PCI_VENDOR_ID_TOSHIBA,PCI_DEVICE_ID_TOSHIBA_PICCOLO_1,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 12},
{ PCI_VENDOR_ID_TOSHIBA,PCI_DEVICE_ID_TOSHIBA_PICCOLO_2,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 13},
+ { PCI_VENDOR_ID_NETCELL,PCI_DEVICE_ID_REVOLUTION,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 14},
/* Must come last. If you add entries adjust this table appropriately
and the init_one code */
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_IDE << 8, 0xFF00UL, 0},
{ 0, },
diff -purN linux-2.6.13-rc3/drivers/ide/setup-pci.c
linux/drivers/ide/setup-pci.c
--- linux-2.6.13-rc3/drivers/ide/setup-pci.c 2005-07-14
18:02:17.0 -0700
+++ linux/drivers/ide/setup-pci.c 2005-07-15 14:43:26.0 -0700
@@ -229,6 +229,7 @@ second_chance_to_dma:
case PCI_DEVICE_ID_AMD_VIPER_7409:
case PCI_DEVICE_ID_CMD_643:
case PCI_DEVICE_ID_SERVERWORKS_CSB5IDE:
+ case PCI_DEVICE_ID_REVOLUTION:
simplex_stat = hwif->INB(dma_base + 2);
hwif->OUTB((simplex_stat&0x60),(dma_base + 2));
simplex_stat = hwif->INB(dma_base + 2);
diff -purN linux-2.6.13-rc3/drivers/pci/pci.ids
linux/drivers/pci/pci.ids
--- linux-2.6.13-rc3/drivers/pci/pci.ids 2005-07-14 18:02:07.0
-0700
+++ linux/drivers/pci/pci.ids 2005-07-16 06:28:32.0 -0700
@@ -7982,7 +7982,7 @@
168c 2042 Netgate 5354MP Plus ARIES2 a/b/g MiniPCI Adapter
1014 AR5212 802.11abg NIC
169c Netcell Corporation
- 0044 SyncRAID SR3000/5000 Series SATA RAID Controllers
+ 0044 Revolution Storage Processing Card
16a5 Tekram Technology Co.,Ltd.
16ab Global Sun Technology Inc
1100 GL24110P
diff -purN linux-2.6.13-rc3/include/linux/pci_ids.h
linux/include/linux/pci_ids.h
--- linux-2.6.13-rc3/include/linux/pci_ids.h 2005-07-14
18:01:56.0 -0700
+++ linux/include/linux/pci_ids.h 2005-07-15 14:43:26.0 -0700
@@ -2170,6 +2170,9 @@
#define PCI_VENDOR_ID_SIBYTE 0x166d
#define PCI_DEVICE_ID_BCM1250_HT 0x0002
+#define PCI_VENDOR_ID_NETCELL 0x169c
+#define PCI_DEVICE_ID_REVOLUTION 0x0044
+
#define PCI_VENDOR_ID_LINKSYS 0x1737
#define PCI_DEVICE_ID_LINKSYS_EG1032 0x1032
#define PCI_DEVICE_ID_LINKSYS_EG1064 0x1064
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Module snd-intel8x0.ko broken in 2.6.12
On 7/16/05, FyD <[EMAIL PROTECTED]> wrote: > Here is the error message I get whatever the kernel 2.6.12 I use: > FATAL: Error inserting snd-intel8x0 > (/lib/modules/2.6.12.2/kernel/sound/pci/snd-intel8x0.ko) > unknown symbol in module or unknown parameter (see dmesg) May be you chose additional modules that were interfering with symbols in this module. Just take your old .config and run `make oldconfig` then update as needed. > Answer of dmesg: [...] Unrelated. > Does it mean this module is broken in 2.6.12 ? No, works fine for me. Regards, -- Arvind Kalyan http://www.devforge.net/~arv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] forcedeth: TX handler changes (experimental)
[If you receive the mail twice - sorry. I forgot to attach the actual patch]
Hi,
Attached is a patch that modifies the tx interrupt handling of the
nForce nic. It's part of the attempts to figure out what causes the nic
hangs (see bug 4552).
The change is experimental: It affects all nForce versions. I've tested
it on my nForce 250-Gb.
Please test it. And especially: If you experince a nic hang, please send
me the debug output. That's the block starting with
<<
NETDEV WATCHDOG: eth1: transmit timed out
eth1: Got tx_timeout. irq:
eth1: Ring at ...
<<
Thanks,
Manfred
--- 2.6/drivers/net/forcedeth.c 2005-07-16 13:10:30.0 +0200
+++ build-2.6/drivers/net/forcedeth.c 2005-07-16 15:58:03.0 +0200
@@ -87,6 +87,8 @@
* 0.35: 26 Jun 2005: Support for MCP55 added.
* 0.36: 28 Jun 2005: Add jumbo frame support.
* 0.37: 10 Jul 2005: Additional ethtool support, cleanup of pci id list
+ * 0.38: 16 Jul 2005: tx irq rewrite: Use global flags instead of
+ *per-packet flags.
*
* Known bugs:
* We suspect that on some hardware no TX done interrupts are generated.
@@ -98,7 +100,7 @@
* DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few
* superfluous timer interrupts from the nic.
*/
-#define FORCEDETH_VERSION "0.36"
+#define FORCEDETH_VERSION "0.38"
#define DRV_NAME "forcedeth"
#include
@@ -133,12 +135,9 @@
* Hardware access:
*/
-#define DEV_NEED_LASTPACKET1 0x0001 /* set LASTPACKET1 in tx flags */
-#define DEV_IRQMASK_1 0x0002 /* use NVREG_IRQMASK_WANTED_1 for irq
mask */
-#define DEV_IRQMASK_2 0x0004 /* use NVREG_IRQMASK_WANTED_2 for irq
mask */
-#define DEV_NEED_TIMERIRQ 0x0008 /* set the timer irq flag in the irq
mask */
-#define DEV_NEED_LINKTIMER 0x0010 /* poll link settings. Relies on the
timer irq */
-#define DEV_HAS_LARGEDESC 0x0020 /* device supports jumbo frames and
needs packet format 2 */
+#define DEV_NEED_TIMERIRQ 0x0001 /* set the timer irq flag in the irq
mask */
+#define DEV_NEED_LINKTIMER 0x0002 /* poll link settings. Relies on the
timer irq */
+#define DEV_HAS_LARGEDESC 0x0003 /* device supports jumbo frames and
needs packet format 2 */
enum {
NvRegIrqStatus = 0x000,
@@ -149,13 +148,16 @@
#define NVREG_IRQ_RX 0x0002
#define NVREG_IRQ_RX_NOBUF 0x0004
#define NVREG_IRQ_TX_ERR 0x0008
-#define NVREG_IRQ_TX2 0x0010
+#define NVREG_IRQ_TX_OK0x0010
#define NVREG_IRQ_TIMER0x0020
#define NVREG_IRQ_LINK 0x0040
+#define NVREG_IRQ_TX_ERROR 0x0080
#define NVREG_IRQ_TX1 0x0100
-#define NVREG_IRQMASK_WANTED_1 0x005f
-#define NVREG_IRQMASK_WANTED_2 0x0147
-#define NVREG_IRQ_UNKNOWN
(~(NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR|NVREG_IRQ_TX2|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX1))
+#define NVREG_IRQMASK_WANTED 0x00df
+
+#define NVREG_IRQ_UNKNOWN
(~(NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR| \
+
NVREG_IRQ_TX_OK|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX_ERROR| \
+ NVREG_IRQ_TX1))
NvRegUnknownSetupReg6 = 0x008,
#define NVREG_UNKSETUP6_VAL3
@@ -296,7 +298,7 @@
#define NV_TX_LASTPACKET (1<<16)
#define NV_TX_RETRYERROR (1<<19)
-#define NV_TX_LASTPACKET1 (1<<24)
+#define NV_TX_FORCED_INTERRUPT (1<<24)
#define NV_TX_DEFERRED (1<<26)
#define NV_TX_CARRIERLOST (1<<27)
#define NV_TX_LATECOLLISION(1<<28)
@@ -306,7 +308,7 @@
#define NV_TX2_LASTPACKET (1<<29)
#define NV_TX2_RETRYERROR (1<<18)
-#define NV_TX2_LASTPACKET1 (1<<23)
+#define NV_TX2_FORCED_INTERRUPT(1<<30)
#define NV_TX2_DEFERRED(1<<25)
#define NV_TX2_CARRIERLOST (1<<26)
#define NV_TX2_LATECOLLISION (1<<27)
@@ -1013,9 +1015,39 @@
struct fe_priv *np = get_nvpriv(dev);
u8 __iomem *base = get_hwbase(dev);
- dprintk(KERN_DEBUG "%s: Got tx_timeout. irq: %08x\n", dev->name,
+ printk(KERN_INFO "%s: Got tx_timeout. irq: %08x\n", dev->name,
readl(base + NvRegIrqStatus) & NVREG_IRQSTAT_MASK);
+ {
+ int i;
+
+ printk(KERN_INFO "%s: Ring at %lx: next %d nic %d\n",
+ dev->name, (unsigned long)np->ring_addr,
+ np->next_tx, np->nic_tx);
+ printk(KERN_INFO "%s: Dumping tx registers\n", dev->name);
+ for (i=0;i<0x400;i+= 32) {
+ printk(KERN_INFO "%3x: %08x %08x %08x %08x %08x %08x
%08x %08x\n",
+ i,
+ readl(base + i + 0),
[PATCH] forcedeth: TX handler changes (experimental)
Hi, Attached is a patch that modifies the tx interrupt handling of the nForce nic. It's part of the attempts to figure out what causes the nic hangs (see bug 4552). The change is experimental: It affects all nForce versions. I've tested it on my nForce 250-Gb. Please test it. And especially: If you experince a nic hang, please send me the debug output. That's the block starting with << NETDEV WATCHDOG: eth1: transmit timed out eth1: Got tx_timeout. irq: eth1: Ring at ... << Thanks, Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: resuming swsusp twice
Hi!
> > I of course won't say that this cannot happen, but by design, the
> > swsusp
> > signature is invalidated even before reading the image, so
> > theoretically
> > it should not happen.
>
> Yes, I'd seen that happen on earlier swsusps, so I was quite suprised
> when it blew up like this.
>
> Perhaps the image should be more rigorously checked? I'm wishing that
> it would verify that the header and the image matched, after it finishes
> reading the image. For example, computing the hash
>
> MD5(header || image) (|| denotes "concatenate" in crypto pseudocode.)
>
> and storing that hash in a final trailing block. Additionally, of
> course, as soon as the resume has read the image it should overwrite the
> header; and the header should include jiffies or something along those
> lines to ensure that it won't accidentally have the same contents as the
> previous image's header.
>
> The hash doesn't have to be MD5; even a CRC should suffice I think...
Actually, what you want is "if filesystems are newer than suspend
image, panic" test. There is more than one way how that can happen.
Are you sure you did not do
suspend kernel 1
boot kernel 2
attempt to suspend kernel 2 but fail ("not enough swap space")
boot kernel 1 ("and successfully resume, corrupting data")
?
Pavel
--
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386: Selectable Frequency of the Timer Interrupt
Hi! > > The real answer here is for the tickless patches to cleaned up to > > the point where they can be merged, and then we won't waste battery > > power entering the timer interrupt in the first place. :-) > > Whilst conceptually this is a nice idea I've yet to see any viable > code that overall has a lower cost. Tickless is a really nice idea > for embedded devices and also paravirtualized hardware but I don't > think anyone has it working well enough yet do they? Actually for power managment uses, "NO_IDLE_HZ" seems to be enough, and that is both implemented and working. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why is 2.6.12.2 less stable on my laptop than 2.6.10?
Hi! > Why can't I expect SWSusp work better and more reliable from release to > release? Patches welcome. Or employ someone to do swsusp development for you. > Some possible things that could help: > > *Addopt a no-regressions-allowed policy and everthing stops until any > identified regressions (in performance, functionally or stability) is fixed > or the changes are all rolled back. This works really well if in addition > organized pre-flight testing is done before calling a new version number. > You simply cannot rely on ad-hock regression testing and reporting. Its got > too much latency. This would also mean "no development at all". > * assign validation folks that the developer need to appease before changes > are allowed to be accepted into the tree. So... get me someone to test swsusp in each -rc and -mm release... that would help. If you can't provide the manpower, why are you whining? Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: resuming swsusp twice
Hi! > > I of course won't say that this cannot happen, but by design, the > > swsusp > > signature is invalidated even before reading the image, so > > theoretically > > it should not happen. > > Yes, I'd seen that happen on earlier swsusps, so I was quite suprised > when it blew up like this. > > Perhaps the image should be more rigorously checked? I'm wishing that > it would verify that the header and the image matched, after it finishes > reading the image. For example, computing the hash > > MD5(header || image) (|| denotes "concatenate" in crypto pseudocode.) > > and storing that hash in a final trailing block. Additionally, of > course, as soon as the resume has read the image it should overwrite the > header; and the header should include jiffies or something along those > lines to ensure that it won't accidentally have the same contents as the > previous image's header. > > The hash doesn't have to be MD5; even a CRC should suffice I think... That's quite a lot of complexity... just fix the bug. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/4] add jiffies_to_nsecs() helper and fix up size of usecs
Hi!
> > > +static inline u64 jiffies_to_nsecs(const unsigned long j)
> > > +{
> > > +#if HZ <= NSEC_PER_SEC && !(NSEC_PER_SEC % HZ)
> > > + return (NSEC_PER_SEC / HZ) * (u64)j;
> > > +#elif HZ > NSEC_PER_SEC && !(HZ % NSEC_PER_SEC)
> > > + return ((u64)j + (HZ / NSEC_PER_SEC) - 1)/(HZ / NSEC_PER_SEC);
> > > +#else
> > > + return ((u64)j * NSEC_PER_SEC) / HZ;
> > > +#endif
> > > +}
> >
> > That might look a little better something like:
> >
> > static inline u64 jiffies_to_nsecs(const unsigned long __j)
> > {
> > u64 j = __j;
> >
> > if (HZ <= NSEC_PER_SEC && !(NSEC_PER_SEC % HZ))
> > return (NSEC_PER_SEC / HZ) * j;
> > else if (HZ > NSEC_PER_SEC && !(HZ % NSEC_PER_SEC))
> > return (j + (HZ / NSEC_PER_SEC) - 1)/(HZ / NSEC_PER_SEC);
> > else
> > return (j * NSEC_PER_SEC) / HZ;
> > }
> >
> > Compilers are smart :)
>
> Well, I was trying to keep it similar to the other conversion functions.
> I guess the compiler can evaluate the conditional full of constants at
> compile-time regardless of whether it is #if or if ().
>
> I can make these changes if others would like them as well.
Yes, please. And feel free to convert nearby functions, too ;-).
Pavel
--
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386: Selectable Frequency of the Timer Interrupt
Hi! > > Alan tested it and said that 250HZ does not save much power anyway. > > Len Brown, a year ago: "The bottom line number to laptop users is battery > lifetime. Just today somebody complained to me that Windows gets twice the > battery life that Linux does." > > And "Maybe I can get Andy Grover over in the moble lab to get some time on > that fancy power measurement setup they have... > > "My expectation is if we want to beat the competition, we'll want the > ability to go *under* 100Hz." > > But then, power consumption of the display should preponderate, so it's not > clear. > > Len, any updates on the relationship between HZ and power consumption? Last time I checked, HZ=100 to HZ=1000 difference was about 1W, about twice as much as disk spinning up vs. disk spinned down. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: resuming swsusp twice
Hi! > Yesterday I booted my laptop to 2.6.13-rc2-mm1, suspended to swsusp, and > then resumed. It ran fine overnight, including a fair amount of IO > (running firefox, rsyncing ~/Mail/archive from my mail server, hg pull, > etc). This morning I did a swsusp: > > echo shutdown > /sys/power/disk > echo disk > /sys/power/state > > and got a panic along the lines of "Unable to find swap space, try > swapon -a". Unfortunately I was in a hurry and didn't record the error > messages. I powered off, then a few minutes later powered on again. > > At this point, it resumed *to the swsusp state from yesterday*! > As soon as I realized what had happened, I powered off (not > shutdown) and rebooted. Bad, very bad. > On the next boot it did not find a swsusp signature and booted normally; > ext3 did a normal recovery and seemed OK, but I was suspicious and did a > fsck -f, which revealed a lot of damage; most of the damage seemed to be > in the hg repo which had been pulled from www.kernel.org/hg/. You should not let ext3 do journal replay. At that point, hopefully damage will be slightly better. > It's extremely unfortunate that there is *any* failure mode in swsusp > that can result in this behavior. Well, I've never seen that one before... Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
strange boot problem since 2.6.12
The problem is simple and I have it since 2.6.12 final (tested on 2.6.12, 2.6.12.2, 2.6.13-rc3). After grub stage2 (kernel image loaded) the system freeze and I can only hit the three-finger-salute (ctrl+alt+del). The system is: Asus A8V Deluxe bios 1014.007 (tested with 1014.001 and 1013) AMD Athlon 64 3800+ running in 32bit mode 2 GB of DDR PC3200 nVIDIA GF FX 5600XT 256Mb 3 HD (1 ATA and 2 SATA) etc etc and it's running mail, web, ldap, ftp and NX services Here's some info: cmdline -> http://lxnay.no-ip.org/kernel/bug-report/cmdline cpuinfo -> http://lxnay.no-ip.org/kernel/bug-report/cpuinfo lspci -> http://lxnay.no-ip.org/kernel/bug-report/lspci grub configuration -> http://lxnay.no-ip.org/kernel/bug-report/grub lsusb -> http://lxnay.no-ip.org/kernel/bug-report/lsusb kernel config (for 2.6.12 and 2.6.13-rc - make oldconfig) -> http://lxnay.no-ip.org/kernel/bug-report/config Error image -> http://lxnay.no-ip.org/kernel/bug-report/boot.jpg (thanks to kdebluetooth and nokia 6600 :-) ) Yes, I'm running 2.6.12, in fact, after hours of recompilations I was able to generate a running kernel (based on 2.6.12.2)... Every 2.6.11 works fine, this is the only one working 2.6.12 and I don't know why it works... Unfortunately, I can't give any more information since the error appears in an early stage... :( -- Fabio Erculiani lxnay [EMAIL PROTECTED] - [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/
PATCH: Adjust PCI rom code to handle more broken ROMs
There are ROMs reporting that their size exceeds their PCI ROM resource window. This patch returns the minimum of the resource window size or the size in the ROM. An example of this breakage is the XGI Volari Z7. Signed-off-by: Jon Smirl <[EMAIL PROTECTED]> Patch is in an attachment since gmail will mangle the tabs. -- Jon Smirl [EMAIL PROTECTED] diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c --- a/drivers/pci/rom.c +++ b/drivers/pci/rom.c @@ -125,7 +125,9 @@ void __iomem *pci_map_rom(struct pci_dev image += readw(pds + 16) * 512; } while (!last_image); - *size = image - rom; + /* never return a size larger than the PCI resource window */ + /* there are known ROMs that get the size wrong */ + *size = min((size_t)(image - rom), *size); return rom; }
Re: [patch 2.6.13-git] 8250 tweaks
Russell King <[EMAIL PROTECTED]> wrote: > The interrupts are only claimed when the port is > actually opened, so if > only one port was open, you'll only see one > appearing in /proc/interrupts. Get it. Thanks so much, Sam Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Audit return code of create_proc_*
Hi Domen,
On Friday 15 July 2005 00:19, you wrote:
> Audit return of create_proc_* functions.
This (and related changes) spam the log, if
kernel is compiled without /proc-support.
Kernels without /proc-support are quite common in the embedded world.
Just provide a function in a suitable header
(include/linux/proc_fs.h looks promising)
file, which contains the following:
#ifdef CONFIG_PROC_FS
#define procfs_failure(msg) do { printk(msg); } while(0)
#else
#define procfs_failure(msg) do {} while(0)
#endif
and use it instead of the direct printk call.
That way you get both: Your GCC or checking tool warning is silenced
and the log is not spammed for the embedded people.
For code, which is broken without procfs, the code
should be fixed or it should select PROC_FS in its Kconfig file.
Regards
Ingo Oeser
pgp4s9qFpX6R1.pgp
Description: PGP signature
NFS and fifos.
Hello, I can't seem to be able to use fifos on an NFS mount. Is there any reason why this is disallowed, or is this is a bug? v.2.4.20. ps. pl. cc to me. Thanx in advance. -- -Dhruv Matani. http://www.geocities.com/dhruvbird/ The race of quality has no finish line. ~Anon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-git] 8250 tweaks
On Sat, Jul 16, 2005 at 03:12:01AM -0700, Sam Song wrote: > Still one puzzle related serial port. That's interrupt itself. I > enabled two serial ports attached two different interrupt levels > like 9/10 with disable interrupt shared. How come only one appeared > in /proc/interrupts? What could be on your platform or they should be? The interrupts are only claimed when the port is actually opened, so if only one port was open, you'll only see one appearing in /proc/interrupts. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Kconfig: lxdialog: Enable UTF8
On Sat, 16 Jul 2005, Sam Ravnborg wrote: > > > > OK, I'll bite - non utf8 here, and no libncursesw : a quick google > > suggests I can get it if I recompile ncurses with --enable-widec, but > > why would I want to do that ? > Could you try if specifying both libraries works for you. the 'w' > version first. Then we can use the 'w' version when available but > fall-back to the normal case if not. > > Sam > Didn't work, I get the not unexpected "cannot find -lncursesw". I think some sort of pre-test will be needed to see which one exists. I'm weak on doing this in a Makefile, but I'll have a look tonight or tomorrow. Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-git] 8250 tweaks
Russell King <[EMAIL PROTECTED]> wrote: > but it's not. We need PPC folk to fix their > SERIAL_PORT_DFNS and remove obsolete stuff like > RS_TABLE_SIZE. Hope Mark could take care this change. I have no sandpoint board at hand:-) I removed RS_TABLE_SIZE on my target successfully and happened to found that there was other file like ../syslib/gen550_dbg.c required SERIAL_PORT_DFNS as well which could use for KGDB or sth. > Ideally, SERIAL_PORT_DFNS should end up being > completely empty. It has implemented on my target:-) Still one puzzle related serial port. That's interrupt itself. I enabled two serial ports attached two different interrupt levels like 9/10 with disable interrupt shared. How come only one appeared in /proc/interrupts? What could be on your platform or they should be? Thanks a lot, Sam __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Interbench v0.21
On Fri, 2005-07-15 at 14:01 +1000, Con Kolivas wrote: > Interbech is a an application is designed to benchmark interactivity in Linux. > > Version 0.21 update > > http://ck.kolivas.org/apps/interbench/interbench-0.21.tar.bz2 > I would suggest using microseconds for both the RT and non RT tests. It would allow easier comparison of results. I have a pretty slow machine and the max result would only be ~44000 usecs. Also, if it's run with -r and sched_setscheduler fails, rather than saying "you must be root for SCHED_FIFO" the error message should encourage the user to try a 2.6.12+ kernel and add themselves to the "audio" or "realtime" group, and to file a feature request if their distro does not support the new realtime rlimit feature. We should encourage more applications to take advantage of, and distros to support, the non-root RT scheduling available in 2.6.12+. I really think the kernel is good enough at this point that we could achieve OSX-like multimedia performance on the desktop if more apps like xmms, xine, and mplayer were to adopt a multithreaded model with the time-critical rendering threads running RT. XMMS recently adopted such a model, but I don't think the audio thread runs SCHED_FIFO yet. These benchmarks imply that it would be a massive improvement. 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: init 0 stopped working
> I used to shutdown my P4 machine based on ASUS P4C800E-Deluxe > with simple "init 0" command. That somehow broke between 2.6.12-rc6-git2 > and 2.6.13-rc1. The machines makes the sound like shutdown but it > immediately turns the power on again. I used acpi and the kernel > configs should be almost identical in all cases, as I just recopy > previously used .config and run "make oldconfig". > > Any clues? I still happens even with 2.6.13-rc3-git2. It was introduced after 2.6.12 but before or with 2.6.13-rc1. It is not fixed by acpi-20050708 patch for 2.6.13 series. I had KEXEC enabled and also disabled, but the problem still persists. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Module option for compiled-in parts
Hi, I have added a module_param() to a component that is compiled in (drivers/char/vt.c). Since it's not a module, will it still show a /sys/module/WhatGoesHere/parameters/myvariablename file? What will be put as "WhatGoesHere" as vt.c does not become vt.ko? Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs+acl makes processes hang?
You made one mistake, the last echo "1" >blah should not be
to the file you created earlier.. the echo is meant to
create another file which is supposed to fail because there
is no free space but for some reason instead of failing it
will cause the process to enter D state.
Here is how I just reproced it:
#mkdir testdir
#cd testdir/
#dd if=/dev/zero of=blk count=64 bs=1M
64+0 records in
64+0 records out
#mkreiserfs -f blk >/dev/null
mkreiserfs 3.6.19 (2003 www.namesys.com)
blk is not a block special device
Continue (y/n):y
#mkdir mpoint
#mount blk mpoint/ -o loop,acl
#cd mpoint
#mkdir dir
#setfacl -f -m u:sn4ip3r:rwX dir
setfacl: invalid option -- f
Usage: setfacl [-bkndRLP] { -m|-M|-x|-X ... } file ...
Try `setfacl --help' for more information.
#setfacl -d -m u:sn4ip3r:rwX dir
#cd dir
#cat /dev/zero >blah
cat: write error: No space left on device
#df .
Filesystem 1K-blocks Used Available Use% Mounted on
/home/sn4ip3r/testdir/blk
65528 65528 0
100% /home/sn4ip3r/testdir/mpoint
#echo 1 > blah2 <<< and this is the line that never returns
--
Tarmo Tänav
[EMAIL PROTECTED]
On L, 2005-07-16 at 10:24 +0200, Jan Engelhardt wrote:
> >Hi,
> >
> >Here's how to reproduce:
> >1. mount a reiserfs volume (loopmount will do) with "-o acl".
> >2. create a directory "dir"
> >3. set some default acl: setfacl -d -m u:username:rwX dir
> >4. cd dir
> >5. dd if=/dev/zero of=somefile1 bs=4k count=10
> >(the idea is to run out of space)
> >6. now df should show 0 free space, if not then repeat 5.
> >7. echo "1" > somefile2 # this should hang infinitely
>
> Can't reproduce. My versions are:
> mkreiserfs 3.6.18
> Kernel 2.6.13-rc1
>
>
> ---Step 1---
> 10:25 shanghai:/mnt > dd if=/dev/zero of=blk count=64 bs=1M
> 64+0 records in
> 64+0 records out
> 67108864 bytes (67 MB) copied, 0.552862 seconds, 121 MB/s
> 10:26 shanghai:/mnt > mkreiserfs -f blk
> mkreiserfs 3.6.18 (2003 www.namesys.com)
>
> A pair of credits:
> ...
> blk is not a block special device
> Continue (y/n):y
> Guessing about desired format.. Kernel 2.6.13-rc1 is running.
> Format 3.6 with standard journal
> Count of blocks on the device: 16384
> Number of blocks consumed by mkreiserfs formatting process: 8212
> Blocksize: 4096
> Hash function used to sort names: "r5"
> Journal Size 8193 blocks (first block 18)
> Journal Max transaction length 1024
> inode generation number: 0
> UUID: aa3bd664-fde0-4552-9484-49bac0fb698f
> Initializing journal - 0%20%40%60%80%100%
> Syncing..ok
> ReiserFS is successfully created on blk.
> 10:26 shanghai:/mnt > mount blk loop -o loop,acl
>
> ---Step 2-7---
> 10:26 shanghai:/mnt > cd loop/
> 10:27 shanghai:/mnt/loop > md dir
> 10:27 shanghai:/mnt/loop > setfacl -d -m u:daemon:rwX dir
> 10:27 shanghai:/mnt/loop > cd dir
> 10:27 shanghai:/mnt/loop/dir > cat /dev/zero >blah
> cat: write error: No space left on device
> 10:27 shanghai:/mnt/loop/dir > df .
> Filesystem 1K-blocks Used Available Use% Mounted on
> /mnt/blk 65528 65528 0 100% /mnt/loop
> 10:27 shanghai:/mnt/loop/dir > l
> total 32684
> drwxr-xr-x+ 2 root root 72 Jul 16 10:27 .
> drwxr-xr-x 5 root root 104 Jul 16 10:27 ..
> -rw-rw-r--+ 1 root root 33435648 Jul 16 10:27 blah
> (That's ok, the other 32MB are for the journal)
> 10:27 shanghai:/mnt/loop/dir > echo "1" >blah
> 10:28 shanghai:/mnt/loop/dir > l blah
> -rw-rw-r--+ 1 root root 2 Jul 16 10:28 blah
>
>
>
> Jan Engelhardt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-git] 8250 tweaks
On Thu, Jul 14, 2005 at 10:11:36PM -0700, Sam Song wrote: > Well, I use a sandpoint-based board. Not the same as > the reference one. There are two serial ports on the > board and I enabled them both with IRQ9/10. > In addition, No 8259 on this board. > > Pls don't apply this patch:-) Indeed I won't. I was hoping that it was going to be something simple, but it's not. We need PPC folk to fix their SERIAL_PORT_DFNS and remove obsolete stuff like RS_TABLE_SIZE. Ideally, SERIAL_PORT_DFNS should end up being completely empty. -- 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: FC3 module sys_print how...
Dear Richard,
Thanks for the copy.
I will try it now.
I know we should not try to open, Read, write files from the kernel
module.
We have problem with our flash media driver hanging at certain
instances.
And when it hangs you know I can't see the /var/log/messages.
After the reboot, I do NOT find the complete set of messages in
/var/log/messages.
When debug messages are exceeding the limits, is there a better solution
than writing to the file.
Regards,
Mukund Jampala
>-Original Message-
>From: Richard B. Johnson [mailto:[EMAIL PROTECTED]
>Sent: Friday, July 15, 2005 6:19 PM
>To: Mukund JB.
>Cc: Linux kernel
>Subject: Re: FC3 module sys_print how...
>
>
>It's no longer exported. You can either modify your kernel to
>export it or you can use that attached work-around to extract
>the symbol offset from /boot/System.map.
>
>Please note that manipulating files from within a module has
>never been supported. It just "sort of" works sometimes. In
>your demo code, it will work because the process-context that
>obtains the file-handle is the process that is running 'insmod'.
>If somebody else tried to write to that file after the module
>was installed, all bets are off. I strongly suggest that
>you provide hooks in your module (ioctl() or mmap(), etc) that
>a user-mode helper program can use to send or receive file-data
>from your module.
>
>
>On Fri, 15 Jul 2005, Mukund JB. wrote:
>>
>>
>> Dear Linux-lovers.
>>
>>
>>
>> I am trying to build a 2.6.10 linux kernel module to print messages
to a
>> file. I have done this 2.4 and I was successful but I am failing
here.
>>
>>
>>
>> I am using the sys_open, sys_write calls to do so.
>>
>> I am getting a compilation warning and I find no .ko file created
>> finally instead I find an .o.ko file.
>>
>>
>>
>> *** WARNIG: "sys_write" [/home/cf.o.ko] undefined!
>>
>> Below is the module code. Please suggest me what could be the
problem:-
>>
>>
>>
>>
>>
>> #include
>>
>> #include
>>
>> #include
>>
>> #include /* for O_WRONLY */
>>
>> #include/* for sys_ functions */
>>
>> #include /* for set_fs(), get_fs() etc. */
>>
>> #include /* for string length */
>>
>> #include/* for kmalloc */
>>
>>
>>
>> MODULE_LICENSE("GPL");
>>
>> /*
>>
>> #define DBG
>>
>> #define PRINTK(fmt,arg...) printk("DBG INFO <%s> | "
>> fmt,__FUNCTION__,##arg)
>>
>> #else
>>
>> #define PRINTK(fmt,arg...) while(0)
>>
>> #endif
>>
>> */
>>
>>
>>
>> typedef struct tagWRITE_TEST
>>
>> {
>>
>> unsigned long fd;
>>
>> unsigned long x;
>>
>>
>>
>> }WRITE_TEST, *PWRITE_TEST;
>>
>>
>>
>> PWRITE_TEST ptest;
>>
>>
>>
>> void SysPrint(char * pString, ...)
>>
>> {
>>
>> static char buff[1024];
>>
>> va_list ap;
>>
>>
>>
>> va_start(ap,pString);
>>
>> vsprintf((char *)buff, pString, ap);
>>
>> va_end(ap);
>>
>>
>>
>> sys_write(ptest->fd,(char *)buff,(size_t)strlen(buff));
>>
>> }
>>
>>
>>
>> int init_module(void)
>>
>> {
>>
>>
>>
>> printk("<%s> invoked!\n",__FUNCTION__);
>>
>> printk("File Creation Testing in Kernel Module!\n");
>>
>>
>>
>> set_fs(get_ds());
>>
>>
>>
>> /* allocate the memory for structre */
>>
>> ptest = (PWRITE_TEST)kmalloc(sizeof(WRITE_TEST),GFP_KERNEL);
>>
>> if(ptest == NULL)
>>
>> {
>>
>>printk("Structure Memory Allocation Fails!\n");
>>
>>return -ENOMEM;
>>
>> }
>>
>>
>>
>> ptest->fd = sys_open("srcdebug.txt", O_CREAT | O_WRONLY, 644);
>>
>> if (ptest->fd == 0)
>>
>> {
>>
>>SysPrint("File Creation Error!!!\n");
>>
>>return 1;
>>
>> }
>>
>>
>>
>> SysPrint("File Creation Testing in Kernel Module!\n");
>>
>> SysPrint("Srinivas Testing the File Creation\n");
>>
>> sys_close(ptest->fd);
>>
>>
>>
>> return 0;
>>
>> }
>>
>>
>>
>> void cleanup_module(void)
>>
>> {
>>
>> printk("Good bye!\n");
>>
>>
>>
>> /* free the allocated memory */
>>
>> kfree(ptest);
>>
>> }
>>
>>
>>
>> Regards,
>>
>> Mukund jampala
>>
>>
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe
linux-kernel"
>in
>> the body of a message to [EMAIL PROTECTED]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
>Cheers,
>Dick Johnson
>Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
> Notice : All mail here is now cached for review by Dictator Bush.
> 98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial core: 8250_pci could not register serial port for UART chip EXAR XR17D152
On Thu, Jul 14, 2005 at 11:47:29AM -0500, V. ANANDA KRISHNAN wrote: > I have been coming across a problem with my serial port EXAR chip XR > 17D152, when I try to use the 8250_pci driver. I am using > kernel-2.6.12.1 on RHEL4.0-U1 on pSeries box with 4-cpu. 8250_pci > during the boot time, after detecting the exar chip (I checked with the > pci_dev structure and the pci_device_id structure for the info), is > unable to get thru the port registration (static int > __devinit_pciserial_init_one(struct pci_dev *dev, const struct > pci_device_id *ent) procedure in 8250_pci.c). I debugged the problem > and traced upto the routine "static int uart_match_port(struct uart_port > *port1, struct uart_port *port2" in 8250.c where UPIO_MEM is not > satisfying the condition port1->membase==port2->membase and hence > returns 0. That's the intended result. uart_match_port() only returns true when the types of the two ports match, and the base address of the two ports also match. Please try mainline 2.6 kernels. Also, please include the kernel entire messages when reporting bugs. -- 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/
Kernel Panic: VFS cannot open a root device
Hi , i have kernel 2.4.29 at slack 10.1 and when I upgrade my kernel to 2.6.11 I get these erros on booting VFS: Cannot open a root device "301" or unknow block please append a correct "root" boot option KERNEL PANIC : not syncing; VFS; Unable to mount root fs on unknown-block (3,1) I have compiled my kernel with my IDE support and also with my file system support with built-in option. My LILO.CONF image = /boot/vmlinuz-2.6.11 root = /dev/hda1 label = 2.6.11 initrd = /boot/initrd.gz read-only I googled this problem, and I think is a kind of bug, and i tryed to patch the kernel with Alan Cox patch 2.6.11-ac7.bzip and I get these :: bzip2 -dc /usr/src/patch-2.6.11.ac7.bzip | patch -p1 -s 1 out of hunk FAILED --saving rejects to file Makefike.rej and I cat the file Makefile.rej *** *** 1,8 VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 11 - EXTRAVERSION = - NAME=Woozy Numbat # *DOCUMENTATION* # To see a list of typical targets execute "make help" --- 1,8 VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 11 + EXTRAVERSION = ac7 + NAME=AC # *DOCUMENTATION* # To see a list of typical targets execute "make help" I'm stuck! The patch dont work fine ( I think the patch is not installed succesfully on my kernel ) I'm booting with my image of kernel 2.4.29. i'm 5 days tryng to solve this problem ... any kind of help is wellcome... sorry for my english. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/6] new timeofday core subsystem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> +extern nsec_t do_monotonic_clock(void);
This looks okay ...
> +/**
> + * do_monotonic_clock - Returns monotonically increasing nanoseconds
> + *
> + * Returns the monotonically increasing number of nanoseconds
> + * since the system booted via __monotonic_clock()
> + */
> +nsec_t do_monotonic_clock(void)
> +{
> + nsec_t ret;
> + unsigned long seq;
> +
> + /* atomically read __monotonic_clock() */
> + do {
> + seq = read_seqbegin(_time_lock);
> +
> + ret = __monotonic_clock();
> +
> + } while (read_seqretry(_time_lock, seq));
> +
> + return ret;
> +}
... but this conflicts with Nish's softtimer patches, which is
implemented slightly differently. For those of us who are real gluttons
for punishment, and want both sets of patches, are there problems just
removing one of the do_monotonic_clock definitions?
Thanks,
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC2MYNaI0dwg4A47wRAiQoAJ9vUvpjE7KmhCNW7NJ6kfd0SuyvXwCg+NtN
pXqoz0v5Tbf5OMFjhYSzPp0=
=LT9E
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs+acl makes processes hang?
>Hi, > >Here's how to reproduce: >1. mount a reiserfs volume (loopmount will do) with "-o acl". >2. create a directory "dir" >3. set some default acl: setfacl -d -m u:username:rwX dir >4. cd dir >5. dd if=/dev/zero of=somefile1 bs=4k count=10 >(the idea is to run out of space) >6. now df should show 0 free space, if not then repeat 5. >7. echo "1" > somefile2 # this should hang infinitely Can't reproduce. My versions are: mkreiserfs 3.6.18 Kernel 2.6.13-rc1 ---Step 1--- 10:25 shanghai:/mnt > dd if=/dev/zero of=blk count=64 bs=1M 64+0 records in 64+0 records out 67108864 bytes (67 MB) copied, 0.552862 seconds, 121 MB/s 10:26 shanghai:/mnt > mkreiserfs -f blk mkreiserfs 3.6.18 (2003 www.namesys.com) A pair of credits: ... blk is not a block special device Continue (y/n):y Guessing about desired format.. Kernel 2.6.13-rc1 is running. Format 3.6 with standard journal Count of blocks on the device: 16384 Number of blocks consumed by mkreiserfs formatting process: 8212 Blocksize: 4096 Hash function used to sort names: "r5" Journal Size 8193 blocks (first block 18) Journal Max transaction length 1024 inode generation number: 0 UUID: aa3bd664-fde0-4552-9484-49bac0fb698f Initializing journal - 0%20%40%60%80%100% Syncing..ok ReiserFS is successfully created on blk. 10:26 shanghai:/mnt > mount blk loop -o loop,acl ---Step 2-7--- 10:26 shanghai:/mnt > cd loop/ 10:27 shanghai:/mnt/loop > md dir 10:27 shanghai:/mnt/loop > setfacl -d -m u:daemon:rwX dir 10:27 shanghai:/mnt/loop > cd dir 10:27 shanghai:/mnt/loop/dir > cat /dev/zero >blah cat: write error: No space left on device 10:27 shanghai:/mnt/loop/dir > df . Filesystem 1K-blocks Used Available Use% Mounted on /mnt/blk 65528 65528 0 100% /mnt/loop 10:27 shanghai:/mnt/loop/dir > l total 32684 drwxr-xr-x+ 2 root root 72 Jul 16 10:27 . drwxr-xr-x 5 root root 104 Jul 16 10:27 .. -rw-rw-r--+ 1 root root 33435648 Jul 16 10:27 blah (That's ok, the other 32MB are for the journal) 10:27 shanghai:/mnt/loop/dir > echo "1" >blah 10:28 shanghai:/mnt/loop/dir > l blah -rw-rw-r--+ 1 root root 2 Jul 16 10:28 blah Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
