Re: [PATCH 2/11] FUSE - core
unsubscribe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Serial Driver problems in 2.6
Hello, I saw the discussion between you and Andrew Morton in the LKML on serial driver's problems. I think the problem comes, as you said from the serail driver: According to the tty_io.c file comments: It should not call the flush of the tty buffer from within interrupt handler in case of handling low_latency. IMHO most drivers do that and are buggy. (or may be I am buggy) what do you think? I was not in the lklm at tht time so I cannot answer in the thread, so I put you in CC. I do not have the email address of Andrew Morton. best regards, Pierre Morel -- http://www.mnis.fr/ http://www.ocera.org/ Real Time Linux & Linux Security TEL/FAX: 0820 20 76 22 MNIS 57, rue d'Amsterdam 75008 PARIS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Logitech MX1000 Horizontal Scrolling
On mar, 2005-02-15 at 21:01 +0100, Esben Stien wrote:
> How did you get that /dev/input/event-mx1000?
A custom rule in /etc/udev/rules.d/00_logitech.rules:
> KERNEL="event*", SYSFS{idVendor}="046d", SYSFS{idProduct}="c50e"
> NAME="input/event-mx1000" SYMLINK="input/%k"
> KERNEL="mouse*", SYSFS{idVendor}="046d", SYSFS{idProduct}="c50e"
> NAME="input/mouse-mx1000" SYMLINK="input/%k"
gets event-mx1000 and mouse-mx1000 rules, with compatibility symlinks
for other configurations. This is basically so don't have to tell evdev
where exactly on the USB hierarchy the mouse is. (You'll note that my
xorg.conf lacks the Phys descriptor line). I can now plug my mouse into
different ports, or ports on a hub, and still have it work ok.
> > and that the horizontal scroll shows up as 6/7 which most software
> > interprets as the left/right scroll buttons.
>
> I got mine on 11/12, but what do you mean most software interprets
> horizontal scroll as 6/7?. This has to be incorrect. It's logical that
> horizontal directions turns up as 11/12 along with top clicks as 9/10
> and side click 8 as these features/buttons were the last added to the
> mouse.
This certainly seems to be the convention. Just like programs interpret
buttons 4 and 5 as vertical scrolling, they interpret 6 and 7 as the
horizontal scrollers. GTK, mozilla, galeon, and firefox all go by this
principal, so you don't actually need to use a program like xbindkeys to
fake keyboard events.
(Mozilla/galeon/firefox use the horizontal scroll for backward/foreward
by default. You can change this by setting
> mousewheel.horizscroll.withnokey.action = 0
> mousewheel.horizscroll.withnokey.numlines = 1
> mousewheel.horizscroll.withnokey.sysnumlines = true
in about:config. )
--
Jeremy Nickurak <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] device-mapper: multipath
* Andrew Morton <[EMAIL PROTECTED]> wrote: > Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > > > +EXPORT_SYMBOL(dm_register_path_selector); > > > +EXPORT_SYMBOL(dm_unregister_path_selector); > > > > I though we agreed to only allow GPL'ed path selectors at OSDL? > > (OSDL?) > > Yup, this should be _GPL. Anything which uses these exports is a > derived work, isn't it? i'd not say it that categorically. I'd rather say that any module which uses these exports gains access to a wide range of GPL-licensed internal functionality of the kernel under the condition that the module declares that it is license-compatible with the GPL. While the use of such functionality very likely means that the module is derived work, even if it's not derived work (e.g. consider the following absurd corner-case: it is a short, trivial binary blob that was brute-force generated and blackbox tested to be a kernel module that happens to load fine) the module still has to follow the rules and must not circumvent the technological protection measure. (this fine distinction may or may not matter to you legally or otherwise, depending on your geographical coordinates and other factors.) 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/
[PATCH] Non-DMA mode for floppy on PowerPC
Was posted with wrong content-type and i got no reply, so i decided to repost
This patch allows to use floppy drive in non-DMA mode on PegasosPPC machines.
To use it:
1. Do not build floppy driver as a module, link it statically. Transferring
parameters to it from insmod is still problematic, at least it doesn't work
properly on my system. May be i'll clean it up in future.
2. Specify floppy=nodma in kernel's arguments. Also you'll need to specify
your drive type here using floppy=,,cmos. For
example, floppy=0,4,cmos specifies type 4 (1.44 mb 3.5") for drive 0 on my
system.
This patch does not affect operation of the driver in DMA mode so it's safe to
use on any platform.
The patch is written for kernel version 2.6.8.
--
Best regards,
Pavel Fedin,
mailto:[EMAIL PROTECTED]
--- include/asm-ppc/floppy.h.orig 2004-08-14 09:36:45.0 +0400
+++ include/asm-ppc/floppy.h2005-02-12 02:26:54.0 +0300
@@ -11,30 +11,188 @@
#ifndef __ASM_PPC_FLOPPY_H
#define __ASM_PPC_FLOPPY_H
+#include
+
+#define CSW fd_routine[can_use_virtual_dma & 1]
+
#define fd_inb(port) inb_p(port)
#define fd_outb(value,port)outb_p(value,port)
-#define fd_enable_dma() enable_dma(FLOPPY_DMA)
-#define fd_disable_dma()disable_dma(FLOPPY_DMA)
-#define fd_request_dma()request_dma(FLOPPY_DMA,"floppy")
-#define fd_free_dma() free_dma(FLOPPY_DMA)
-#define fd_clear_dma_ff() clear_dma_ff(FLOPPY_DMA)
-#define fd_set_dma_mode(mode) set_dma_mode(FLOPPY_DMA,mode)
-#define fd_set_dma_addr(addr) set_dma_addr(FLOPPY_DMA,(unsigned
int)virt_to_bus(addr))
-#define fd_set_dma_count(count) set_dma_count(FLOPPY_DMA,count)
+#define fd_disable_dma() CSW._disable_dma(FLOPPY_DMA)
+#define fd_request_dma()CSW._request_dma(FLOPPY_DMA,"floppy")
+#define fd_free_dma() CSW._free_dma(FLOPPY_DMA)
+#define fd_get_dma_residue()CSW._get_dma_residue(FLOPPY_DMA)
+#define fd_dma_mem_alloc(size) CSW._dma_mem_alloc(size)
+#define fd_dma_setup(addr, size, mode, io) CSW._dma_setup(addr, size, mode, io)
#define fd_enable_irq() enable_irq(FLOPPY_IRQ)
#define fd_disable_irq()disable_irq(FLOPPY_IRQ)
-#define fd_cacheflush(addr,size) /* nothing */
-#define fd_request_irq()request_irq(FLOPPY_IRQ, floppy_interrupt, \
- SA_INTERRUPT|SA_SAMPLE_RANDOM, \
- "floppy", NULL)
#define fd_free_irq() free_irq(FLOPPY_IRQ, NULL);
-__inline__ void virtual_dma_init(void)
+static int virtual_dma_count;
+static int virtual_dma_residue;
+static char *virtual_dma_addr;
+static int virtual_dma_mode;
+static int doing_pdma;
+
+static irqreturn_t floppy_hardint(int irq, void *dev_id, struct pt_regs * regs)
+{
+ register unsigned char st;
+
+#undef TRACE_FLPY_INT
+
+#ifdef TRACE_FLPY_INT
+ static int calls=0;
+ static int bytes=0;
+ static int dma_wait=0;
+#endif
+ if (!doing_pdma)
+ return floppy_interrupt(irq, dev_id, regs);
+
+#ifdef TRACE_FLPY_INT
+ if(!calls)
+ bytes = virtual_dma_count;
+#endif
+ {
+ register int lcount;
+ register char *lptr;
+
+ st = 1;
+ for(lcount=virtual_dma_count, lptr=virtual_dma_addr;
+ lcount; lcount--, lptr++) {
+ st=inb(virtual_dma_port+4) & 0xa0 ;
+ if(st != 0xa0)
+ break;
+ if(virtual_dma_mode)
+ outb_p(*lptr, virtual_dma_port+5);
+ else
+ *lptr = inb_p(virtual_dma_port+5);
+ }
+ virtual_dma_count = lcount;
+ virtual_dma_addr = lptr;
+ st = inb(virtual_dma_port+4);
+ }
+
+#ifdef TRACE_FLPY_INT
+ calls++;
+#endif
+ if(st == 0x20)
+ return IRQ_HANDLED;
+ if(!(st & 0x20)) {
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
+#ifdef TRACE_FLPY_INT
+ printk("count=%x, residue=%x calls=%d bytes=%d dma_wait=%d\n",
+ virtual_dma_count, virtual_dma_residue, calls, bytes,
+ dma_wait);
+ calls = 0;
+ dma_wait=0;
+#endif
+ doing_pdma = 0;
+ floppy_interrupt(irq, dev_id, regs);
+ return IRQ_HANDLED;
+ }
+#ifdef TRACE_FLPY_INT
+ if(!virtual_dma_count)
+ dma_wait++;
+#endif
+ return IRQ_HANDLED;
+}
+
+static void vdma_disable_dma(unsigned int dummy)
{
- /* Nothing to do on PowerPC */
+ doing_pdma = 0;
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
}
+static int vdma_request_dma(unsigned int dmanr, const c
Re: [PATCH] Run softirqs on proper processor on offline
On Tue, 15 Feb 2005, Andrew Morton wrote: > Zwane Mwaikambo <[EMAIL PROTECTED]> wrote: > > > > Ensure that we only offline the processor when it's safe and never run > > softirqs in another processor's ksoftirqd context. This also gets rid of > > the warnings in ksoftirqd on cpu offline. > > I don't get it. ksoftirqd is pinned to its cpu, so why does any of this > matter? We take down ksoftirqds at CPU_DEAD time, so there is a brief period whereupon there is a ksoftirqd thread for an offline processor, it is at this point that ->cpus_allowed won't have it pinned anymore. An online processor would then take down that ksoftirqd and exit it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Model hack (or "how to do it") -- Acer Aspire 1406LC ole's radeonfb patch I have to turn off dri, and then it works with the radeonfb patch. I use this method because I like the fancy framebuffersplash on booting .. although I do not reboot often when S3 wors ;) You can find the patch here: http://dev.gentoo.org/~marineam/patch-radeonfb-2.6.11-rc2-mm2 or for older kernels: http://dev.gentoo.org/~genstef/files/radeon-s3-resume-2.6.10.patch The problems with this patch are: - you need to press a key to come back from the "resume-console" after resume. - DRI in X does not work (at least for me with intel-agp, others reportet it works) I just disabloed it by not loading intel-agp (hotplug-blacklist) I have not only issues with video not coming back, but I also need to append acpi=noirq to my command-line that I am able to finish resuming and use my devices correctly afterwards. Regards, Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Run softirqs on proper processor on offline
Zwane Mwaikambo <[EMAIL PROTECTED]> wrote: > > Ensure that we only offline the processor when it's safe and never run > softirqs in another processor's ksoftirqd context. This also gets rid of > the warnings in ksoftirqd on cpu offline. I don't get it. ksoftirqd is pinned to its cpu, so why does any of this matter? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RCF/RFT] Fix race timer race in gameport-based joystick drivers
Somehow missed sidewinder driver...
==
Input: fix timer handling race in sidewinder joystick driver by
switching to gameport's polling facilities.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
= drivers/input/joystick/sidewinder.c 1.19 vs edited =
--- 1.19/drivers/input/joystick/sidewinder.c2005-02-10 19:00:00 -05:00
+++ edited/drivers/input/joystick/sidewinder.c 2005-02-14 21:36:26 -05:00
@@ -58,7 +58,6 @@
#define SW_BAD 2 /* Number of packet read errors to switch off
3d Pro optimization */
#define SW_OK 64 /* Number of packet read successes to switch
optimization back on */
#define SW_LENGTH 512 /* Max number of bits in a packet */
-#define SW_REFRESH HZ/50 /* Time to wait between updates of joystick
data [20 ms] */
#ifdef SW_DEBUG
#define dbg(format, arg...) printk(KERN_DEBUG __FILE__ ": " format "\n" , ##
arg)
@@ -115,7 +114,6 @@
struct sw {
struct gameport *gameport;
- struct timer_list timer;
struct input_dev dev[4];
char name[64];
char phys[4][32];
@@ -127,7 +125,6 @@
int ok;
int reads;
int bads;
- int used;
};
/*
@@ -496,22 +493,20 @@
return -1;
}
-static void sw_timer(unsigned long private)
+static void sw_poll(struct gameport *gameport)
{
- struct sw *sw = (void *) private;
+ struct sw *sw = gameport_get_drvdata(gameport);
sw->reads++;
if (sw_read(sw))
sw->bads++;
- mod_timer(&sw->timer, jiffies + SW_REFRESH);
}
static int sw_open(struct input_dev *dev)
{
struct sw *sw = dev->private;
- if (!sw->used++)
- mod_timer(&sw->timer, jiffies + SW_REFRESH);
+ gameport_start_polling(sw->gameport);
return 0;
}
@@ -519,8 +514,7 @@
{
struct sw *sw = dev->private;
- if (!--sw->used)
- del_timer(&sw->timer);
+ gameport_stop_polling(sw->gameport);
}
/*
@@ -606,9 +600,6 @@
}
sw->gameport = gameport;
- init_timer(&sw->timer);
- sw->timer.data = (long) sw;
- sw->timer.function = sw_timer;
gameport_set_drvdata(gameport, sw);
@@ -725,6 +716,9 @@
sw_print_packet("ID", j * 3, idbuf, 3);
sw_print_packet("Data", i * m, buf, m);
#endif
+
+ gameport_set_poll_handler(gameport, sw_poll);
+ gameport_set_poll_interval(gameport, 20);
k = i;
l = j;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Run softirqs on proper processor on offline
* Zwane Mwaikambo <[EMAIL PROTECTED]> wrote: > Ensure that we only offline the processor when it's safe and never run > softirqs in another processor's ksoftirqd context. This also gets rid of > the warnings in ksoftirqd on cpu offline. > > Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]> looks good. Acked-by: Ingo Molnar <[EMAIL PROTECTED]> 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/
[PATCH] Run softirqs on proper processor on offline
Ensure that we only offline the processor when it's safe and never run
softirqs in another processor's ksoftirqd context. This also gets rid of
the warnings in ksoftirqd on cpu offline.
Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc3-mm2/kernel/softirq.c
===
RCS file: /home/cvsroot/linux-2.6.11-rc3-mm2/kernel/softirq.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 softirq.c
--- linux-2.6.11-rc3-mm2/kernel/softirq.c 11 Feb 2005 05:14:57 -
1.1.1.1
+++ linux-2.6.11-rc3-mm2/kernel/softirq.c 12 Feb 2005 18:24:54 -
@@ -355,8 +355,12 @@ static int ksoftirqd(void * __bind_cpu)
set_current_state(TASK_INTERRUPTIBLE);
while (!kthread_should_stop()) {
- if (!local_softirq_pending())
+ preempt_disable();
+ if (!local_softirq_pending()) {
+ preempt_enable_no_resched();
schedule();
+ preempt_disable();
+ }
__set_current_state(TASK_RUNNING);
@@ -364,14 +368,14 @@ static int ksoftirqd(void * __bind_cpu)
/* Preempt disable stops cpu going offline.
If already offline, we'll be on wrong CPU:
don't process */
- preempt_disable();
if (cpu_is_offline((long)__bind_cpu))
goto wait_to_die;
do_softirq();
- preempt_enable();
+ preempt_enable_no_resched();
cond_resched();
+ preempt_disable();
}
-
+ preempt_enable();
set_current_state(TASK_INTERRUPTIBLE);
}
__set_current_state(TASK_RUNNING);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: seccomp for 2.6.11-rc4
On Tue, Feb 15, 2005 at 10:32:44AM +0100, Andrea Arcangeli wrote: > Hello, > > This is the latest version against 2.6.11-rc4: > > > http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.11-rc4/seccomp > > I'd need it merged into mainline at some point, unless anybody has > strong arguments against it. All I can guarantee here, is that I'll back > it out myself in the future, iff Cpushare will fail and nobody else > started using it in the meantime for similar security purposes. hmm, just an idea, but have you thought about using an indirect syscall table for your purposes? current->syscall_table and have a table for every 'mode' you want to use ... or maybe have a 'mask' for every syscall (in a separate table) which describes the allowed 'modes' just because checking the syscall number in a loop doesn't look very scaleable to me ... best, Herbert > Thanks. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.11-rc4]: IBM TrackPoint configuration support
Hi,
sorry, couple of more things (and I promise I will shut up ;))
> /*
> + * Try to initialize the IBM TrackPoint
> + */
> + if (max_proto > PSMOUSE_PS2 && trackpoint_init(psmouse) == 0) {
> + psmouse->vendor = "IBM";
> + psmouse->name = "TrackPoint";
> +
> + return PSMOUSE_PS2;
> + }
I would like you to change the code so that psmouse structure only
changed when set_properties is set. Probably moving these into
trackpoint_init is a good idea since _init should not override
psmouse->private unless told to do so. It is important when the device
was not identified as a trackpoint but later (let's say after resume)
it is - in this case generic reconnect will cause psmouse_extensions
with set_properties = 0 to verify protocol and we dont' want to change
anything in psmouse to give the original disconnect handler change to
clean up properly.
Thinking about it some more I am pretty sure that you need a special
protocol number for the trackpoint, because protocol number is used
by psmouse_reconnect to check whether reconnect can be done or rescan
is needed. You can reuse the standard protocol handler, but you need
the new number. This way if trackpad was not identified as such first
time around, but is identified on reconnect psmouse-base would notice
that it is a new type of device and schedule reconnect and will proper
cleanup/initialization.
Does this make sense?
> +
> +#define MAKE_ATTR_WRITE(_item, command) \
> +static ssize_t psmouse_attr_set_##_item(struct psmouse
> *psmouse, const char *buf, size_t count) \
It looks like the patch got mangled on it's way, please check your mail
client.
> +{ \
> + char *rest; \
> +unsigned long value; \
> +struct trackpoint_data *tp = psmouse->private; \
> +value = simple_strtoul(buf, &rest, 10); \
Whitespace damage (tabs vs. spaces). Also there are some trailing
whitespace. If you are using vi I find the following helpful to
highlight the problem spots:
set listchars=tab:\|-
highlight WhitespaceEOL ctermbg=red guibg=red
match WhitespaceEOL /\s\+$/
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: queue_work from interrupt Real time preemption2.6.11-rc2-RT-V0.7.37-03
* Mark Gross <[EMAIL PROTECTED]> wrote: > I'm attempting to change the softIRQ preemption implementation to use > work queues (one per softIRQ), that allow for runtime priority changes > on a per-soft IRQ bases. To do this I was trying to have > raise_softirq call queu_work directly. queue_work, doesn't use the > *_nort() api's. > > My alternitive is to put the call to queue_work into do_softIRQ. > Which seems to work, but feels like a bit too much indirection to > queue up the soft IRQ bottom half processing. correct, that may be too much of an indirection. we cannot turn queue_work()'s spinlocks into raw spinlocks, because that would necessiate waitqueue locks to be raw spinlocks too, which would be generally bad. Check out how entangled the cwq->work_done and cwq->more_work waitqueues are with cwq->lock. also, i'm not sure about how correctly this maps to the upstream softirq semantics. Right now softirqs are processed by a single context (per CPU), and each softirq type is processed serially. Softirqs are preemptable, but they dont preempt each other. Maybe the networking stack would break if we allowed the TIMER softirq (thread) to preempt the NET softirq (threads) (and vice versa)? but, prioritizing individual softirqs (within the PREEMPT_RT framework) is something that needs to be thought about - e.g. Mark H. Johnson reported various PREEMPT_RT (and softirq threading) SMP artifacts that seem to be related to the current 'all softirqs are processed by a single thread' approach. (check Mark's postings for 'ping' latency anomalies) 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: -rc3 leaking NOT BIO [Was: Memory leak in 2.6.11-rc1?]
Parag Warudkar <[EMAIL PROTECTED]> wrote:
>
> I am running -rc3 on my AMD64 laptop and I noticed it becomes sluggish after
> use mainly due to growing swap use. It has 768M of RAM and a Gig of swap.
> After following this thread, I started monitoring /proc/slabinfo. It seems
> size-64 is continuously growing and doing a compile run seem to make it grow
> noticeably faster. After a day's uptime size-64 line in /proc/slabinfo looks
> like
>
> size-64 7216543 7216544 64 611 : tunables 120 600
> :
> slabdata 118304 118304 0
Plenty of moisture there.
Could you please use this patch? Make sure that you enable
CONFIG_FRAME_POINTER (might not be needed for __builtin_return_address(0),
but let's be sure). Also enable CONFIG_DEBUG_SLAB.
From: Manfred Spraul <[EMAIL PROTECTED]>
With the patch applied,
echo "size-4096 0 0 0" > /proc/slabinfo
walks the objects in the size-4096 slab, printing out the calling address
of whoever allocated that object.
It is for leak detection.
diff -puN mm/slab.c~slab-leak-detector mm/slab.c
--- 25/mm/slab.c~slab-leak-detector 2005-02-15 21:06:44.0 -0800
+++ 25-akpm/mm/slab.c 2005-02-15 21:06:44.0 -0800
@@ -2116,6 +2116,15 @@ cache_alloc_debugcheck_after(kmem_cache_
*dbg_redzone1(cachep, objp) = RED_ACTIVE;
*dbg_redzone2(cachep, objp) = RED_ACTIVE;
}
+ {
+ int objnr;
+ struct slab *slabp;
+
+ slabp = GET_PAGE_SLAB(virt_to_page(objp));
+
+ objnr = (objp - slabp->s_mem) / cachep->objsize;
+ slab_bufctl(slabp)[objnr] = (unsigned long)caller;
+ }
objp += obj_dbghead(cachep);
if (cachep->ctor && cachep->flags & SLAB_POISON) {
unsigned long ctor_flags = SLAB_CTOR_CONSTRUCTOR;
@@ -2179,12 +2188,14 @@ static void free_block(kmem_cache_t *cac
objnr = (objp - slabp->s_mem) / cachep->objsize;
check_slabp(cachep, slabp);
#if DEBUG
+#if 0
if (slab_bufctl(slabp)[objnr] != BUFCTL_FREE) {
printk(KERN_ERR "slab: double free detected in cache
'%s', objp %p.\n",
cachep->name, objp);
BUG();
}
#endif
+#endif
slab_bufctl(slabp)[objnr] = slabp->free;
slabp->free = objnr;
STATS_DEC_ACTIVE(cachep);
@@ -2998,6 +3009,29 @@ struct seq_operations slabinfo_op = {
.show = s_show,
};
+static void do_dump_slabp(kmem_cache_t *cachep)
+{
+#if DEBUG
+ struct list_head *q;
+
+ check_irq_on();
+ spin_lock_irq(&cachep->spinlock);
+ list_for_each(q,&cachep->lists.slabs_full) {
+ struct slab *slabp;
+ int i;
+ slabp = list_entry(q, struct slab, list);
+ for (i = 0; i < cachep->num; i++) {
+ unsigned long sym = slab_bufctl(slabp)[i];
+
+ printk("obj %p/%d: %p", slabp, i, (void *)sym);
+ print_symbol(" <%s>", sym);
+ printk("\n");
+ }
+ }
+ spin_unlock_irq(&cachep->spinlock);
+#endif
+}
+
#define MAX_SLABINFO_WRITE 128
/**
* slabinfo_write - Tuning for the slab allocator
@@ -3038,9 +3072,11 @@ ssize_t slabinfo_write(struct file *file
batchcount < 1 ||
batchcount > limit ||
shared < 0) {
- res = -EINVAL;
+ do_dump_slabp(cachep);
+ res = 0;
} else {
- res = do_tune_cpucache(cachep, limit,
batchcount, shared);
+ res = do_tune_cpucache(cachep, limit,
+ batchcount, shared);
}
break;
}
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Thoughts on the "No Linux Security Modules framework" old claims
On Tue, 15 Feb 2005 23:38:09 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= said: > Yes, and that's noticed from the "official" documentation. > But, who says that we can't place auditing facilities inside the > existing hooks? or even file system linking related tweaks? Many auditing policies require an audit event to be generated if the operation is rejected by *either* the DAC (as implemented by the file permissions and possibly ACLs) *or* the MAC (as implemented by the LSM exit). However, in most (all?) cases, the DAC check is made *first*, and the LSM exit isn't even called if the DAC check fails. As a result, if you try to open() a file and get -EPERM due to the file permissions, the LSM exit isn't called and you can't cut an audit record there. pgpIg1VbKxmpP.pgp Description: PGP signature
Re: PATCH 2.6.11-rc4]: IBM TrackPoint configuration support
On Tue, 15 Feb 2005 15:16:18 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> Stephen, if you fix the above, and send me the patch, I'll merge it,
> there isn't any other problem with it.
Ok, more descriptive names, I noticed that psmouse->disconnect wasn't
being called when my laptop suspended so I made the reconnect function
sync the in memory configuration with what is actually on the device.
Also, I removed the external port disable commands in trackpoint_init
-- they didn't seem to do anything on my T23.
Stephen
diff -uNr a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
--- a/drivers/input/mouse/Makefile 2005-02-13 12:47:32.0 -0500
+++ b/drivers/input/mouse/Makefile 2005-02-13 12:46:30.0 -0500
@@ -14,4 +14,4 @@
obj-$(CONFIG_MOUSE_SERIAL) += sermouse.o
obj-$(CONFIG_MOUSE_VSXXXAA)+= vsxxxaa.o
-psmouse-objs := psmouse-base.o alps.o logips2pp.o synaptics.o
+psmouse-objs := psmouse-base.o alps.o logips2pp.o synaptics.o trackpoint.o
diff -uNr a/drivers/input/mouse/psmouse-base.c
b/drivers/input/mouse/psmouse-base.c
--- a/drivers/input/mouse/psmouse-base.c2005-02-13 12:47:32.0
-0500
+++ b/drivers/input/mouse/psmouse-base.c2005-02-13 17:33:17.0
-0500
@@ -23,6 +23,7 @@
#include "psmouse.h"
#include "synaptics.h"
#include "logips2pp.h"
+#include "trackpoint.h"
#include "alps.h"
#define DRIVER_DESC"PS/2 mouse driver"
@@ -482,6 +483,16 @@
return PSMOUSE_IMPS;
/*
+ * Try to initialize the IBM TrackPoint
+ */
+ if (max_proto > PSMOUSE_PS2 && trackpoint_init(psmouse) == 0) {
+ psmouse->vendor = "IBM";
+ psmouse->name = "TrackPoint";
+
+ return PSMOUSE_PS2;
+ }
+
+/*
* Okay, all failed, we have a standard mouse here. The number of the buttons
* is still a question, though. We assume 3.
*/
diff -uNr a/drivers/input/mouse/trackpoint.c b/drivers/input/mouse/trackpoint.c
--- a/drivers/input/mouse/trackpoint.c 1969-12-31 19:00:00.0 -0500
+++ b/drivers/input/mouse/trackpoint.c 2005-02-15 23:05:08.0 -0500
@@ -0,0 +1,344 @@
+/*
+ * Stephen Evanchik <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * Trademarks are the property of their respective owners.
+ *
+ * 13/02/2005 - Removed middle button scroll, see Xorg for
+ * scroll emulation.
+ *
+ * 03/02/2005 - Remove proc and module parameters
+ * Added sysfs attributes
+ *
+ * 29/01/2005 - Fixed UltraNav support
+ * Moved to libps2 interface
+ * Renamed internal property variables to be consistent with
reference docs
+ * Fixed negative inertia not being set properly
+ * Added middle button scroll module parameter
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "psmouse.h"
+#include "trackpoint.h"
+
+
+PSMOUSE_DEFINE_ATTR(sensitivity);
+PSMOUSE_DEFINE_ATTR(speed);
+PSMOUSE_DEFINE_ATTR(inertia);
+PSMOUSE_DEFINE_ATTR(reach);
+PSMOUSE_DEFINE_ATTR(draghys);
+PSMOUSE_DEFINE_ATTR(mindrag);
+PSMOUSE_DEFINE_ATTR(thresh);
+PSMOUSE_DEFINE_ATTR(upthresh);
+PSMOUSE_DEFINE_ATTR(ztime);
+PSMOUSE_DEFINE_ATTR(jenks);
+PSMOUSE_DEFINE_ATTR(press_to_select);
+PSMOUSE_DEFINE_ATTR(skipback);
+PSMOUSE_DEFINE_ATTR(middle_btn_disable);
+PSMOUSE_DEFINE_ATTR(ext_dev);
+PSMOUSE_DEFINE_ATTR(transparent);
+
+
+#define MAKE_ATTR_READ(_item) \
+static ssize_t psmouse_attr_show_##_item(struct psmouse
*psmouse, char *buf) \
+{ \
+struct trackpoint_data *tp = psmouse->private; \
+return sprintf(buf, "%lu\n", (unsigned long)tp->_item); \
+}
+
+#define MAKE_ATTR_WRITE(_item, command) \
+static ssize_t psmouse_attr_set_##_item(struct psmouse
*psmouse, const char *buf, size_t count) \
+{ \
+ char *rest; \
+unsigned long value; \
+struct trackpoint_data *tp = psmouse->private; \
+value = simple_strtoul(buf, &rest, 10); \
+ if(*rest) \
+ return -EINVAL; \
+ tp->_item = value; \
+trackpoint_write(&psmouse->ps2dev, command, tp->_item); \
+return count; \
+}
+
+#define MAKE_ATTR_TOGGLE(_item, command, mask) \
+static ssize_t psmouse_attr_set_##_item(struct psmouse
*psmouse, const char *buf, size_t count) \
+{ \
+unsigned char toggle; \
+struct trackpoint_data *tp = psmouse->private; \
+toggle = (buf[0] == '1') ? 1 : 0; \
+if( toggle != tp->_item) { \
+tp->_item = toggle; \
+trackpoint_toggle_bit(&psmouse->ps2dev,
command, mask); \
+} \
+ret
Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II
Andi Kleen wrote: Making memory migration a subset of page migration is not a general solution. It only works for programs that are using memory policy to control placement. As I've tried to point out multiple times before, most programs that I am aware of use placement based on first-touch. When we migrate such programs, we have to respect the placement decisions that the program has implicitly made in this way. Sorry, but the only real difference between your API and mbind is that yours has a pid argument. That may be true, but the internals of the implementations have got to be pretty different as near as I can tell. So just beause the API's are nearly the same doesn't imply that the internals are at all the same. And I'm convinced that using node masks is an insufficiently general approach to specifying page migration. But let's save that discussion for a later note, ok? I think we are talking by each other, here's a more structured overview of my thinking on the issue. I'm sure that is what is going on and we face little other choice than keep our good humor about this and keep trying until we see our way clear to a common understanding. :-) Main cases: - Program is NUMA API aware. Fine. It takes care of its own. Yes, we could migrate this program using a migration facility embedded in the NUMA API. - Program is not aware, but is started with a process policy from numactl/cpusets/batch scheduler. Already covered too in NUMA API. Hmmm What about the case where no NUMA API is used and cpusets are used as containers, and page placement is done by first touch. Then there no NUMA API whatsoever. I think this is the category where most of the programs in a large Altix system would fall. (See more on this below) - Program is not aware and hasn't been started with a policy (or has and you change your mind) but you want to change it later. I'm having a little trouble parsing the "it" in that sentence. Does that sentence mean "you want to change the NUMA API later"? What if there never is a NUMA API structure associated with the program other than the default (local) policy? The fundamental disconnect here is that I think that very few programs use the NUMA API, and you think that most programs do. Eventually more programs will use the NUMA API, but I don't think they do at the present time. Let me expand on that a bit. What most programs do on Altix is to do first-touch to get data allocated locally. That is, lets say you have a big array that your parallel computation is going to work on. The programmer would sit down and say, I want processor 1 to work on this part of the array, processor 2 on that part, etc. Then the programmer writes code that causes each processor to touch the portions of the data array that should be allocated locally on that processor. Bingo, storage is now allocated the way the user wants it, and no NUMA API call was ever issued. Yes, it is clumsy, but that is because these programs were written before your NUMA API came into being. Now we simply can't go back to these people (many of them ISV's) and say "Please rewrite your code to use the NUMA API." So we are left with a pile of legacy programs that we have to be able to migrate that don't have any NUMA api data structures associated with them. What are we supposed to do in this case? We can't necessarily construct a NUMA API that will cause storage to be allocated as the programmer intended, because we can't fathom what the programmer was trying to accomplish based on the state of the program when we go to migrate it. So how would we use a migration facility embedded into the NUMA API to migrate this program and maintain its old topology? That's the fundamental question here. Can you address that question specifically for me, please? That's the new case we discuss here. Now how to change policy of objects in an already running process. If the running process has a non-trivial mempolicy defined for all of its address space, then I think I understand this. This is not where our disconnect lies. The disconnect is in the above, I think. First there are already some special cases already handled or with existing patches: - tmpfs/hugetlbfs/sysv shm: numactl can handle this by just mapping the object into a different process and changing the policy there. - shared libraries and mmaped files in general: this is a generialization of the previous point. SteveL's patch is the beginning of handling this, although it needs some more work (xattrs) to make the policy persistent over memory pressure. Only case not covered left is anonymous memory. You said it would need user space control, but the main reason for wanting that seems to be to handle the non anonymous cases which are already covered above. Yes, so long as the rest of the cases were handled in user space, then the anonymous memory case has to be handled there as well. My thinking is the simplest way to handle that is to have a call that just o migrate
(no subject)
Unsubscribe linux-kernel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pty is losing bytes
On Wed, 16 Feb 2005, Roman Zippel wrote:
>
> The patch below seems to do the trick too.
> It seems the initial receive_room() call in pty_write() returns
> N_TTY_BUF_SIZE and receive_buf() will happily drop the last byte.
Why have that "tty->icanon && !tty->canon_data" test in the first place, I
wonder? Isn't the "left" calculation always correct? That's really how
many bytes free we have in the tty, that "canon_data" thing is just about
how much of it is available for _reading_ as canon, no? (Ie "how many
characters that have seen a finishing end-of-line"). So I don't see why
that canon_data test is relevant to the question of filling the buffer..
In particular, afaikt, "canon_data" can be zero even if we _have_
characters in the queue (just not aany EOLN), so I'd expect your version
to still return "N_TTY_BUF_SIZE-1" even though the queue can only actually
take fewer characters..
So I'd still worry whether that added -1 actually fixes the bug, or just
means that a off-by-one has to now be off-by-two to be noticeable.. (In
contrast, changing the chunking to 2kB not only changes a "off-by-one" to
a "off-by-2048", but more importantly is what we've tested for the last
decade or so ;)
In fact, I _think_ that the whole
if (tty->icanon && !tty->canon_data)
test is about the fact that we _want_ the writer to start dropping
characters at some point, since if we're in canon mode, we need to get a
full line in the end, and if there is no EOLN to be had, then we _need_ to
drop characters.
So I'd think that the n_tty_receive_room() function should look something
like this:
static int n_tty_receive_room(struct tty_struct *tty)
{
int left = N_TTY_BUF_SIZE - tty->read_cnt - 1;
if (left <= 0)
left = tty->icanon && !tty->canon_data;
return left;
}
which basically says: only accept as much data as we can fit in the
buffer, BUT if we can't really fit anything and we're in canon mode (but
haven't seen a newline yet), we need to allow the writer to continut to
trickle data (that we will discard) in the hopes of _eventually_ seeing an
EOLN.
Does that make sense to you? Maybe the "input full, but no canon_data"
special case would be better handled in the read path, rather than the
write path?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] quiet non-x86 option ROM warnings
On Tue, 2005-02-15 at 20:08 -0500, Jon Smirl wrote: > There is a new io resource flag as part of the pci rom code, > IORESOURCE_ROM_SHADOW, that is used on x86. If IORESOURCE_ROM_SHADOW > is set, you should ignore the physical ROM and use the copy at C000:0. > Can we build an equivalent flag for PPC? On x86 arch specific code > determines the boot video device and sets the flag. > > Acutally, if radeon and rage fb drivers were using the PCI ROM support > (drivers/pci/rom.c) would they be having this problem? The 55AA check > is in the PCI ROM support too. No, such a flag wouldn't make sense as it's not really a ROM shadow. In fact, the driver is just part of the main open firmware, there are no tables we can get to like x86 etc... however, we can access properties in the open firmware device-tree that have been set by the OF driver. So it's a completely different mecanism. A ROM shadow bit wouldn't make sense. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
-rc3 leaking NOT BIO [Was: Memory leak in 2.6.11-rc1?]
I am running -rc3 on my AMD64 laptop and I noticed it becomes sluggish after use mainly due to growing swap use. It has 768M of RAM and a Gig of swap. After following this thread, I started monitoring /proc/slabinfo. It seems size-64 is continuously growing and doing a compile run seem to make it grow noticeably faster. After a day's uptime size-64 line in /proc/slabinfo looks like size-64 7216543 7216544 64 611 : tunables 120 600 : slabdata 118304 118304 0 Since this doesn't seem to bio, I think we have another slab leak somewhere. The box recently went OOM during a gcc compile run after I killed the swap. Output from free , OOM Killer, and /proc/slabinfo is down below.. free output - total used free sharedbuffers cached Mem:767996 758120 9876 0 5276 130360 -/+ buffers/cache: 622484 145512 Swap: 1052248 67668 984580 OOM Killer Output oom-killer: gfp_mask=0x1d2 DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 HighMem per-cpu: empty Free pages:7260kB (0kB HighMem) Active:62385 inactive:850 dirty:0 writeback:0 unstable:0 free:1815 slab:120136 mapped:62334 pagetables:2110 DMA free:3076kB min:72kB low:88kB high:108kB active:3328kB inactive:0kB present:16384kB pages_scanned:4446 all_unreclaimable? yes lowmem_reserve[]: 0 751 751 Normal free:4184kB min:3468kB low:4332kB high:5200kB active:246212kB inactive:3400kB present:769472kB pages_scanned:3834 all_unreclaimable? no lowmem_reserve[]: 0 0 0 HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 1*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3076kB Normal: 170*4kB 10*8kB 2*16kB 0*32kB 1*64kB 0*128kB 1*256kB 2*512kB 0*1024kB 1*2048kB 0*4096kB = 4184kB HighMem: empty Swap cache: add 310423, delete 310423, find 74707/105490, race 0+0 Free swap = 0kB Total swap = 0kB Out of Memory: Killed process 4898 (klauncher). oom-killer: gfp_mask=0x1d2 DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 HighMem per-cpu: empty Free pages:7020kB (0kB HighMem) Active:62308 inactive:648 dirty:0 writeback:0 unstable:0 free:1755 slab:120439 mapped:62199 pagetables:2020 DMA free:3076kB min:72kB low:88kB high:108kB active:3336kB inactive:0kB present:16384kB pages_scanned:7087 all_unreclaimable? yes lowmem_reserve[]: 0 751 751 Normal free:3944kB min:3468kB low:4332kB high:5200kB active:245896kB inactive:2592kB present:769472kB pages_scanned:3861 all_unreclaimable? no lowmem_reserve[]: 0 0 0 HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 1*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3076kB Normal: 112*4kB 9*8kB 0*16kB 1*32kB 1*64kB 0*128kB 1*256kB 2*512kB 0*1024kB 1*2048kB 0*4096kB = 3944kB HighMem: empty Swap cache: add 310423, delete 310423, find 74707/105490, race 0+0 Free swap = 0kB Total swap = 0kB Out of Memory: Killed process 4918 (kwin). /proc/slabinfo output ipx_sock 0 089641 : tunables 54 270 : slabdata 0 0 0 scsi_cmd_cache 3 757671 : tunables 54 270 : slabdata 1 1 0 ip_fib_alias 10119 32 1191 : tunables 120 600 : slabdata 1 1 0 ip_fib_hash 10 61 64 611 : tunables 120 600 : slabdata 1 1 0 sgpool-12832 32 409611 : tunables 24 120 : slabdata 32 32 0 sgpool-64 32 32 204821 : tunables 24 120 : slabdata 16 16 0 sgpool-32 32 32 102441 : tunables 54 270 : slabdata 8 8 0 sgpool-16 32 3251281 : tunables 54 270 : slabdata 4 4 0 sgpool-8 32 45256 151 : tunables 120 600 : slabdata 3 3 0 ext3_inode_cache2805 3063 122431 : tunables 24 120 : slabdata 1021 1021 0 ext3_xattr 0 0 88 451 : tunables 120 600 : slabdata 0 0 0 journal_handle16156 24 1561 : tunables 120 600 : slabdata 1 1 0 journal_head 49180 88 451 : tunables 120 600 : slabdata 4 4 0 revoke_table 6225 16 2251 : tunables 120 600 : slabdata 1 1 0 revoke_record 0 0 32 1191 : tun
Re: [PATCH] add "bus" symlink to class/block devices
On Tuesday 15 February 2005 18:44, Greg KH wrote:
> On Tue, Feb 15, 2005 at 05:25:54PM -0500, Dmitry Torokhov wrote:
> > On Tue, 15 Feb 2005 23:04:06 +0100, Kay Sievers <[EMAIL PROTECTED]> wrote:
> > >
> > > -static int class_device_dev_link(struct class_device * class_dev)
> > > -{
> > > - if (class_dev->dev)
> > > - return sysfs_create_link(&class_dev->kobj,
> > > -&class_dev->dev->kobj, "device");
> > > - return 0;
> > > -}
> > > -
> > > -static void class_device_dev_unlink(struct class_device * class_dev)
> > > -{
> > > - sysfs_remove_link(&class_dev->kobj, "device");
> > > -}
> > > -
> >
> > Hi,
> >
> > I can agree on dropping driver link but I think that the link to
> > underlying real device is still needed.
>
> It's still there, read the patch :)
>
Oops, missed that. Sorry.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Pty is losing bytes
Hi, On Tue, 15 Feb 2005, Linus Torvalds wrote: > > I've also seen more than one byte missing. For example when sending a big > > chunk of bytes down the pty via an Emacs *shell* buffer up to 16 bytes are > > missing somewhere in the middle. > > If it's NTTY (and I'm pretty certain it is - the generic tty code looks > fine, the pty code itself is too simple for words), then I'd actually have > expected more variability than a simple off-by-one. The patch below seems to do the trick too. It seems the initial receive_room() call in pty_write() returns N_TTY_BUF_SIZE and receive_buf() will happily drop the last byte. bye, Roman n_tty.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6/drivers/char/n_tty.c === --- linux-2.6.orig/drivers/char/n_tty.c 2005-02-16 03:53:53.0 +0100 +++ linux-2.6/drivers/char/n_tty.c 2005-02-16 03:56:39.0 +0100 @@ -863,7 +863,7 @@ static int n_tty_receive_room(struct tty * characters will be beeped. */ if (tty->icanon && !tty->canon_data) - return N_TTY_BUF_SIZE; + return N_TTY_BUF_SIZE - 1; if (left > 0) return left; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FIx u32 vs. pm_message_t confusion in firewire
On Tue, Feb 15, 2005 at 01:47:59AM +0100, Pavel Machek wrote:
> Hi!
>
> This should fix u32 vs. pm_message_t confusion in firewire. No code
> changes. Please apply,
> Pavel
Applied to 1394 SVN and development bitkeeper. I will send this
upstream sometime after 2.6.11.
Thanks,
Jody
> Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
>
> --- clean-mm/drivers/ieee1394/nodemgr.c 2005-02-15 00:46:40.0
> +0100
> +++ linux-mm/drivers/ieee1394/nodemgr.c 2005-02-15 01:04:10.0
> +0100
> @@ -1284,7 +1284,7 @@
>
> if (ud->device.driver &&
> (!ud->device.driver->suspend ||
> - ud->device.driver->suspend(&ud->device, 0, 0)))
> + ud->device.driver->suspend(&ud->device, PMSG_SUSPEND, 0)))
> device_release_driver(&ud->device);
> }
> up_write(&ne->device.bus->subsys.rwsem);
> --- clean-mm/drivers/ieee1394/ohci1394.c 2005-02-15 00:46:40.0
> +0100
> +++ linux-mm/drivers/ieee1394/ohci1394.c 2005-02-15 01:04:10.0
> +0100
> @@ -3546,7 +3546,7 @@
> }
>
>
> -static int ohci1394_pci_suspend (struct pci_dev *pdev, u32 state)
> +static int ohci1394_pci_suspend (struct pci_dev *pdev, pm_message_t state)
> {
> #ifdef CONFIG_PMAC_PBOOK
> {
>
>
> --
> People were complaining that M$ turns users into beta-testers...
> ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Call for help: list of machines with working S3
Hi. On Wed, 2005-02-16 at 12:54, Pavel Machek wrote: > > Also, is USB suspend/resume supposed to work? My brief trials involved > > modprobing the USB HCD modules, which still allowed me to suspend/resume, > > but > > my USB mouse was non-functional on resume. > > Yes, it seems to work quite okay. You may need to unplug/replug > devices after resume, but it should be basically ok. We still have plenty of people for whom the best option is to build as modules, unload prior to suspending and reload afterwards. It seems to depend on what type your controller is: I do this for uhci_hcd and get fully functional usb post resume (-rc4). Regards, Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon FB troubles with recent kernels
On Tue, 2005-02-15 at 20:53 -0500, Vincent C Jones wrote: > > Kernel command line: auto BOOT_IMAGE=Test_9.2 ro root=306 pci=usepirqmask > desktop idebus=66 video=radeonfb:[EMAIL PROTECTED] > > Note the "video=radeonfb:[EMAIL PROTECTED]" which used to be required to > get the console into 1024x768 mode but is documented in "modefb.txt" > as an invalid combination of mode specifications (and also states > that radeonfb does not support mode specification...). So other > than the loss of temporary working of backlight controls, I just > see undocumented progress :-) > > Thanks again, and keep up the great work! Heh, good. Well, the mode spec should work in fact, provided that you get the syntax right, though I haven't tried. I'll have a look later, but if it doesn't work, then it was always broken and it's not a regression :) I still want to fix more stuff in this area, but for now, I'm concerned mostly about regressions. Can you remind me exactly what's up with the backlight control ? Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] kthread_bind new worker threads when onlining cpu
Hi Andrew-
On Tue, Feb 15, 2005 at 08:02:17AM +0100, Ingo Molnar wrote:
>
> * Nathan Lynch <[EMAIL PROTECTED]> wrote:
>
> >
> > It looks as if we need to explicitly bind worker threads to a newly
> > onlined cpu. This gets rid of the smp_processor_id warnings from
> > cache_reap. Adding a little more instrumentation to the debug
> > smp_processor_id showed that new worker threads were actually running
> > on the wrong cpu...
> >
> > Does this look ok?
>
> indeed - looks much better than the 'turn off the warning' solution.
>
> Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
We weren't binding new worker threads to their cpu when onlining.
Using preempt and the debug version of smp_processor_id found this.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc4-bk2/kernel/workqueue.c
===
--- linux-2.6.11-rc4-bk2.orig/kernel/workqueue.c2005-02-14
11:13:08.0 -0600
+++ linux-2.6.11-rc4-bk2/kernel/workqueue.c 2005-02-14 15:18:35.0
-0600
@@ -485,8 +485,10 @@
case CPU_ONLINE:
/* Kick off worker threads. */
- list_for_each_entry(wq, &workqueues, list)
+ list_for_each_entry(wq, &workqueues, list) {
+ kthread_bind(wq->cpu_wq[hotcpu].thread, hotcpu);
wake_up_process(wq->cpu_wq[hotcpu].thread);
+ }
break;
case CPU_UP_CANCELED:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] quiet non-x86 option ROM warnings
On Tuesday, February 15, 2005 5:08 pm, Jon Smirl wrote: > There is a new io resource flag as part of the pci rom code, > IORESOURCE_ROM_SHADOW, that is used on x86. If IORESOURCE_ROM_SHADOW > is set, you should ignore the physical ROM and use the copy at C000:0. > Can we build an equivalent flag for PPC? On x86 arch specific code > determines the boot video device and sets the flag. > > Acutally, if radeon and rage fb drivers were using the PCI ROM support > (drivers/pci/rom.c) would they be having this problem? The 55AA check > is in the PCI ROM support too. They're using it, they just do additional checks. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)
In article <[EMAIL PROTECTED]>, Helge Hafting <[EMAIL PROTECTED]> wrote: >Bernd Petrovitsch wrote: >>This would be a win (especially if the numbers are tweked to tune this) >>with a relatively small effort. >>However for real dependencies and parallelism you want the info similar >>to creat a Makefile from it (i.e. the explicit dependency from service X >>to service Y). As a consequence you can get rid of the numbers (since >>they are not needed any more). >> >Now that is a really good idea. Init could simply run "make -j init2" to >enter runlevel 2. A suitable makefile would list all dependencies, and >of course the targets needed for "init2", "init3" and so on. It's not too hard to script it using 'tsort', either. The hard part is getting all the dependencies of the scripts right. And once you've done that, to _keep_ them right. Now how do you implement that on a Debian system that is package-wise somewhere between potato and sarge ... (yes, I've encountered those). Solveable, not trivial. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: Call for help: list of machines with working S3
Hi! > > I would advise trying to compile a custom kernel from scratch with my > > .config first. > > > > I got S3 working first with a very basic kernel config, but I couldn't > > get it to work with my usual kernel. Assuming it was some feature that > > caused the problem, I started disabling features in the hope of getting > > it to work, but I ended up with two different kernels with seemingly > > irrelevant differences, of which one would succesfully resume and one > > wouldn't. So I started added features to the other kernel, and I never > > found out what caused the problem. > > I took your advice and built your kernel with a few modifications (XFS > instead > of ext, etc.). If I boot the kernel with init=/bin/sh, I can actually > suspend! Thanks! > > I will exhaustively enable and disable drivers tomorrow to figure out which > one is causing suspend to fail when I do a complete boot. Whatever we find is > clearly a bug that should be fixed. > > It is not the framebuffer driver (I always ran without vesafb or radeonfb), > and it is not my ipw2200 or USB drivers. > > Also, is USB suspend/resume supposed to work? My brief trials involved > modprobing the USB HCD modules, which still allowed me to suspend/resume, but > my USB mouse was non-functional on resume. Yes, it seems to work quite okay. You may need to unplug/replug devices after resume, but it should be basically ok. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon FB troubles with recent kernels
On Wed, Feb 16, 2005 at 09:02:01AM +1100, Benjamin Herrenschmidt wrote: > On Tue, 2005-02-15 at 10:07 -0500, Vincent C Jones wrote: > > > .../... > > > > radeonfb: panel ID string: 1024x768 > > radeonfb: detected LVDS panel size from BIOS: 1024x768 > > BIOS provided panel power delay: 1000 > > radeondb: BIOS provided dividers will be used > > ref_divider = 8 > > post_divider = 2 > > fbk_divider = 4d > > Scanning BIOS table ... > > 320 x 350 > > 320 x 400 > > 320 x 400 > > 320 x 480 > > 400 x 600 > > 512 x 384 > > 640 x 350 > > 640 x 400 > > 640 x 475 > > 640 x 480 > > 720 x 480 > > 720 x 576 > > 800 x 600 > > 848 x 480 > > 1024 x 768 > > Found panel in BIOS table: > > hblank: 320 > > hOver_plus: 16 > > hSync_width: 136 > > vblank: 38 > > vOver_plus: 2 > > vSync_width: 6 > > clock: 6500 > > Setting up default mode based on panel info > > So far, things look good. At this point, the driver should have obtained > the 1024x768 mode that matches your panel... > > Can you look at radeon_monitor.c, function radeon_check_modes(). This > function calls radeon_get_panel_info_BIOS() which is the above. Then, it > gets into the if () block that follow that comment: > > /* >* If we have some valid panel infos, we setup the default mode based on >* those >*/ > > Could you add some more printk's in there to see what's going on ? It should > setup a 1024x768 mode at this point... > > Also, it should not get into any of the other if () statements of this > function, > except the last bit, in if (1) which adds the panel mode to the list for the > driver. Can you check that happens ? (Especially, check that mode_option is > NULL > and thus the driver isn't trying to override the panel mode from the command > line arguments). This appears to be the challenge... the mode_option is being set from the command line. > > If all of that looks good, then maybe look at what's going on in the function > radeon_match_mode()... Maybe it's not matching the mode properly. > > > radeonfb: Dynamic Clock Power Management enabled > > hStart = 656, hEnd = 792, hTotal = 960 > > vStart = 402, vEnd = 408, vTotal = 438 > > h_total_disp = 0x4f0077hsync_strt_wid = 0x11028a > > v_total_disp = 0x18f01b5 vsync_strt_wid = 0x60191 > > pixclock = 15384 > > freq = 6500 > > Console: switching to colour frame buffer device 53x18 > > radeonfb (:01:00.0): ATI Radeon LY > > radeonfb_pci_register END > > ACPI: AC Adapter [AC] (off-line) . . . Setting up default mode based on panel info vcj: var->xres = 1024, yres = 768 vcj: var->xres_virtual = 1024, yres_virtual = 768 vcj: var->hsync_len = 136, vsync_len = 6 vcj: var->sync = 0x3 vcj: Inside if (mode_option) vcj: Inside if (fb_find_mode(xxx)) with fb_find_mode = 3 vcj: Inside if (1) vcj: Leaving radeon_check_modes radeonfb: Dynamic Clock Power Management enabled . . . Duhhh... Going back to the beginning, guess what I find... Kernel command line: auto BOOT_IMAGE=Test_9.2 ro root=306 pci=usepirqmask desktop idebus=66 video=radeonfb:[EMAIL PROTECTED] Note the "video=radeonfb:[EMAIL PROTECTED]" which used to be required to get the console into 1024x768 mode but is documented in "modefb.txt" as an invalid combination of mode specifications (and also states that radeonfb does not support mode specification...). So other than the loss of temporary working of backlight controls, I just see undocumented progress :-) Thanks again, and keep up the great work! -- 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 http://www.tux.org/lkml/
Re: [ACPI] Re: Call for help: list of machines with working S3
On Tuesday 15 Feb 2005 21:09, Lorenzo Colitti wrote: [snip] > I would advise trying to compile a custom kernel from scratch with my > .config first. > > I got S3 working first with a very basic kernel config, but I couldn't > get it to work with my usual kernel. Assuming it was some feature that > caused the problem, I started disabling features in the hope of getting > it to work, but I ended up with two different kernels with seemingly > irrelevant differences, of which one would succesfully resume and one > wouldn't. So I started added features to the other kernel, and I never > found out what caused the problem. I took your advice and built your kernel with a few modifications (XFS instead of ext, etc.). If I boot the kernel with init=/bin/sh, I can actually suspend! Thanks! I will exhaustively enable and disable drivers tomorrow to figure out which one is causing suspend to fail when I do a complete boot. Whatever we find is clearly a bug that should be fixed. It is not the framebuffer driver (I always ran without vesafb or radeonfb), and it is not my ipw2200 or USB drivers. Also, is USB suspend/resume supposed to work? My brief trials involved modprobing the USB HCD modules, which still allowed me to suspend/resume, but my USB mouse was non-functional on resume. -- Cheers, Alistair. personal: alistair()devzero!co!uk university: s0348365()sms!ed!ac!uk student:CS/CSim Undergraduate contact:1F2 55 South Clerk Street, Edinburgh. EH8 9PP. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] quiet non-x86 option ROM warnings
There is a new io resource flag as part of the pci rom code, IORESOURCE_ROM_SHADOW, that is used on x86. If IORESOURCE_ROM_SHADOW is set, you should ignore the physical ROM and use the copy at C000:0. Can we build an equivalent flag for PPC? On x86 arch specific code determines the boot video device and sets the flag. Acutally, if radeon and rage fb drivers were using the PCI ROM support (drivers/pci/rom.c) would they be having this problem? The 55AA check is in the PCI ROM support too. On Wed, 16 Feb 2005 12:00:31 +1100, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > I thought the signature described what type of ROM was there? E.g. 0xaa55 > > means x86 ROM, x0303 means OF ROM, etc.? > > > > At any rate, not having a ROM at all (which my case may be) isn't an error > > either, so I think removing the printk is appropriate regardless. > > Oh, and if this is the PowerBook, then you don't have a ROM attached to > the video chip, the OF driver is part of the main system ROM. > > Ben. > > -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] kernel 2.4 hotfixes : 2.4.29-hf2
Hi All, after a short discussion with Marcelo, we quickly agreed that a hotfix tree would be a good thing for kernel 2.4, since a few months can separate two stable releases. I offered to help in this area because I already have to pick random patches from the BK changesets anyway, so the only additional work will be to pack them in a more presentable way than what I can do just for me. Marcelo offered to help me by telling me when he thinks that a particular patch needs to be merged or excluded. Overall, the patches included are classified in 6 categories : - security : fixes for security bugs in general - critical : fixes for problems leading to panic, or data corruption - major: fixes for general system stability (oopses, memory leaks, ...) - minor: fixes for erroneous behaviours in general. - build: missing includes, Makefile bugs, etc... which prevents certain configurations from being built (here, we should often encounter Adrian Bunk's numerous patches :-)) - documentation : configure.help and friends. Will most probably be fed by Adrian's contributions too. As much as possible, I will avoid changes in drivers because we all know that in this area, a fix for one user breaks another one. Anyway, all of those patches will be extracted from -BK. I'm not building a parallel tree (I already have another one for that :-)). The main goal is that the diff between this kernel and the next release should be smaller than the diff between previous and next release. Marcelo and I agreed on the "-hf" suffix (for "Hot Fix"). Two patches are systematically provided, one with the version in the Makefile, and one without. The goal is to ease both people using vanilla kernels in production (who need to check the real version) and people who want a virgin kernel base to apply external patches while limiting the number of rejects. A tarball is also included with all the individual patches. A makefile relies on the "CONTENTS" file itself to rebuild the patch against the kernel of your choice. It is very easy to add/remove patches in the CONTENTS file, so I hope it will be convenient enough for people who don't want to include minor or documentation fixes for example. It is documented anyway. I've started with 2.4.29 and released 2.4.29-hf2 a few days ago. In fact, I was waiting for the site to migrate from home to my company (EXOSEC) to benefit from more outgoing bandwidth, before sending this announce. Despite this, I will try to stay up to date within the shortest time, and release a new hotfix as soon as either something weird gets fixed, or Marcelo asks me to do so. In any case, I'll do my best to send an announce here for new releases. The patches and tarballs are hosted here : http://linux.exosec.net/kernel/2.4-hf/ I'm open to comments, advices, critics, etc, but flames such as "you lose your time" or "2.4 is dead" will feed /dev/null. One possible improvement I have already identified would be to publish the work in progress so that people could get fixes in real time, but if they really need so, they should download from BK instead. If this branch gets enough demand, I will maintain several previous versions in parallel (eg: go back to 2.4.27). In the mean time, please find here the CONTENTS file which details what patches have been included and basically what they do. Enjoy, Willy -->8-- CONTENTS file : please remove it before replying. 1) Security fixes = + flash_erase-checks-cap_sys_admin-1 (James Nelson) This patch adds CAP_SYS_ADMIN checks to the potentially dangerous ioctls FLASH_Erase and FLASH_Burn in the Cobalt LCD interface driver. + rw_verify_area-against-file-offset-overflow-2(Linus Torvalds) backport 2.6 rw_verify_area() to check against file offset overflows - Make generic rw_verify_area check against file offset overflows. - Add 'f_maxcount' to allow filesystems to set a per-file maximum IO size. - Rename "locks_verify_area()" to "rw_verify_area()" and clean up the arguments. + rw_verify_area-missing-f_maxcount-1 (Solar Designer) + wireless-data-leak-1 (Chris Wright) There is a potential leak of kernel data to user space in private handler handling. Few drivers use that feature, there is no risk of crash or direct attack, so I would not worry about it. 2) Critical fixes = + panic-when-backing-up-lvm-snapshots-1 (Heinz J. Mauelshagen) This patch fixes lvm-snap.c in order to avoid a list update on the snapshot exception hash happening while only holding a read lock as documented in Red Hat bugzilla #135266. 3) Major bug fixes == + oops-ata_to_sense_error-1 (Jeff Garzik) Fix an oops in ata_to_sense_error + lcd_ioctl-memory-leak-1
2.6.10 : kernel BUG at mm/rmap.c:483!
Hi all, I'm running a kernel compiled from pristine 2.6.10 sources downloaded from kernel.org on a P4 with HT. I was originally working on an SMP/CONFIG_PREEMPT kernel when I first hit this problem. I downgraded to an SMP kernel without CONFIG_PREEMPT the problem remained. Same problem on a kernel compiled for a single CPU. The dmesg output below is for the single CPU, no CONFIG_PREEMPT case. The problem is triggered by a user space application which mmaps memory space on a custom PCI card via /dev/mem, reads some data and munmaps it. The program works perfectly on a 2.4.26 kernel. On 2.6.10 I get this on the console: [ cut here ] kernel BUG at mm/rmap.c:483! invalid operand: [#1] Modules linked in: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010286 (2.6.10) EIP is at page_remove_rmap+0x26/0x40 eax: ebx: 3000 ecx: b5e86000 edx: c160 esi: dabd9a24 edi: c160 ebp: 0017a000 esp: da40febc ds: 007b es: 007b ss: 0068 Process counters-erikd (pid: 1622, threadinfo=da40e000 task=da9d6a60) Stack: c0135a38 dfd0f878 0002 f277a8c0 3027 b5e86000 c049e480 b6286000 da43eb60 b600 c049e480 c0135b9b 0017a000 de16f030 dfc82000 b5e86000 da43eb60 b6286000 c049e480 c0135bfd 0040 Call Trace: [] zap_pte_range+0x138/0x250 [] zap_pmd_range+0x4b/0x70 [] unmap_page_range+0x3d/0x70 [] unmap_vmas+0xfe/0x1b0 [] unmap_region+0x6a/0xd0 [] do_munmap+0xf4/0x130 [] sys_munmap+0x40/0x70 [] syscall_call+0x7/0xb Code: 90 8d 74 26 00 89 c2 8b 00 f6 c4 08 75 27 83 42 08 ff 0f 98 c0 84 c0 74 11 8b 42 08 40 78 0c 9c 58 fa ff 0d 50 65 4a c0 50 9d c3 <0f> 0b e3 01 41 2c 38 c0 eb ea 0f 0b e0 01 41 2c 38 c0 eb cf 8d Is there anything I have missed? Does /dev/mem on a 2.6 kerel behave the same way as on a 2.4 kernel? I can supply more info if needed. Regards, Erik -- --- [N] Erik de Castro Lopo, Senior Computer Engineer [E] [EMAIL PROTECTED] [W] http://www.sensorynetworks.com [T] +61 2 83022726 [F] +61 2 94750316 [A] L6/140 William St, East Sydney NSW 2011, Australia --- A good debugger is no substitute for a good test suite. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] quiet non-x86 option ROM warnings
On Tue, 2005-02-15 at 15:57 -0800, Jesse Barnes wrote: > Both the r128 and radeon drivers complain if they don't find an x86 option > ROM > on the device they're talking to. This would be fine, except that the > message is incorrect--not all option ROMs are required to be x86 based. This > small patch just removes the messages altogether, causing the drivers to > *silently* fall back to the non-x86 option ROM behavior (it works fine and > there's no cause for alarm). What about printing "No PCI ROM detected" ? I like having that info when getting user reports, but I agree that a less worrying message would be good. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] quiet non-x86 option ROM warnings
> I thought the signature described what type of ROM was there? E.g. 0xaa55 > means x86 ROM, x0303 means OF ROM, etc.? > > At any rate, not having a ROM at all (which my case may be) isn't an error > either, so I think removing the printk is appropriate regardless. Oh, and if this is the PowerBook, then you don't have a ROM attached to the video chip, the OF driver is part of the main system ROM. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] quiet non-x86 option ROM warnings
On Tue, 2005-02-15 at 16:45 -0800, Jesse Barnes wrote: > On Tuesday, February 15, 2005 4:36 pm, Jon Smirl wrote: > > You're removing the check for 55AA at the start of the ROM. > > No, the check is still there, I just removed the printk if 0xaa55 isn't found > (my box returns 0x303 instead). > > > I though > > the PCI standard was that all ROMs had to start with the no matter > > what object code they contain. Then if you look for PCIR there is a > > field in the stucture that says what language the ROM is in. Maybe the > > problem is in the BIOS_IN16() function and things are getting byte > > swapped wrong. > > I thought the signature described what type of ROM was there? E.g. 0xaa55 > means x86 ROM, x0303 means OF ROM, etc.? > > At any rate, not having a ROM at all (which my case may be) isn't an error > either, so I think removing the printk is appropriate regardless. No, they all haev 0xaa55, then a header that says the type of ROM... Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] quiet non-x86 option ROM warnings
On Tuesday, February 15, 2005 4:36 pm, Jon Smirl wrote: > You're removing the check for 55AA at the start of the ROM. No, the check is still there, I just removed the printk if 0xaa55 isn't found (my box returns 0x303 instead). > I though > the PCI standard was that all ROMs had to start with the no matter > what object code they contain. Then if you look for PCIR there is a > field in the stucture that says what language the ROM is in. Maybe the > problem is in the BIOS_IN16() function and things are getting byte > swapped wrong. I thought the signature described what type of ROM was there? E.g. 0xaa55 means x86 ROM, x0303 means OF ROM, etc.? At any rate, not having a ROM at all (which my case may be) isn't an error either, so I think removing the printk is appropriate regardless. Thanks, Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device
On Tue, 2005-02-15 at 18:16, Kiniger wrote: > > > > what about catting out that device? I.E., > > > > 'cat /dev/cdxxx > some.iso' > > > > *instead* of using 'dd' (or variants) against it? I've always had good > > results using 'cat' and CDs, avoiding 'dd' and CDs whenever the > > opportunity presents itself. > > I dont think this is relevant. cat will probably use stdio which will > do blocking similar to dd (perhaps 4 kB). > But it *is* a quick try (rule out), though. Take 5 minutes if you can and try it. Easy to rule. If it fails, it fails. But *if* not, you don't waste any more time. I only mention it because it's worked for me in the past where dd (and variants) has (have) not. -fd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] quiet non-x86 option ROM warnings
You're removing the check for 55AA at the start of the ROM. I though the PCI standard was that all ROMs had to start with the no matter what object code they contain. Then if you look for PCIR there is a field in the stucture that says what language the ROM is in. Maybe the problem is in the BIOS_IN16() function and things are getting byte swapped wrong. void __iomem *pds; /* Standard PCI ROMs start out with these bytes 55 AA */ if (readb(image) != 0x55) break; if (readb(image + 1) != 0xAA) break; /* get the PCI data structure and check its signature */ pds = image + readw(image + 24); if (readb(pds) != 'P') break; if (readb(pds + 1) != 'C') break; if (readb(pds + 2) != 'I') break; if (readb(pds + 3) != 'R') break; last_image = readb(pds + 21) & 0x80; /* this length is reliable */ image += readw(pds + 16) * 512; On Tue, 15 Feb 2005 15:57:05 -0800, Jesse Barnes <[EMAIL PROTECTED]> wrote: > Both the r128 and radeon drivers complain if they don't find an x86 option ROM > on the device they're talking to. This would be fine, except that the > message is incorrect--not all option ROMs are required to be x86 based. This > small patch just removes the messages altogether, causing the drivers to > *silently* fall back to the non-x86 option ROM behavior (it works fine and > there's no cause for alarm). > > Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]> > > > -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add "bus" symlink to class/block devices
On Tue, Feb 15, 2005 at 05:25:54PM -0500, Dmitry Torokhov wrote:
> On Tue, 15 Feb 2005 23:04:06 +0100, Kay Sievers <[EMAIL PROTECTED]> wrote:
> >
> > -static int class_device_dev_link(struct class_device * class_dev)
> > -{
> > - if (class_dev->dev)
> > - return sysfs_create_link(&class_dev->kobj,
> > -&class_dev->dev->kobj, "device");
> > - return 0;
> > -}
> > -
> > -static void class_device_dev_unlink(struct class_device * class_dev)
> > -{
> > - sysfs_remove_link(&class_dev->kobj, "device");
> > -}
> > -
>
> Hi,
>
> I can agree on dropping driver link but I think that the link to
> underlying real device is still needed.
It's still there, read the patch :)
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Consolidate compat_sys_waitid
Stephen Rothwell writes: > This patch does: > - consolidate the three implementations of compat_sys_waitid > (some were called sys32_waitid). > - adds sys_waitid syscall to ppc > - adds sys_waitid and compat_sys_waitid syscalls to ppc64 Looks good to me. Are you going to submit it to Andrew? Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sigwait() and 2.6
On Tue, 15 Feb 2005 13:58:28 +0100, Yves Crespin <[EMAIL PROTECTED]> wrote: >ThreadUnblockSignal(); >signo = WaitSignal(); >ThreadBlockSignal(); You expect this to work? Just read the POSIX spec or even the man pages. All signals sigwait() waits for must be blocked before the call. You deliberately do the opposite. Swap the ThreadUnblockSignal and ThreadBlockSignal lines and suddenly the program doesn't crash anymore. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] quiet non-x86 option ROM warnings
Both the r128 and radeon drivers complain if they don't find an x86 option ROM
on the device they're talking to. This would be fine, except that the
message is incorrect--not all option ROMs are required to be x86 based. This
small patch just removes the messages altogether, causing the drivers to
*silently* fall back to the non-x86 option ROM behavior (it works fine and
there's no cause for alarm).
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
= drivers/video/aty/radeon_base.c 1.39 vs edited =
--- 1.39/drivers/video/aty/radeon_base.c 2005-02-10 22:57:44 -08:00
+++ edited/drivers/video/aty/radeon_base.c 2005-02-15 15:51:19 -08:00
@@ -329,11 +329,9 @@
rinfo->bios_seg = rom;
/* Very simple test to make sure it appeared */
- if (BIOS_IN16(0) != 0xaa55) {
- printk(KERN_ERR "radeonfb (%s): Invalid ROM signature %x should be"
- "0xaa55\n", pci_name(rinfo->pdev), BIOS_IN16(0));
- goto failed;
- }
+ if (BIOS_IN16(0) != 0xaa55)
+ goto failed; /* not an x86 option ROM, bail out */
+
/* Look for the PCI data to check the ROM type */
dptr = BIOS_IN16(0x18);
= drivers/video/aty/aty128fb.c 1.56 vs edited =
--- 1.56/drivers/video/aty/aty128fb.c 2005-02-10 22:57:44 -08:00
+++ edited/drivers/video/aty/aty128fb.c 2005-02-15 15:51:40 -08:00
@@ -812,11 +812,8 @@
}
/* Very simple test to make sure it appeared */
- if (BIOS_IN16(0) != 0xaa55) {
- printk(KERN_ERR "aty128fb: Invalid ROM signature %x should be 0xaa55\n",
- BIOS_IN16(0));
- goto failed;
- }
+ if (BIOS_IN16(0) != 0xaa55)
+ goto failed; /* not an x86 option ROM, bail out */
/* Look for the PCI data to check the ROM type */
dptr = BIOS_IN16(0x18);
Re: [PATCH] ext3: Fix sparse -Wbitwise warnings.
On Feb 15, 2005 15:29 -0800, Mitchell Blank Jr wrote: > Stephen C. Tweedie wrote: > > If we want to fix this, let's fix the macros: for example, convert > > EXT3_HAS_COMPAT_FEATURE to be > > > > ( le32_to_cpu(EXT3_SB(sb)->s_es->s_feature_compat) & (mask) ) > > Of course that's less efficient though since "mask" is probably constant.. > so now the endian conversion changed from compile-time to run-time. > > Would something like > > ( ( EXT3_SB(sb)->s_es->s_feature_compat & cpu_to_le32(mask) ) != 0) > > be enough to satisfy sparse? Or we could cast "mask" to the appropriate type (I'm not sure what sparse uses to determine this). Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/ pgphLeAEUOvy0.pgp Description: PGP signature
Re: [patch 10/13] Solaris nfsacl workaround
On Tue, Feb 15, 2005 at 06:37:19PM -0500, Trond Myklebust wrote: > on den 16.02.2005 Klokka 00:02 (+0100) skreiv Olivier Galibert: > > > Resolving the problem and/or cleaning the code, no. Telling what kind > > of patch would be acceptable is your responsability, yes. > > Read the patch, read the earlier patch [2/13] in which the same hack > appeared in the client code, and see my response. I'm sure Andreas knows > exactly what was meant by the comment and why. Ok. You have my apologies then. OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 10/13] Solaris nfsacl workaround
on den 16.02.2005 Klokka 00:02 (+0100) skreiv Olivier Galibert: > Resolving the problem and/or cleaning the code, no. Telling what kind > of patch would be acceptable is your responsability, yes. Read the patch, read the earlier patch [2/13] in which the same hack appeared in the client code, and see my response. I'm sure Andreas knows exactly what was meant by the comment and why. Trond -- Trond Myklebust <[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: 2.6.10 on PowerMac9,1 G5 Fan problem
On Tue, 2005-02-15 at 15:27 -0800, Ajay Patel wrote: > Hi, > > I have a single processor PowerMac G5 where > the model property is PowerMac9,1. > I do have therm_pm72 and I2C_keywest option > enabled in my config. Still fans are always on. > > Any thermal control driver patch available for this newer G5? Hi ! Not yet no. This one uses a new chip called the "SMU" that replace both the old PMU (power management) and the FCU (fan control unit). I don't know yet how to operate it to drive the fans, there is no open source darwin driver for it and no infos available from Apple :( Hopefully, I'll get an iMac G5 soon, which has a similar chip, so I'll be able to do some reverse engineering and eventually figure it out. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] drivers/media/video/tvaudio.c: make some variables static
This patch makes some needlessly global variables static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- tvaudio.c | 22 +++--- 1 files changed, 11 insertions(+), 11 deletions(-) --- linux-2.6.11-rc3-mm2-full/drivers/media/video/tvaudio.c.old 2005-02-15 22:13:38.0 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/media/video/tvaudio.c 2005-02-15 22:14:29.0 +0100 @@ -1237,17 +1237,17 @@ /* audio chip descriptions - struct CHIPDESC */ /* insmod options to enable/disable individual audio chips */ -int tda8425 = 1; -int tda9840 = 1; -int tda9850 = 1; -int tda9855 = 1; -int tda9873 = 1; -int tda9874a = 1; -int tea6300 = 0; // address clash with msp34xx -int tea6320 = 0; // address clash with msp34xx -int tea6420 = 1; -int pic16c54 = 1; -int ta8874z = 0; // address clash with tda9840 +static int tda8425 = 1; +static int tda9840 = 1; +static int tda9850 = 1; +static int tda9855 = 1; +static int tda9873 = 1; +static int tda9874a = 1; +static int tea6300 = 0; // address clash with msp34xx +static int tea6320 = 0; // address clash with msp34xx +static int tea6420 = 1; +static int pic16c54 = 1; +static int ta8874z = 0; // address clash with tda9840 module_param(tda8425, int, 0444); module_param(tda9840, int, 0444); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Kill some sparse warnings
On Tue, Feb 15, 2005 at 10:56:56PM +, Russell King wrote: > On Tue, Feb 15, 2005 at 11:45:53PM +0100, Peter Hagervall wrote: > > Cleaned up some address space issues in: > > This is wrong, and highlights a problem with the "remote" dma pool API. > dma_alloc_coherent() normally returns CPU-local memory, unless you've > declared remote memory, in which case it's __iomem-type memory. > > Therefore, I don't think we want to mark the return value of > dma_alloc_coherent with __iomem, because in the vast majority of > cases, it isn't. Doh! My bad, I changed the attribute for the return value to get it on par with the dma-mapping.h file, which as it turned out, was changed by myself some time ago. An aonther issue, what I'd like to see, is sort of a "don't care" attribute which could be used to mark some of the library functions, e.g. memset and family. AFAICS, many of them shouldn't need to care what address space they're handling, and at the same time we could get rid of a lot of the __force casts. Please correct me if this sounds completely wrong or otherwise insane. Any other comments welcome. -- Peter Hagervall <[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/
2.6.10 on PowerMac9,1 G5 Fan problem
Hi, I have a single processor PowerMac G5 where the model property is PowerMac9,1. I do have therm_pm72 and I2C_keywest option enabled in my config. Still fans are always on. Any thermal control driver patch available for this newer G5? Thanks in advance for your help. Aj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ext3: Fix sparse -Wbitwise warnings.
Hi, On Tue, 2005-02-15 at 23:29, Mitchell Blank Jr wrote: > Of course that's less efficient though since "mask" is probably constant.. > so now the endian conversion changed from compile-time to run-time. > > Would something like > > ( ( EXT3_SB(sb)->s_es->s_feature_compat & cpu_to_le32(mask) ) != 0) > > be enough to satisfy sparse? Yes, but it breaks other places: there are a few places where callers actually want the real return value from the "&", so that (for example) they can tell the user which feature failed the compatibility test. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device
On Tue, Feb 15, 2005 at 03:15:14PM -0500, [EMAIL PROTECTED] wrote: > On Tue, Feb 15, 2005 at 08:48:13PM +0100, Kiniger, Karl (GE Healthcare) wrote: > > I can confirm that. Creating a correct iso image from a CD is a > > major pain w/o ide-scsi. Depending on what one has done before the iso > > image is missing some data at the end most of the time. > > (paired with lots of kernel error messages) > > > > Testing was done here using Joerg Schilling's sdd: > > > > sdd ivsize=`isosize /dev/cdxxx` if=/dev/cdxxx of=/dev/null \ > > bs= > > > > and most of the time it results in bad iso images > > I have only ever used his readcd program for doing such things. It has > been so long I can't even remember if it was using ide-scsi or ide-cd. > > For burning I use ide-cd with cdrecord and growisofs, and so far it has > worked great. Flashing firmware on the plextor still requires ide-scsi > though. Burning has not been the problem here, just reading. At least `isosize /dev/cdxxx` bytes have to be readable and I am always burning with additional pad sectors at the end and even 32kb were not always enough to get all files contents.. Karl > > Lennart Sorensen -- Karl Kiniger mailto:[EMAIL PROTECTED] GE Medical Systems Kretztechnik GmbH & Co OHG Tiefenbach 15 Tel: (++43) 7682-3800-710 A-4871 Zipf Austria Fax: (++43) 7682-3800-47 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ext3: Fix sparse -Wbitwise warnings.
Stephen C. Tweedie wrote: > If we want to fix this, let's fix the macros: for example, convert > EXT3_HAS_COMPAT_FEATURE to be > > ( le32_to_cpu(EXT3_SB(sb)->s_es->s_feature_compat) & (mask) ) Of course that's less efficient though since "mask" is probably constant.. so now the endian conversion changed from compile-time to run-time. Would something like ( ( EXT3_SB(sb)->s_es->s_feature_compat & cpu_to_le32(mask) ) != 0) be enough to satisfy sparse? -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86_64 kernel support MAX memory.
Thanks. I will test 64G on node 4-7 only or 64G on node 0-3. YH > -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 15, 2005 2:55 PM > To: YhLu > Cc: linux-kernel@vger.kernel.org > Subject: Re: X86_64 kernel support MAX memory. > > On Tue, Feb 15, 2005 at 02:57:14PM -0800, YhLu wrote: > > It passed the memtest86+ 3.1a > > Are you sure it even tests the full 128GB? Traditionally PAE > only supports 64GB. > > > > > No oops dump, it just restart the system. > > At what point exactly? You probably have a serial console. > What are the last lines. > > That could well be an ECC error. You can see if mcelog logs > something after reboot (kernel should preserve machine check events) > > Or you could switch around the DIMMs of the CPUs for testing. > > -Andi > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device
On Tue, Feb 15, 2005 at 03:03:02PM -0500, kernel wrote: > On Tue, 2005-02-15 at 14:48, Kiniger, Karl (GE Healthcare) wrote: > > I can confirm that. Creating a correct iso image from a CD is a > > major pain w/o ide-scsi. Depending on what one has done before the iso > > image is missing some data at the end most of the time. > > (paired with lots of kernel error messages) > > > > Testing was done here using Joerg Schilling's sdd: > > > > sdd ivsize=`isosize /dev/cdxxx` if=/dev/cdxxx of=/dev/null \ > > bs= > > > > and most of the time it results in bad iso images > > Karl, > > what about catting out that device? I.E., > > 'cat /dev/cdxxx > some.iso' > > *instead* of using 'dd' (or variants) against it? I've always had good > results using 'cat' and CDs, avoiding 'dd' and CDs whenever the > opportunity presents itself. I dont think this is relevant. cat will probably use stdio which will do blocking similar to dd (perhaps 4 kB). Interestingly reading the files off the mounted CD works fine. Karl > > regards, > > > -fd > > -- Karl Kiniger mailto:[EMAIL PROTECTED] GE Medical Systems Kretztechnik GmbH & Co OHG Tiefenbach 15 Tel: (++43) 7682-3800-710 A-4871 Zipf Austria Fax: (++43) 7682-3800-47 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: two Oopses on 2.6.10
On Tuesday 15 February 2005 05:38 pm, Anthony DiSante wrote: > # ksymoops -K -o /lib/modules/2.6.10-1.9_FC2smp/ -m > /boot/System.map-2.6.10-1.9_FC2smp oops.01 >ksymoops.01 You seem to be using a Redhat/Fedora kernel and not a stock 2.6.10 - Two options - Either report this bug at https://bugzilla.redhat.com or reproduce it with a recent stock kernel like 2.6.11-rc4 and report it if you do reproduce it. Parag - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II
Thanks Andi for your effort to present your case more completely. I agree that there is some 'talking by each other' going on. Dave Hansen has publically (and Ray privately) sought to move this discussion to linux-mm (or more specifically, off lkml for now). Any chance, Andi, that you could repost this, in response to Ray's restarting this thread on linux-mm, once he gets around to that? I will reserve my response until I see if that works out. Thanks. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Message incompatible avec le système de messagerie
SVP stop. Cette message et SPAM! Pour local cet pas mal, pur l'internet cet SPAM. m'excuse mon francais terrible Ed Tomlinson On Monday 29 November 2004 11:23, Service de messagerie wrote: > Le message émis par linux-kernel@vger.kernel.org est incompatible avec le > système de messagerie, il a été supprimé. > > Certains éléments contenus dans ce message ayant pour objet :" Re: Your > details " sont susceptibles d'être dangereux pour le destinataire : [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/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 2.6.11-rc2-mm2 7/7] mm: manual page migration -- sys_page_migrate
Good explanation, Robin. Thanks. See y'all on linux-mm. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 10/13] Solaris nfsacl workaround
On Tue, Feb 15, 2005 at 05:43:24PM -0500, Trond Myklebust wrote: > ty den 15.02.2005 Klokka 21:35 (+0100) skreiv Olivier Galibert: > > That's the second time I see you refusing an interoperability patch > > without bothering to say what would be acceptable. Do we need a fork > > between knfsd-pure and knfsd-actually-works-in-the-real-world or what? > > You appear to be under the misguided impression that if a patch is > reviewed, and rejected, then somehow the responsibility for resolving > your problem (and cleaning up the code) falls to the reviewer. > > I'm not aware of any such rule. Resolving the problem and/or cleaning the code, no. Telling what kind of patch would be acceptable is your responsability, yes. That's where the difference is between a reviewer and a naysayer. OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Kill some sparse warnings
On Tue, Feb 15, 2005 at 11:45:53PM +0100, Peter Hagervall wrote: > Cleaned up some address space issues in: This is wrong, and highlights a problem with the "remote" dma pool API. dma_alloc_coherent() normally returns CPU-local memory, unless you've declared remote memory, in which case it's __iomem-type memory. Therefore, I don't think we want to mark the return value of dma_alloc_coherent with __iomem, because in the vast majority of cases, it isn't. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 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: X86_64 kernel support MAX memory.
On Tue, Feb 15, 2005 at 02:57:14PM -0800, YhLu wrote: > It passed the memtest86+ 3.1a Are you sure it even tests the full 128GB? Traditionally PAE only supports 64GB. > > No oops dump, it just restart the system. At what point exactly? You probably have a serial console. What are the last lines. That could well be an ECC error. You can see if mcelog logs something after reboot (kernel should preserve machine check events) Or you could switch around the DIMMs of the CPUs for testing. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [IPSEC] Move dst->child loop from dst_ifdown to xfrm_dst_ifdown
On Tue, 8 Feb 2005 12:31:40 +1100 Herbert Xu <[EMAIL PROTECTED]> wrote: > On Tue, Feb 08, 2005 at 12:29:29PM +1100, herbert wrote: > > > > This one moves the dst->child processing from dst_ifdown into > > xfrm_dst_ifdown. > > This patch adds a net_device argument to ifdown. After all, > it's a bit silly to notify someone of an ifdown event without > telling them what which device it was for :) > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Ok, I'm going to try and get these two patches into 2.6.11 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 2.6.11-rc2-mm2 7/7] mm: manual page migration -- sys_page_migrate
On Wed, Feb 16, 2005 at 08:58:19AM +1100, Peter Chubb wrote: > > "Robin" == Robin Holt <[EMAIL PROTECTED]> writes: > > Robin> On Tue, Feb 15, 2005 at 08:35:29AM -0800, Paul Jackson wrote: > >> What about the suggestion I had that you sort of skipped over, > >> which amounted to changing the system call from a node array to > >> just one node: > >> > >> sys_page_migrate(pid, va_start, va_end, count, old_nodes, > >> new_nodes); > >> > >> to: > >> > >> sys_page_migrate(pid, va_start, va_end, old_node, new_node); > >> > >> Doesn't that let you do all you need to? Is it insane too? > > Robin> Migration could be done in most cases and would only fall apart > Robin> when there are overlapping node lists and no nodes available as > Robin> temp space and we are not moving large chunks of data. > > A possibly stupid suggestion: > > Can page migration be done lazily, instead of all at once? Move the > process, mark its pages as candidates for migration, and when > the page faults, decide whether to copy across or not... > > That way you only copy the pages the process is using, and only copy > each page once. It makes copy for replication easier in some future > incarnation, too, because the same basic infrastructure can be used. I would agree that lazy might be possible, but then we need to keep track of the desired destination and can not rely upon first touch as that will likely result in scrambling the memory of the application. I have been very lax in describing how a typical MPI application works. This method has been in place for years and is commonly accepted practice. In the MPI model, a set of large mappings are done by the first process. It then forks x number of worker threads which touch their chunk of memory and rendezvous with the other workers. Once all workers have redezvoused, they are allowed to start their processing. A typical worker thread will reference their memory set 85-97% of the time and reference other memory sets in a read-only fashion the other part of the time. It is important to performance that the worker threads memory remains as close to its cpu as possible. Any time the memory is on a different node, the performance of that thread degrades (memory is further away) and performance of the other thread is hindered (its memory controller is more busy) and the read portions of the neighbor threads to both of the afor mentioned worker threads is hindered as there is more NUMA activity. Given all that, there is a common concept in MPI called a barrier where when worker threads complete a work set, they awaken threads waiting at the barrier associated with the work set. As a result of this wait, by slowing down a single thread you can have a cascade effect which slows down the entire application significantly as barriers are missed. Because of all this discussion, memory placement needs be thought of as relative to the worker threads and maintained relatively consistent before and after the migration. Another issue with making it a lazy migrate is the real impetus for this is to free up memory on a node so a job can be stopped on one node, migrated to a different node and thereby free up the original node for a second job which would not fit with the original job taking up a section of the machine which would cause the other job to perform too poorly. Sorry for the long rambling explanation. I guess I will try to break this into smaller chunks on the upcoming discussion on the linux-mm list. Thanks, Robin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Kill some sparse warnings
On Tue, 15 Feb 2005, Peter Hagervall wrote: > > Cleaned up some address space issues in: I'm holding off these for now, but you might check with Al Viro, since he's got a ton in store for a post-2.6.11 merge. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: X86_64 kernel support MAX memory.
It passed the memtest86+ 3.1a No oops dump, it just restart the system. YH > -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 15, 2005 2:42 PM > To: YhLu > Cc: linux-kernel@vger.kernel.org > Subject: Re: X86_64 kernel support MAX memory. > > On Tue, Feb 15, 2005 at 02:34:17PM -0800, YhLu wrote: > > If only use 64G RAM, it works well. > > Are you sure the RAM is not broken? The more you have of it > the more likely one DIMM is bad. > > Otherwise debug it. What's the oops dump? > > -Andi > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 10/13] Solaris nfsacl workaround
ty den 15.02.2005 Klokka 21:35 (+0100) skreiv Olivier Galibert: > That's the second time I see you refusing an interoperability patch > without bothering to say what would be acceptable. Do we need a fork > between knfsd-pure and knfsd-actually-works-in-the-real-world or what? You appear to be under the misguided impression that if a patch is reviewed, and rejected, then somehow the responsibility for resolving your problem (and cleaning up the code) falls to the reviewer. I'm not aware of any such rule. Feel free to apply as many hacks as you like to your own private fork, but the mainline kernel has to be maintained by a community of people most of which will not be aware, when debugging the ACL code, of the little special cases peppered around the RPC server code in an entirely different section of the kernel. In this particular case, there are 100s of solutions that do not involve putting NFSv3 ACL code in the generic RPC layer. If there really is a generic need for RPC programs to override the RFC-specified error that is returned to the client, then one obvious solution is to add a callback that allows them to do so. Even a flag called RPC_SVC_DO_NOT_EVER_RETURN_BAD_VERS would be easier to maintain. Trond -- Trond Myklebust <[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] Kill some sparse warnings
Cleaned up some address space issues in:
arch/i386(kernel/pci-dma.c
drivers/base/dmapool.c
fs/proc/base.c
include/asm-generic/pci-dma-compat.h
include/linux/dmapool.h
kernel/stop_machine.c
Signed-off-by: Peter Hagervall <[EMAIL PROTECTED]>
= arch/i386/kernel/pci-dma.c 1.19 vs edited =
--- 1.19/arch/i386/kernel/pci-dma.c 2005-02-12 02:33:28 +01:00
+++ edited/arch/i386/kernel/pci-dma.c 2005-02-15 18:24:02 +01:00
@@ -14,17 +14,17 @@
#include
struct dma_coherent_mem {
- void*virt_base;
+ void__iomem *virt_base;
u32 device_base;
int size;
int flags;
unsigned long *bitmap;
};
-void *dma_alloc_coherent(struct device *dev, size_t size,
+void __iomem *dma_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, int gfp)
{
- void *ret;
+ void __iomem *ret;
struct dma_coherent_mem *mem = dev ? dev->dma_mem : NULL;
int order = get_order(size);
/* ignore region specifiers */
@@ -36,7 +36,7 @@
if (page >= 0) {
*dma_handle = mem->device_base + (page << PAGE_SHIFT);
ret = mem->virt_base + (page << PAGE_SHIFT);
- memset(ret, 0, size);
+ memset((void __force *)ret, 0, size);
return ret;
}
if (mem->flags & DMA_MEMORY_EXCLUSIVE)
@@ -46,17 +46,17 @@
if (dev == NULL || (dev->coherent_dma_mask < 0x))
gfp |= GFP_DMA;
- ret = (void *)__get_free_pages(gfp, order);
+ ret = (void __iomem *)__get_free_pages(gfp, order);
if (ret != NULL) {
- memset(ret, 0, size);
- *dma_handle = virt_to_phys(ret);
+ memset((void __force *)ret, 0, size);
+ *dma_handle = virt_to_phys((volatile void __force *)ret);
}
return ret;
}
void dma_free_coherent(struct device *dev, size_t size,
-void *vaddr, dma_addr_t dma_handle)
+void __iomem *vaddr, dma_addr_t dma_handle)
{
struct dma_coherent_mem *mem = dev ? dev->dma_mem : NULL;
int order = get_order(size);
@@ -128,7 +128,7 @@
}
EXPORT_SYMBOL(dma_release_declared_memory);
-void *dma_mark_declared_memory_occupied(struct device *dev,
+void __iomem *dma_mark_declared_memory_occupied(struct device *dev,
dma_addr_t device_addr, size_t size)
{
struct dma_coherent_mem *mem = dev->dma_mem;
@@ -136,12 +136,12 @@
int pos, err;
if (!mem)
- return ERR_PTR(-EINVAL);
+ return (void __iomem *)ERR_PTR(-EINVAL);
pos = (device_addr - mem->device_base) >> PAGE_SHIFT;
err = bitmap_allocate_region(mem->bitmap, pos, get_order(pages));
if (err != 0)
- return ERR_PTR(err);
+ return (void __iomem *)ERR_PTR(err);
return mem->virt_base + (pos << PAGE_SHIFT);
}
EXPORT_SYMBOL(dma_mark_declared_memory_occupied);
= drivers/base/dmapool.c 1.22 vs edited =
--- 1.22/drivers/base/dmapool.c 2004-06-30 17:57:24 +02:00
+++ edited/drivers/base/dmapool.c 2005-02-15 23:13:07 +01:00
@@ -28,7 +28,7 @@
struct dma_page { /* cacheable header for 'allocation' bytes */
struct list_headpage_list;
- void*vaddr;
+ void __iomem*vaddr;
dma_addr_t dma;
unsignedin_use;
unsigned long bitmap [0];
@@ -175,7 +175,7 @@
if (page->vaddr) {
memset (page->bitmap, 0xff, mapsize); // bit set == free
#ifdef CONFIG_DEBUG_SLAB
- memset (page->vaddr, POOL_POISON_FREED, pool->allocation);
+ memset ((void __force *)page->vaddr, POOL_POISON_FREED,
pool->allocation);
#endif
list_add (&page->page_list, &pool->page_list);
page->in_use = 0;
@@ -204,7 +204,7 @@
dma_addr_t dma = page->dma;
#ifdef CONFIG_DEBUG_SLAB
- memset (page->vaddr, POOL_POISON_FREED, pool->allocation);
+ memset ((void __force *)page->vaddr, POOL_POISON_FREED,
pool->allocation);
#endif
dma_free_coherent (pool->dev, pool->allocation, page->vaddr, dma);
list_del (&page->page_list);
@@ -261,14 +261,14 @@
* and reports its dma address through the handle.
* If such a memory block can't be allocated, null is returned.
*/
-void *
+void __iomem *
dma_pool_alloc (struct dma_pool *pool, int mem_flags, dma_addr_t *handle)
{
unsigned long flags;
struct dma_page *page;
int map, block;
size_t offset;
- void*retval;
+ void __iomem*retval;
restart:
spin_lock_irqsave (&pool->lock, flags);
@@ -313,
Re: X86_64 kernel support MAX memory.
On Tue, Feb 15, 2005 at 02:34:17PM -0800, YhLu wrote: > If only use 64G RAM, it works well. Are you sure the RAM is not broken? The more you have of it the more likely one DIMM is bad. Otherwise debug it. What's the oops dump? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
two Oopses on 2.6.10
I've had two recent Oopses on two different 2.6.10 kernels on an SMP system. The system was being used "normally" -- a web browser, a few xterms and text-editors, and a VNC window running on it, in addition to some services (apache, ssh...). The only thing that sticks out is that this only happens when someone's physically in front of the box, using its kb/mouse/monitor. We have this system on a KVM, and we get the jumping mouse a few times a day, and sometimes X and/or the whole system locks up... at first I thought this might be a KVM problem, but with these kernel oops I'm not sure. The attached oops reports were created by copying the oops info from /var/log/messages into oops.01 and oops.02, then running: # ksymoops -K -o /lib/modules/2.6.10-1.9_FC2smp/ -m /boot/System.map-2.6.10-1.9_FC2smp oops.01 >ksymoops.01 # ksymoops -K -o /lib/modules/2.6.10-1.12_FC2smp/ -m /boot/System.map-2.6.10-1.12_FC2smp oops.02 >ksymoops.02 Please let me know if there's any other information I need to provide. -Anthony DiSante http://nodivisions.com/ ksymoops 2.4.5 on i686 2.6.10-1.12_FC2. Options used -V (default) -K (specified) -l /proc/modules (default) -o /lib/modules/2.6.10-1.9_FC2smp/ (specified) -m /boot/System.map-2.6.10-1.9_FC2smp (specified) No modules in ksyms, skipping objects No ksyms, skipping lsmod Jan 25 15:30:11 hostfoo kernel: eip: c0124efd Jan 25 15:30:11 hostfoo kernel: kernel BUG at include/asm/spinlock.h:146! Jan 25 15:30:11 hostfoo kernel: invalid operand: [#1] Jan 25 15:30:11 hostfoo kernel: CPU:0 Jan 25 15:30:11 hostfoo kernel: EIP:0060:[]Not tainted VLI Using defaults from ksymoops -t elf32-i386 -a i386 Jan 25 15:30:11 hostfoo kernel: EFLAGS: 00210006 (2.6.10-1.9_FC2smp) Jan 25 15:30:11 hostfoo kernel: eax: c0124efd ebx: 00200286 ecx: c02d4a00 edx: c02d4a00 Jan 25 15:30:11 hostfoo kernel: esi: c201fa00 edi: cc6bbfa0 ebp: f576be80 esp: cc6bbf18 Jan 25 15:30:11 hostfoo kernel: ds: 007b es: 007b ss: 0068 Jan 25 15:30:11 hostfoo kernel: Stack: cc6bbf38 c201fa60 c0124efd cc6bbf38 181712b7 c0124fe9 181712b7 c02bd6a3 Jan 25 15:30:11 hostfoo kernel:c2020028 c2020028 181712b7 0001 dead4ead 4b87ad6e c0125706 da7c1a40 Jan 25 15:30:11 hostfoo kernel:c201fa60 f576be80 002e cc6bbfa0 002e c016231d Jan 25 15:30:11 hostfoo kernel: [] del_timer+0x22/0x63 Jan 25 15:30:11 hostfoo kernel: [] del_singleshot_timer_sync+0x8/0x21 Jan 25 15:30:11 hostfoo kernel: [] schedule_timeout+0x9a/0xae Jan 25 15:30:11 hostfoo kernel: [] process_timeout+0x0/0x5 Jan 25 15:30:11 hostfoo kernel: [] do_poll+0x88/0xa6 Jan 25 15:30:11 hostfoo kernel: [] sys_poll+0x11b/0x1bd Jan 25 15:30:11 hostfoo kernel: [] __pollwait+0x0/0x95 Jan 25 15:30:11 hostfoo kernel: [] sys_gettimeofday+0x25/0x55 Jan 25 15:30:11 hostfoo kernel: [] syscall_call+0x7/0xb Jan 25 15:30:11 hostfoo kernel: Code: 81 00 00 00 00 01 c3 f0 ff 00 c3 56 89 c6 53 9c 5b fa 81 78 04 ad 4e ad de 74 18 ff 74 24 08 68 00 4a 2d c0 e8 c6 04 e6 ff 59 58 <0f> 0b 92 00 e0 39 2d c0 f0 fe 0e 79 13 f7 c3 00 02 00 00 74 01 >>EIP; c02bdc7d <_spin_lock_irqsave+20/45> <= >>eax; c0124efd >>ebx; 00200286 Before first symbol >>ecx; c02d4a00 <__func__.2+9dd7/2f1fb> >>edx; c02d4a00 <__func__.2+9dd7/2f1fb> >>esi; c201fa00 >>edi; cc6bbfa0 >>ebp; f576be80 >>esp; cc6bbf18 Code; c02bdc52 <_write_unlock+1/8> <_EIP>: Code; c02bdc52 <_write_unlock+1/8> 0: 81 00 00 00 00 01 addl $0x100,(%eax) Code; c02bdc58 <_write_unlock+7/8> 6: c3ret Code; c02bdc59 <_read_unlock+0/4> 7: f0 ff 00 lock incl (%eax) Code; c02bdc5c <_read_unlock+3/4> a: c3ret Code; c02bdc5d <_spin_lock_irqsave+0/45> b: 56push %esi Code; c02bdc5e <_spin_lock_irqsave+1/45> c: 89 c6 mov%eax,%esi Code; c02bdc60 <_spin_lock_irqsave+3/45> e: 53push %ebx Code; c02bdc61 <_spin_lock_irqsave+4/45> f: 9cpushf Code; c02bdc62 <_spin_lock_irqsave+5/45> 10: 5bpop%ebx Code; c02bdc63 <_spin_lock_irqsave+6/45> 11: facli Code; c02bdc64 <_spin_lock_irqsave+7/45> 12: 81 78 04 ad 4e ad de cmpl $0xdead4ead,0x4(%eax) Code; c02bdc6b <_spin_lock_irqsave+e/45> 19: 74 18 je 33 <_EIP+0x33> Code; c02bdc6d <_spin_lock_irqsave+10/45> 1b: ff 74 24 08 pushl 0x8(%esp) Code; c02bdc71 <_spin_lock_irqsave+14/45> 1f: 68 00 4a 2d c0push $0xc02d4a00 Code; c02bdc76 <_spin_lock_irqsave+19/45> 24: e8 c6 04 e6 ffcall ffe604ef <_EIP+0xffe604ef> Code; c02bdc7b <_spin_lock_irqsave+1e/45> 29: 59pop%ecx Code; c02bdc7c <_spin_lock_irqsave+1f/45> 2a: 58pop%eax Code; c0
Re: [ACPI] Call for help: list of machines with working S3
Matthew Garrett schrieb: > On Tue, 2005-02-15 at 19:57 +0100, Carl-Daniel Hailfinger wrote: > > >>Kendall Bennett is working with me to get suspend/resume working >>even with framebuffers. Once we have results, I'll post them here. > > > I've had success using vesafb with vbetool state restoration. vga16fb > ought to work fairly happily. Well, in my testing the machine deadlocked if any framebuffer was active during resume. It even deadlocked *before* I could run vbetool. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Thoughts on the "No Linux Security Modules framework" old claims
Hi, The purpose of this email is not re-opening the old flame on the anti-LSM "pleas" that were subject of many discussion and disappointments in certain developers and user groups. I will try to answer some of those in as much as possible organized manner, without any personal opinion being show in front of the objective analysis, and talking from the side of the developer who is looking at the advantages and shortcomings of different solutions to achieve almost the same thing (or at least, help when achieving it): [ http://www.rsbac.org/documentation/lsm.php ] -> 1. Incompleteness AFAIK, the LSM framework has evolved much more since it got accepted in the kernel mainline, many independent hackers contributed to it because they thought that it needed further improvement, but even if people could think in the beginning that it was going to be more a weakness than a real security enhancement, nowadays there are many available hooks, demonstrating how complete it can be, also, hooks can be added easily even if there's no (AFAIK, visible) documentation on it (a thing I'm planning to solve in the forthcoming months, maybe updating the current documentation at immunix.org), depending on how well the developer knows about how LSM framework works and how the kernel DAC and standard checks work themselves. The point is that people must have in mind that hooks need to work as they are supposed to do: no ABI/API breaking, no unexpected effects on "normal operation flow" of the kernel (if it's not explicitly wanted), no extra overhead or logics messing...etc. In addition, LKMs using the LSM framework *don't need* to use *only* a procfs sysctl interface or something alike for providing user-land<->kernel space communication capabilities. We have more options: registering a sysfs-based subsystem for example. During the research I was doing recently on the current hook'ing architecture, I wrote an useless patch to add a hook for sys_chmod(), just because I forgot that notify_change() calls an existing LSM hook, that can handle most file modes changing operation. I just mean that I'm working daily with them and I forgot *ALL* about it, so, it's not strange that many people could simply forget that LSM makes developers and the kernel itself being able of hooks re-using within similar or related syscalls that have in common some kernel objects or standard checks. In short, it's a complicated architecture that needs further research in order to make solid critics on it, same for RSBAC (which it's not known for me in terms of internal design and implementation, just having the idea from the available documentation). Both are good, but we must admit it, and we must admit that finally LSM got in mainline and now seems getting more solid and stable. -> 2. Access Control Only Yes, and that's noticed from the "official" documentation. But, who says that we can't place auditing facilities inside the existing hooks? or even file system linking related tweaks? Also, why disabling DAC? It's not a good idea if you have to handle *ALL* at *your OWN*. And it represents, BTW, a real performance hit because you do *double checking* or logics overhead. DAC checks normally *override* LSM checks, except in certain situations when both pre- and post-processing LSM hooks are used. An operation must at least be (if no override present): 1) DAC compliant, 2) LSM->user compliant. Going into personal thoughts, what's the point of having a *real pain* and maintenance overhead due to modifying the by-default permissions and access control basis with your own, even if they can live and have sex together? You can split up yours and maintain DAC alone and working with RSBAC when the user chooses explicitly to use the RSBAC-basis checking, as LSM does. -> 3. Low Level Internal Data Structures I agree that incorrect handling of the structures on-flow can lead to kernel stack or runtime corruption, but this is nonsense to be claimed as an LSM fault. I had freezes many times when I started doing some development with the LSM framework, but it was more because of my incompetency than the framework itself. When new kernel releases hit the streets, LSM framework is stable and compatible with it, as many people contributes and also the folks maintaining it are good and responsible ones. Common mistakes that lead to system take down are more pointer and structures wrong initialization, but again, those are related with the developer side. (It's the cost of doing "low level" sexy-thing development ;) ) -> 4. Stacking I agree with this, but AFAIK there has been work done in this area, as far it comes to mind, Serge Hallyn is someone to be asked about it. Stacking seems not fully support in a out-of-the-box working manner, nope, you need further work from your side to let other modules using the framework being subjects of redirection from your hooks. Anyways, we can even work together on the complete nifty-smooth-good smelling solution an
[2.4 TTY] Lost wake-up of tty->write_wait due to race?
Sorry for the repost! I forgot to attach my analysis so far ... In the 2.4 kernels, is there a race window when a wake_up() of the tty->write_wait queue from the underlying tty_driver can be lost in la-la-land, while a task is sleeping on it from tty_wait_until_sent() ? I am seeing something similar. I have the "pppd" daemon in the TASK_INTERRUPTIBLE state stuck in tty_wait_until_sent() [determined from wchan] as a result of its ioctl(fd, TIOCSETD, [N_TTY]) call while about to exit. The debug module is showing that the tty->write_wait queue is empty. As a result, *nothing* will wake up pppd from its TASK_INTERRUPTIBLE state. How could that be? Just to show that I've done my homework, attached is my analysis of the issue. I've seen references to race conditions in the changing of line-disciplines in postings by Alan Cox, but none of those references seems to explain what I am seeing. Any insight will be greatly appreciated! Thanks - Bhavesh Bhavesh P. Davda | Distinguished Member of Technical Staff | Avaya | 1300 West 120th Avenue | B3-B03 | Westminster, CO 80234 | U.S.A. | Voice/Fax: 303.538.4438 | [EMAIL PROTECTED] pppd: Calls ioctl(modemfd [/dev/usb/ttyACM0], TIOCSETD, (N_TTY)) In the kernel: tty_ioctl() calls tty_wait_until_sent(tty, 0) [ drivers/char/tty_io.c:1735 ] tty_wait_until_sent(tty, 0) checks tty->driver.chars_in_buffer func ptr. If true, Adds pppd to the tty->write_wait wait queue Calls tty->driver.chars_in_buffer(tty). If true, Translates to acm_tty_chars_in_buffer() Returns 0 if acm->writeurb.status != EINPROGRESS Returns -EINVAL if !ACM_READY() Returns acm->writeurb.transfer_buffer_length if acm->writeurb.status==EINPROGRESS Calls schedule_timeout(MAX_SCHEDULE_TIMEOUT) To wake up pppd from schedule_timeout(MAX_SCHEDULE_TIMEOUT), someone has to wake_up the tty->write_wait wait queue One candidate to do so is acm_softint() acm_softint() is called in bottom-half of acm_write_bulk() acm_write_bulk() is called as a completion routine for the write URB Most likely happens in interrupt context, as the outstanding UHCI TD is completed. That's why it queues a IMMEDIATE_BH task to do acm_softint() POTENTIALS FOR RACE CONDITION: Another task does a write() on /dev/usb/ttyACM0 Translates to acm_tty_write() acm->writeurb.tranfer_buffer_length = count passed in usb_submit_urb(&acm->writeurb) UHCI driver writes TD to USB controller If pppd does its ioctl(TIOCSETD) *after* usb_submit_urb() from other task, then its tty_wait_until_sent(tty, 0) routine will get a non-zero acm_tty_chars_in_buffer(). By that time, pppd has added itself to the tty->write_wait queue. So on completion of the TD/URB, acm_softint() *should* wake up pppd correctly What happens if the TD completion interrupt (and hence the call to acm_write_bulk()) comes in right before pppd calls schedule_timeout(MAX_SCHEULE_TIMEOUT) ? It queues an IMMEDIATE_BH task to do acm_softint(), which won't be executed until *after* the schedule_timeout() call from pppd (*I THINK*, due to the non-preemptible nature of the 2.4.20 kernel). acm_softint() *should* be executed by the ksoftirqd kernel thread, which runs *after* pppd has called schedule_timeout(). So the wake-up of tty->write_wait *should* wake up pppd correctly What can I do to see if pppd is still on the write_wait queue for the tty? Write a driver whose init routine will create a tty, and examine its write_wait queue.
[2.4 TTY] Lost wake-up of tty->write_wait due to race?
In the 2.4 kernels, is there a race window when a wake_up() of the tty->write_wait queue from the underlying tty_driver can be lost in la-la-land, while a task is sleeping on it from tty_wait_until_sent() ? I am seeing something similar. I have the "pppd" daemon in the TASK_INTERRUPTIBLE state stuck in tty_wait_until_sent() [determined from wchan] as a result of its ioctl(fd, TIOCSETD, [N_TTY]) call while about to exit. The debug module is showing that the tty->write_wait queue is empty. As a result, *nothing* will wake up pppd from its TASK_INTERRUPTIBLE state. How could that be? Just to show that I've done my homework, attached is my analysis of the issue. I've seen references to race conditions in the changing of line-disciplines in postings by Alan Cox, but none of those references seems to explain what I am seeing. Any insight will be greatly appreciated! Thanks - Bhavesh Bhavesh P. Davda | Distinguished Member of Technical Staff | Avaya | 1300 West 120th Avenue | B3-B03 | Westminster, CO 80234 | U.S.A. | Voice/Fax: 303.538.4438 | [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: [PATCH] add "bus" symlink to class/block devices
On Tue, 15 Feb 2005 23:04:06 +0100, Kay Sievers <[EMAIL PROTECTED]> wrote:
>
> -static int class_device_dev_link(struct class_device * class_dev)
> -{
> - if (class_dev->dev)
> - return sysfs_create_link(&class_dev->kobj,
> -&class_dev->dev->kobj, "device");
> - return 0;
> -}
> -
> -static void class_device_dev_unlink(struct class_device * class_dev)
> -{
> - sysfs_remove_link(&class_dev->kobj, "device");
> -}
> -
Hi,
I can agree on dropping driver link but I think that the link to
underlying real device is still needed.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: X86_64 kernel support MAX memory.
If only use 64G RAM, it works well. YH > -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 15, 2005 12:15 PM > To: YhLu > Cc: linux-kernel@vger.kernel.org > Subject: Re: X86_64 kernel support MAX memory. > > On Tue, Feb 15, 2005 at 10:49:05AM -0800, YhLu wrote: > > I got a system with 8 way Opteron. Every CPU has 16G memory. > > > > 2.6 kernel x86_64, it will crash when it start the Fifth node. > > The kernel has been successfully booted on 8 CPU Opteron > systems before. > Most likely it is something specific to your system. > > -Andi > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pty is losing bytes
On Maw, 2005-02-15 at 19:44, Linus Torvalds wrote: > However, then when I start looking at n_tty_receive_room() and > n_tty_receive_buf(), my stomach gets a bit queasy. I have this horrid > feeling that I had something to do with the mess, but I'm going to lash You did. Then Ted tided it up Then Bill added hacks to "fix" up the locking The real fix is shooting the flip buffers, at that point a lot of the locking goes away (because the tty owns everything relevant). I just don't have time to do major kernel hacking and finish the MBA thesis at the same time. Sorry yes I know how n_tty works, and no I'm not going to fix it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 2.6.11-rc2-mm2 7/7] mm: manual page migration -- sys_page_migrate
Dr Peter Chubb writes: > Can page migration be done lazily, instead of all at once? That might be a useful option. Not my area to comment on. We would also require, at least as an option, to be able to force the migration on demand. Some of our big honkin iron parallel jobs run with a high degree of parallelism, and nearly saturate each node being used. For jobs like that, it can be better to get everything in place, before resuming execution. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device
On Maw, 2005-02-15 at 17:48, David GÃmez wrote: > Is going to be merged soon to the mainline 2.6 kernel? I guess this > bad error handling from ide-cd has something to do with recent messages > about kernel hanging with bad dvd media. Up to the maintainer. I've been very busy on thesis stuff but I'll try and split it out for 2.6.12pre if Bartlomiej wants the changes. As to the DVD media hang - I think that is unrelated. The ide-cd fixes deal with end of media error handling primarily and better reporting of sense data. That affects multisession discs, readahead and some other oddments rather than any hang cases Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] add "bus" symlink to class/block devices
On Tue, Feb 15, 2005 at 09:53:44PM +0100, Kay Sievers wrote:
> Add a "bus" symlink to the class and block devices, just like the "driver"
> and "device" links. This may be a huge speed gain for e.g. udev to determine
> the bus value of a device, as we currently need to do a brute-force scan in
> /sys/bus/* to find this value.
Hmm, while playing around with it, I think we should create the "bus"
link on the physical device on not on the class device.
Also the current "driver" link at the class device should be removed,
cause class devices don't have a driver. Block devices never had this
misleading symlink.
>From the class device we point with the "device" link to the physical
device, and only the physical device should have the "driver" and the
"bus" link, as it represents the real relationship.
Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
+++ edited/drivers/base/bus.c 2005-02-15 22:33:37 +01:00
@@ -465,6 +465,7 @@ int bus_add_device(struct device * dev)
up_write(&dev->bus->subsys.rwsem);
device_add_attrs(bus, dev);
sysfs_create_link(&bus->devices.kobj, &dev->kobj, dev->bus_id);
+ sysfs_create_link(&dev->kobj, &dev->bus->subsys.kset.kobj,
"bus");
}
return error;
}
@@ -481,6 +482,7 @@ int bus_add_device(struct device * dev)
void bus_remove_device(struct device * dev)
{
if (dev->bus) {
+ sysfs_remove_link(&dev->kobj, "bus");
sysfs_remove_link(&dev->bus->devices.kobj, dev->bus_id);
device_remove_attrs(dev->bus, dev);
down_write(&dev->bus->subsys.rwsem);
= drivers/base/class.c 1.58 vs edited =
--- 1.58/drivers/base/class.c 2005-02-05 19:35:12 +01:00
+++ edited/drivers/base/class.c 2005-02-15 22:32:08 +01:00
@@ -196,33 +196,6 @@ void class_device_remove_bin_file(struct
sysfs_remove_bin_file(&class_dev->kobj, attr);
}
-static int class_device_dev_link(struct class_device * class_dev)
-{
- if (class_dev->dev)
- return sysfs_create_link(&class_dev->kobj,
-&class_dev->dev->kobj, "device");
- return 0;
-}
-
-static void class_device_dev_unlink(struct class_device * class_dev)
-{
- sysfs_remove_link(&class_dev->kobj, "device");
-}
-
-static int class_device_driver_link(struct class_device * class_dev)
-{
- if ((class_dev->dev) && (class_dev->dev->driver))
- return sysfs_create_link(&class_dev->kobj,
-&class_dev->dev->driver->kobj,
"driver");
- return 0;
-}
-
-static void class_device_driver_unlink(struct class_device * class_dev)
-{
- sysfs_remove_link(&class_dev->kobj, "driver");
-}
-
-
static ssize_t
class_device_attr_show(struct kobject * kobj, struct attribute * attr,
char * buf)
@@ -452,8 +425,9 @@ int class_device_add(struct class_device
class_device_create_file(class_dev, &class_device_attr_dev);
class_device_add_attrs(class_dev);
- class_device_dev_link(class_dev);
- class_device_driver_link(class_dev);
+ if (class_dev->dev)
+ sysfs_create_link(&class_dev->kobj,
+ &class_dev->dev->kobj, "device");
register_done:
if (error && parent)
@@ -482,8 +456,8 @@ void class_device_del(struct class_devic
up_write(&parent->subsys.rwsem);
}
- class_device_dev_unlink(class_dev);
- class_device_driver_unlink(class_dev);
+ if (class_dev->dev)
+ sysfs_remove_link(&class_dev->kobj, "device");
class_device_remove_attrs(class_dev);
kobject_del(&class_dev->kobj);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon FB troubles with recent kernels
On Tue, 2005-02-15 at 10:07 -0500, Vincent C Jones wrote: > .../... > > radeonfb: panel ID string: 1024x768 > radeonfb: detected LVDS panel size from BIOS: 1024x768 > BIOS provided panel power delay: 1000 > radeondb: BIOS provided dividers will be used > ref_divider = 8 > post_divider = 2 > fbk_divider = 4d > Scanning BIOS table ... > 320 x 350 > 320 x 400 > 320 x 400 > 320 x 480 > 400 x 600 > 512 x 384 > 640 x 350 > 640 x 400 > 640 x 475 > 640 x 480 > 720 x 480 > 720 x 576 > 800 x 600 > 848 x 480 > 1024 x 768 > Found panel in BIOS table: > hblank: 320 > hOver_plus: 16 > hSync_width: 136 > vblank: 38 > vOver_plus: 2 > vSync_width: 6 > clock: 6500 > Setting up default mode based on panel info So far, things look good. At this point, the driver should have obtained the 1024x768 mode that matches your panel... Can you look at radeon_monitor.c, function radeon_check_modes(). This function calls radeon_get_panel_info_BIOS() which is the above. Then, it gets into the if () block that follow that comment: /* * If we have some valid panel infos, we setup the default mode based on * those */ Could you add some more printk's in there to see what's going on ? It should setup a 1024x768 mode at this point... Also, it should not get into any of the other if () statements of this function, except the last bit, in if (1) which adds the panel mode to the list for the driver. Can you check that happens ? (Especially, check that mode_option is NULL and thus the driver isn't trying to override the panel mode from the command line arguments). If all of that looks good, then maybe look at what's going on in the function radeon_match_mode()... Maybe it's not matching the mode properly. > radeonfb: Dynamic Clock Power Management enabled > hStart = 656, hEnd = 792, hTotal = 960 > vStart = 402, vEnd = 408, vTotal = 438 > h_total_disp = 0x4f0077 hsync_strt_wid = 0x11028a > v_total_disp = 0x18f01b5 vsync_strt_wid = 0x60191 > pixclock = 15384 > freq = 6500 > Console: switching to colour frame buffer device 53x18 > radeonfb (:01:00.0): ATI Radeon LY > radeonfb_pci_register END > ACPI: AC Adapter [AC] (off-line) > ACPI: Battery Slot [BAT0] (battery present) > ACPI: Power Button (FF) [PWRF] > ACPI: Lid Switch [LID] > ACPI: Sleep Button (CM) [SLPB] > ACPI: Video Device [VID] (multi-head: yes rom: no post: no) > ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3] C4[C3]) > ACPI: Processor [CPU] (supports 8 throttling states) > ACPI: Thermal Zone [THM0] (51 C) > ibm_acpi: IBM ThinkPad ACPI Extras v0.8 > ibm_acpi: http://ibm-acpi.sf.net/ > ibm_acpi: dock device not present > ibm_acpi: bay device not present > Real Time Clock Driver v1.12 > Non-volatile memory driver v1.2 > i8xx TCO timer: initialized (0x1060). heartbeat=30 sec (nowayout=0) > Linux agpgart interface v0.100 (c) Dave Jones > agpgart: Detected an Intel 855PM Chipset. > agpgart: Maximum main memory to use for agp memory: 690M > agpgart: AGP aperture is 256M @ 0xd000 > [drm] Initialized drm 1.0.0 20040925 > ACPI: PCI interrupt :01:00.0[A] -> GSI 11 (level, low) -> IRQ 11 > [drm] Initialized radeon 1.14.0 20050125 on minor 0: > ACPI: PS/2 Keyboard Controller [KBD] at I/O 0x60, 0x64, irq 1 > ACPI: PS/2 Mouse Controller [MOU] at irq 12 > serio: i8042 AUX port at 0x60,0x64 irq 12 > serio: i8042 KBD port at 0x60,0x64 irq 1 > io scheduler noop registered > io scheduler deadline registered > io scheduler cfq registered > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 66MHz system bus speed for PIO modes > ICH4: IDE controller at PCI slot :00:1f.1 > PCI: Enabling device :00:1f.1 (0005 -> 0007) > ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 > ACPI: PCI interrupt :00:1f.1[A] -> GSI 11 (level, low) -> IRQ 11 > ICH4: chipset revision 1 > ICH4: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:pio, hdd:pio > Probing IDE interface ide0... > hda: HTS726060M9AT00, ATA DISK drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > Probing IDE interface ide1... > hda: max request size: 1024KiB > hda: 117210240 sectors (60011 MB) w/7877KiB Cache, CHS=16383/255/63, UDMA(100) > hda: cache flushes supported > hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 > hda4 > mice: PS/2 mouse device common for all mice > input: AT Translated Set 2 keyboard on isa0060/serio0 > input: PS/2 Generic Mouse on isa0060/serio1 > input: PC Speaker > i2c /dev entries driver > i2c-core: driver dev_driver registered. > i2c_adapter i2c-0: Registered as minor 0 > i2c_adapter i2c-1: Registered as minor 1 > i2c_adapter i2c-2: Registered as minor 2 > i2c_adapter i2c-3: Registered as minor 3 > i801_smbus :00:1f.3: I801 using PCI Interrupt for SMBus. > i801_smbus :00:1f.3: SMBREV = 0x1 > i801_smbus :00:1f.3: I801_smba = 0x1880 > i2c_adapter i2c-4: Registere
Re: Pty is losing bytes
Linus Torvalds <[EMAIL PROTECTED]> writes: > That's clearly not the case, and I haven't looked into exactly what > termios settings "forkpty()" uses If no termios is passed then the defaults are unchanged. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II
> Making memory migration a subset of page migration is not a general > solution. It only works for programs that are using memory policy > to control placement. As I've tried to point out multiple times > before, most programs that I am aware of use placement based on > first-touch. When we migrate such programs, we have to respect > the placement decisions that the program has implicitly made in > this way. Sorry, but the only real difference between your API and mbind is that yours has a pid argument. I think we are talking by each other, here's a more structured overview of my thinking on the issue. Main cases: - Program is NUMA API aware. Fine. It takes care of its own. - Program is not aware, but is started with a process policy from numactl/cpusets/batch scheduler. Already covered too in NUMA API. - Program is not aware and hasn't been started with a policy (or has and you change your mind) but you want to change it later. That's the new case we discuss here. Now how to change policy of objects in an already running process. First there are already some special cases already handled or with existing patches: - tmpfs/hugetlbfs/sysv shm: numactl can handle this by just mapping the object into a different process and changing the policy there. - shared libraries and mmaped files in general: this is a generialization of the previous point. SteveL's patch is the beginning of handling this, although it needs some more work (xattrs) to make the policy persistent over memory pressure. Only case not covered left is anonymous memory. You said it would need user space control, but the main reason for wanting that seems to be to handle the non anonymous cases which are already covered above. My thinking is the simplest way to handle that is to have a call that just o migrates everything. The main reasons for that is that I don't think external processes should mess with virtual addresses of another process. It just feels unclean and has many drawbacks (parsing /proc/*/maps needs complicated user code, racy, locking difficult). In kernel space handling full VMs is much easier and safer due to better locking facilities. In user space only the process itself really can handle its own virtual addresses well, and if it does that it can use NUMA API directly anyways. You argued that it may be costly to walk everything, but I don't see this as a big problem - first walking mempolicies is not very costly and then fork() and exit() do exactly this already. The main missing piece for this would be a way to make policies for files persistent. One way would be to use xattrs like selinux, but that may be costly (not sure we want to read xattrs all the time when reading a file). A hackish way to do this that already works would be to do a mlock on one page of the file to keep the inode pinned. E.g. the batch manager could do this. That's not very clean, but would probably work. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NO-PATCH] compile error: 2.6.10 / megaraid_mbox
Hello Again! Sorry Greg for the wrong information. The kernel I modified had been patched with some megaraid patches before. I wasn't told that it was patched. I retested it with 2.6.10 and it works fine! So keep on good work, Nico - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] hotplug-ng 001 release
Diego Calleja wrote: Of course there're lots of problems, like what happens if you change a file which was being used by a suspended process, That one is easy. Store a checksum of the file in use when you go to sleep If on wakeup the checksum is different, pop up a window that says "the file *foo* has been modified by another application, do you want to reload?". > what happens if you update a library that a image is supposed to use Same as updating it on a running system. Don't do that unless you really know what you're doing. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Hi, On Mon, 2005-02-14 at 22:11 +0100, Pavel Machek wrote: > Stefan provided me initial list of machines where S3 works (including > video). If you have machine that is not on the list, please send me a > diff. If you have eMachines... I'd like you to try playing with > vbetool (it worked for me), and if it works for you supplying right > model numbers. I have S3 working with 2.6.11-rc4 here: Model hack (or "how to do it") -- IBM TP X31 / Type 2672-XXH LCD backlight must be turned off manually using radeontool [1] Sincerely, Brix [1]: http://fdd.com/software/radeon/ -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: Optimizing disk-I/O [was Re: [ANNOUNCE] hotplug-ng 001 release]
El Tue, 15 Feb 2005 15:46:56 -0500, Adam Goode <[EMAIL PROTECTED]> escribió: > Mac OS X has a similar thing, with a pretty simple description of how > they do it: > > http://developer.apple.com/technotes/tn/tn1150.html#HotFile Also all those things are part of darwin i think (or IOW, we can look at how they did it) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device
On Tue, 15 Feb 2005 20:48:13 +0100, "Kiniger, Karl (GE Healthcare)" said: > I can confirm that. Creating a correct iso image from a CD is a > major pain w/o ide-scsi. Depending on what one has done before the iso > image is missing some data at the end most of the time. > (paired with lots of kernel error messages) > > Testing was done here using Joerg Schilling's sdd: > > sdd ivsize=`isosize /dev/cdxxx` if=/dev/cdxxx of=/dev/null \ > bs= > > and most of the time it results in bad iso images Have you tested the ISO on some *OTHER* hardware? The impression I got was that the cd was *burned* right by ide-cd, but when *read back*, it bollixed things up at the end of the CD. pgpA5EgUHI7iy.pgp Description: PGP signature
Re: Optimizing disk-I/O [was Re: [ANNOUNCE] hotplug-ng 001 release]
On Tue, 15 Feb 2005 13:56:14 CST, Linas Vepstas said: > Now I like this idea. It need not have anything to do with startup, > or with any particular program or distro whatsoever. Rather, one > would have a daemon keeping track of disk i/o patterns, and constantly > trying to figure out if there is a rearrangement of the sectors on disk > that would minimize i/o seeks based on past uasge. More prior art - a company called FDR made a disk compactor product for IBM's OS series, and I seem to remember a SHARE (IBM mainframe user group) tape that had a program to read the I/O trace table and generate an optimal "what goes where" command stream for FDR's software. Again a late 70s to early 80s thing. (Probably not enough to be "prior art" by itself, but certainly goes towards the "obviousness to a practitioner in the field" criteria - if *I* knew about it as a junior sysadmin at a college in middle-of-nowhere upstate NY knew about it in 1983.. ;) pgpMVGAygnHjV.pgp Description: PGP signature
Re: [ANNOUNCE] hotplug-ng 001 release
El Tue, 15 Feb 2005 14:51:06 -0500, Lee Revell <[EMAIL PROTECTED]> escribió: > Of course resuming from suspend will always be faster than booting but > for the forseeable future we will have to reboot from time to time. And > XP's boot time currently is way, way better than ours. FWIW, OSX still > takes forever to boot so we are not the only ones with this problem. What I wonder is if we can have a "process-to-disk" thing and use it to improve other things. Some OSs implement this (DFbsd, for one), but I think we could use it to do some cool things, ie: instead of closing gnome and restarting all the apps when you login again, you could do something like "when you're closing gnome, dump all the process' images to disk and restart all the process when you login again". This way your desktop would be *always* in the same state you left it (including things like the text buffer in your terminal). You could use it to speed up some things ej: instead of loading openoffice, load a saved image of a void document. Of course there're lots of problems, like what happens if you change a file which was being used by a suspended process, disconnection between app <-> xserver (x folks are working on thinks like that because of wireless connections i think) , what happens if you update a library that a image is supposed to use, can users "restart" images or just only root, etc but i think it'd be interesting to discuss if it's feasible (in the X world there's already some "signal" sent to programs, but if we were able to do it by "sending a process' image to disk" it'd be much easier and cleaner IMHO) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.9 IO-APIC + timer doesn't work! with VMWare 4
Thank you Lee, I haven't contacted them, but will do so now upon your suggestion. I did look through their support forums but did not find what I was looking for. Joseph From: Lee Revell <[EMAIL PROTECTED]> To: Joseph Cosby <[EMAIL PROTECTED]> CC: linux-kernel@vger.kernel.org Subject: Re: 2.6.9 IO-APIC + timer doesn't work! with VMWare 4 Date: Tue, 15 Feb 2005 15:58:59 -0500 On Tue, 2005-02-15 at 13:29 -0700, Joseph Cosby wrote: > Hi, > Using VMWare 4 with a 2.6.9 kernel I get "IO-APIC + timer doesn't work!" > As suggested, the noapic option fixes the problem. This resulted after > adding APIC support to my kernel. My problem is, I need APIC support to boot > on a separate, non-VMWare machine, and I need to keep the kernel and boot > params the same on both machines. > Aside from disabling APIC support, and running with the noapic parameter, > can anybody suggest how to get this running on the VMware machine? Did you ask VMWare about it? Lee _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] hotplug-ng 001 release
On Tue, 15 Feb 2005 14:51:06 EST, Lee Revell said: > I wonder if XP's solution is patented. If it is, IBM's OS/360 and OS/VS1 and MVS had prior art way back in the 70's. There were *plenty* of products that would look at the system call usage and spit out an ordered load list for SYS1.LINKLIB and SYS1.LPALIB - so the idea of machine-optimizing the list of things to cache for a fast startup is *not* new. I'd not be surprised to find out that somebody did something like that on the 7094 ;) pgpCSRl8tAwmh.pgp Description: PGP signature
Re: [ACPI] Re: Call for help: list of machines with working S3
Matthew Garrett wrote: Vendor: Hewlett-Packard - Version: 68BDD Ver. F.0F - Release Date: 07/23/2004 + Version: 68BDD Ver. F.11 + Release Date: 11/22/2004 Ok, so you both have different BIOS versions and different CPUs. S3 works for me with both BIOS F.0F, which I was using before, and F.11, which I flashed today after learning it existed. Everything else looks pretty identical. Could you both stick /proc/acpi/dsdt up somewhere so I can check if there are any relevant looking differences? I would advise trying to compile a custom kernel from scratch with my .config first. I got S3 working first with a very basic kernel config, but I couldn't get it to work with my usual kernel. Assuming it was some feature that caused the problem, I started disabling features in the hope of getting it to work, but I ended up with two different kernels with seemingly irrelevant differences, of which one would succesfully resume and one wouldn't. So I started added features to the other kernel, and I never found out what caused the problem. I'm not saying that this is not deterministic, but I am saying that, at least in my case, it's not obvious what it is that stops S3 from working. :-) Cheers, Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.9 IO-APIC + timer doesn't work! with VMWare 4
On Tue, 2005-02-15 at 13:29 -0700, Joseph Cosby wrote: > Hi, > Using VMWare 4 with a 2.6.9 kernel I get "IO-APIC + timer doesn't work!" > As suggested, the noapic option fixes the problem. This resulted after > adding APIC support to my kernel. My problem is, I need APIC support to boot > on a separate, non-VMWare machine, and I need to keep the kernel and boot > params the same on both machines. > Aside from disabling APIC support, and running with the noapic parameter, > can anybody suggest how to get this running on the VMware machine? Did you ask VMWare about it? Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pty is losing bytes
On Tue, 15 Feb 2005, Andreas Schwab wrote: > > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > I think it may be a n_tty line discipline bug, brought on by the fact that > > the PTY buffering is now 4kB rather than 2kB. 4kB is also the > > N_TTY_BUF_SIZE, and if n_tty has some off-by-one error, that would explain > > it. > > I've also seen more than one byte missing. For example when sending a big > chunk of bytes down the pty via an Emacs *shell* buffer up to 16 bytes are > missing somewhere in the middle. If it's NTTY (and I'm pretty certain it is - the generic tty code looks fine, the pty code itself is too simple for words), then I'd actually have expected more variability than a simple off-by-one. I'd have expected the problems to be due to character expansion, ie the CR->LF thing etc, and that would have resulted in off-by-N, where N is the number of expanded characters in a 4096 byte block. With XTAB, you could even have each \t be expanded to 8 space characters on ECHO, and you could lose a whole lot more than just one byte at the end. That's clearly not the case, and I haven't looked into exactly what termios settings "forkpty()" uses, so I suspect that it's something else than pure expansion on write. There's a lot of things going on in a tty driver: the character flow itself, the "backflow" in the form of ECHO, etc etc. Also, there's the interaction with "flushing" the buffer: we do a "flush_chars()" at regular intervals, and that will flush it to the next buffer, which may actually cause things to fit a lot better than they would otherwise have fit. In fact, I'd not be at all surprised if this thing was timing-dependent too, ie depended on how quickly the reader emptied the other side buffer. The tty layer is pretty ugly, but in its defense, it has to be said that tty handling _is_ one of the more complex parts of traditional UNIX, so the ugliness is at least partly due to the problem space, not just the fact that the code is old. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2.6.11-rc2-mm2 7/7] mm: manual page migration -- sys_page_migrate
In the interest of the size of everyone's inboxes, I mentioned to Ray that we might move this discussion to a smaller forum while we resolve some of the outstanding issues. Ray's going to post a followup to to linux-mm, and trim the cc list down. So, if you're still interested, keep your eyes on linux-mm and we'll continue there. -- 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/
[PATCH ] add "bus" symlink to class/block devices
Add a "bus" symlink to the class and block devices, just like the "driver"
and "device" links. This may be a huge speed gain for e.g. udev to determine
the bus value of a device, as we currently need to do a brute-force scan in
/sys/bus/* to find this value.
/sys
|-- block
| |-- fd0
| | |-- bus -> ../../bus/platform
| | |-- dev
| | |-- device -> ../../devices/platform/floppy0
| | |-- queue
| | | |-- iosched
|-- class
| |-- net
| | |-- eth0
| | | |-- addr_len
| | | |-- address
| | | |-- broadcast
| | | |-- bus -> ../../../bus/pci
| | | |-- carrier
...
| | |-- ttyS0
| | | |-- bus -> ../../../bus/pnp
| | | |-- dev
| | | |-- device -> ../../../devices/pnp0/00:09
| | | `-- driver -> ../../../bus/pnp/drivers/serial
...
| |-- sound
| | |-- controlC0
| | | |-- bus -> ../../../bus/pci
| | | |-- dev
| | | |-- device -> ../../../devices/pci:00/:00:1f.5
| | | `-- driver -> ../../../bus/pci/drivers/Intel ICH
Signed-off-by: Kay Sievers <[EMAIL PROTECTED]>
= drivers/base/class.c 1.58 vs edited =
--- 1.58/drivers/base/class.c 2005-02-05 19:35:12 +01:00
+++ edited/drivers/base/class.c 2005-02-15 21:31:06 +01:00
@@ -196,33 +196,33 @@ void class_device_remove_bin_file(struct
sysfs_remove_bin_file(&class_dev->kobj, attr);
}
-static int class_device_dev_link(struct class_device * class_dev)
+static void class_device_add_dev_symlinks(struct class_device *class_dev)
{
- if (class_dev->dev)
- return sysfs_create_link(&class_dev->kobj,
-&class_dev->dev->kobj, "device");
- return 0;
-}
+ if (!class_dev->dev)
+ return 0;
-static void class_device_dev_unlink(struct class_device * class_dev)
-{
- sysfs_remove_link(&class_dev->kobj, "device");
-}
+ sysfs_create_link(&class_dev->kobj, &class_dev->dev->kobj, "device");
-static int class_device_driver_link(struct class_device * class_dev)
-{
- if ((class_dev->dev) && (class_dev->dev->driver))
- return sysfs_create_link(&class_dev->kobj,
-&class_dev->dev->driver->kobj,
"driver");
- return 0;
+ if (class_dev->dev->driver)
+ sysfs_create_link(&class_dev->kobj,
+ &class_dev->dev->driver->kobj, "driver");
+
+ if (class_dev->dev->bus)
+ sysfs_create_link(&class_dev->kobj,
+ &class_dev->dev->bus->subsys.kset.kobj,
+ "bus");
}
-static void class_device_driver_unlink(struct class_device * class_dev)
+static void class_device_remove_dev_symlinks(struct class_device *class_dev)
{
+ if (!class_dev->dev)
+ return 0;
+
+ sysfs_remove_link(&class_dev->kobj, "device");
sysfs_remove_link(&class_dev->kobj, "driver");
+ sysfs_remove_link(&class_dev->kobj, "bus");
}
-
static ssize_t
class_device_attr_show(struct kobject * kobj, struct attribute * attr,
char * buf)
@@ -452,8 +452,7 @@ int class_device_add(struct class_device
class_device_create_file(class_dev, &class_device_attr_dev);
class_device_add_attrs(class_dev);
- class_device_dev_link(class_dev);
- class_device_driver_link(class_dev);
+ class_device_add_dev_symlinks(class_dev);
register_done:
if (error && parent)
@@ -482,8 +481,7 @@ void class_device_del(struct class_devic
up_write(&parent->subsys.rwsem);
}
- class_device_dev_unlink(class_dev);
- class_device_driver_unlink(class_dev);
+ class_device_remove_dev_symlinks(class_dev);
class_device_remove_attrs(class_dev);
kobject_del(&class_dev->kobj);
= fs/partitions/check.c 1.129 vs edited =
--- 1.129/fs/partitions/check.c 2005-01-31 07:33:40 +01:00
+++ edited/fs/partitions/check.c2005-02-15 21:14:43 +01:00
@@ -318,6 +318,8 @@ static void disk_sysfs_symlinks(struct g
struct device *target = get_device(disk->driverfs_dev);
if (target) {
sysfs_create_link(&disk->kobj,&target->kobj,"device");
+ if (target->bus)
+
sysfs_create_link(&disk->kobj,&target->bus->subsys.kset.kobj,"bus");
sysfs_create_link(&target->kobj,&disk->kobj,"block");
}
}
@@ -438,6 +440,7 @@ void del_gendisk(struct gendisk *disk)
if (disk->driverfs_dev) {
sysfs_remove_link(&disk->kobj, "device");
+ sysfs_remove_link(&disk->kobj, "bus");
sysfs_remove_link(&disk->driverfs_dev->kobj, "block");
put_device(disk->driverfs_dev);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ple
