Re: a 15 GB file on tmpfs
On Wed, Jul 20, 2005 at 05:23:52PM +0200, Antonio Vargas wrote: > Most probably the cost of programming and debugging the hand-made > paging on 32bit machines will cost more than the difference for a > 64bit machine. I'll second that. There may not even be a price difference. I've had quotes for otherwise comprable 32 bit Xeon servers come in more expensive than 64 bit AMD machines. One piece of advice I would offer is to make sure you buy good ECC memory. I've been working with large servers for the last few years, and trying to be cheap with memory has caused a lot of hard to track down problems. - Jim -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.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/
Re: [linux-pm] [PATCH] Corrected Workqueue freezer support.
On Thursday 21 July 2005 00:32, Nigel Cunningham wrote: > (Fixed to remove the latent mention of syncthreads). > > This patch implements freezer support for workqueues. The current > refrigerator implementation makes all workqueues NOFREEZE, regardless of > whether they need to be or not. > I think kseriod and kgameportd threads can be left freezable. -- 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: [patch,rfc] Support for touchscreen on sharp zaurus sl-5500
Hi,
On Thursday 21 July 2005 00:24, Pavel Machek wrote:
>
> +config TOUCHSCREEN_COLLIE
> + tristate "Collie touchscreen (for Sharp SL-5500)"
> + depends on MCP_UCB1200 && INPUT
I don't think you need && INPUT here.
>
> obj-$(CONFIG_TOUCHSCREEN_BITSY) += h3600_ts_input.o
> obj-$(CONFIG_TOUCHSCREEN_CORGI) += corgi_ts.o
> +obj-$(CONFIG_TOUCHSCREEN_COLLIE)+= collie_ts.o
A tab would be nice.
> +
> +/*
> + * This is a RT kernel thread that handles the ADC accesses
> + * (mainly so we can use semaphores in the UCB1200 core code
> + * to serialise accesses to the ADC). The UCB1400 access
> + * functions are expected to be able to sleep as well.
> + */
> +static int ucb1x00_thread(void *_ts)
> +{
> + struct ucb1x00_ts *ts = _ts;
> + struct task_struct *tsk = current;
> + int valid;
> +
> + ts->rtask = tsk;
> +
> + daemonize("ktsd");
> + /* only want to receive SIGKILL */
> + allow_signal(SIGKILL);
> +
This should be converted to kthread interface.
> +static int ucb1x00_ts_open(struct input_dev *idev)
> +{
> + struct ucb1x00_ts *ts = (struct ucb1x00_ts *)idev;
> + int ret = 0;
> +
> + if (down_interruptible(>sem))
> + return -EINTR;
> +
> + if (ts->use_count++ != 0)
> + goto out;
> +
Please kill both ts->sem and ts->use_count - input core already serializes
input_open and input_close.
> + if (ts->rtask)
> + panic("ucb1x00: rtask running?");
> +
> + sema_init(>irq_wait, 0);
> + ret = ucb1x00_hook_irq(ts->ucb, UCB_IRQ_TSPX, ucb1x00_ts_irq, ts);
> + if (ret < 0)
> + goto out;
> +
> + /*
> + * If we do this at all, we should allow the user to
> + * measure and read the X and Y resistance at any time.
> + */
> + ucb1x00_adc_enable(ts->ucb);
> + ts->x_res = ucb1x00_ts_read_xres(ts);
> + ts->y_res = ucb1x00_ts_read_yres(ts);
> + ucb1x00_adc_disable(ts->ucb);
> +
> + init_completion(>init_exit);
> + ret = kernel_thread(ucb1x00_thread, ts, CLONE_KERNEL);
> + if (ret >= 0) {
> + wait_for_completion(>init_exit);
> + ret = 0;
> + } else {
> + ucb1x00_free_irq(ts->ucb, UCB_IRQ_TSPX, ts);
> + }
kthread_run(ucb1x00_thread, ts, "ktsd")...
> +
> +MODULE_PARM(adcsync, "i");
> +MODULE_PARM_DESC(adcsync, "Enable use of ADCSYNC signal");
Die, MODULE_PARM, die!
--
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/
[PATCH] Corrected Workqueue freezer support.
(Fixed to remove the latent mention of syncthreads).
This patch implements freezer support for workqueues. The current
refrigerator implementation makes all workqueues NOFREEZE, regardless of
whether they need to be or not.
While this doesn't appear to have caused any problems with swsusp (ie
Pavel's version) to date, this is no guarantee for the future.
Furthermore, it seems better to me to treat kernel and userspace threads
consistently, and it also enables us to err on the side of caution by
default with new workqueues.
Queues can be made unfreezable via the new kthread_nonfreeze_run,
create_nofreeze_workqueue and create_nofreeze_singlethread_workqueue
calls, which take the same parameters as kthread_run, create_workqueue
and create_singlethread_workqueue respectively. Existing call syntax is
unchanged and the vast majority of current workqueue calls are therefore
unaffected.
As far as Suspend2 goes, I don't rate this as critical. May save your
hard disk partition one day, but that depends upon what workqueues get
implemented in the future, what out of tree ones do and whether I've
missed good rationale for having nofreeze on existing in tree instances.
If you must flame me, call me overly careful :>.
Regards,
Nigel
Signed-off by: Nigel Cunningham <[EMAIL PROTECTED]>
drivers/acpi/osl.c |2 +-
drivers/block/ll_rw_blk.c |2 +-
drivers/char/hvc_console.c |2 +-
drivers/char/hvcs.c |2 +-
drivers/input/serio/serio.c |2 +-
drivers/md/dm-crypt.c |2 +-
drivers/scsi/hosts.c|2 +-
drivers/usb/net/pegasus.c |2 +-
include/linux/kthread.h | 20 ++--
include/linux/workqueue.h |9 ++---
kernel/kthread.c| 23 ++-
kernel/sched.c |4 ++--
kernel/softirq.c|3 +--
kernel/workqueue.c | 21 -
14 files changed, 69 insertions(+), 27 deletions(-)
diff -ruNp 400-workthreads.patch-old/drivers/acpi/osl.c
400-workthreads.patch-new/drivers/acpi/osl.c
--- 400-workthreads.patch-old/drivers/acpi/osl.c2005-07-18
06:36:41.0 +1000
+++ 400-workthreads.patch-new/drivers/acpi/osl.c2005-07-20
08:52:31.0 +1000
@@ -98,7 +98,7 @@ acpi_os_initialize1(void)
return AE_NULL_ENTRY;
}
#endif
- kacpid_wq = create_singlethread_workqueue("kacpid");
+ kacpid_wq = create_nofreeze_singlethread_workqueue("kacpid");
BUG_ON(!kacpid_wq);
return AE_OK;
diff -ruNp 400-workthreads.patch-old/drivers/block/ll_rw_blk.c
400-workthreads.patch-new/drivers/block/ll_rw_blk.c
--- 400-workthreads.patch-old/drivers/block/ll_rw_blk.c 2005-07-18
06:36:42.0 +1000
+++ 400-workthreads.patch-new/drivers/block/ll_rw_blk.c 2005-07-21
00:44:30.0 +1000
@@ -3215,7 +3215,7 @@ EXPORT_SYMBOL(kblockd_flush);
int __init blk_dev_init(void)
{
- kblockd_workqueue = create_workqueue("kblockd");
+ kblockd_workqueue = create_nofreeze_workqueue("kblockd");
if (!kblockd_workqueue)
panic("Failed to create kblockd\n");
diff -ruNp 400-workthreads.patch-old/drivers/char/hvc_console.c
400-workthreads.patch-new/drivers/char/hvc_console.c
--- 400-workthreads.patch-old/drivers/char/hvc_console.c2005-07-18
06:36:43.0 +1000
+++ 400-workthreads.patch-new/drivers/char/hvc_console.c2005-07-20
08:52:31.0 +1000
@@ -844,7 +844,7 @@ int __init hvc_init(void)
/* Always start the kthread because there can be hotplug vty adapters
* added later. */
- hvc_task = kthread_run(khvcd, NULL, "khvcd");
+ hvc_task = kthread_nofreeze_run(khvcd, NULL, "khvcd");
if (IS_ERR(hvc_task)) {
panic("Couldn't create kthread for console.\n");
put_tty_driver(hvc_driver);
diff -ruNp 400-workthreads.patch-old/drivers/char/hvcs.c
400-workthreads.patch-new/drivers/char/hvcs.c
--- 400-workthreads.patch-old/drivers/char/hvcs.c 2005-07-18
06:36:43.0 +1000
+++ 400-workthreads.patch-new/drivers/char/hvcs.c 2005-07-20
08:52:31.0 +1000
@@ -1403,7 +1403,7 @@ static int __init hvcs_module_init(void)
return -ENOMEM;
}
- hvcs_task = kthread_run(khvcsd, NULL, "khvcsd");
+ hvcs_task = kthread_nofreeze_run(khvcsd, NULL, "khvcsd");
if (IS_ERR(hvcs_task)) {
printk(KERN_ERR "HVCS: khvcsd creation failed. Driver not
loaded.\n");
kfree(hvcs_pi_buff);
diff -ruNp 400-workthreads.patch-old/drivers/input/serio/serio.c
400-workthreads.patch-new/drivers/input/serio/serio.c
--- 400-workthreads.patch-old/drivers/input/serio/serio.c 2005-07-21
15:29:32.0 +1000
+++ 400-workthreads.patch-new/drivers/input/serio/serio.c 2005-07-20
08:52:31.0 +1000
@@ -889,7 +889,7 @@ irqreturn_t serio_interrupt(struct serio
static int __init serio_init(void)
{
- serio_task =
Re: amd64-agp vs. swsusp
Hi! > >>I have rebuilt agpgart and amd64-agp into the kernel and now it has > >>resumed successfully for the first time. Thank you for the hint! > >> > >>But I still wonder, why that makes a difference. > > > > > >Before resume the module is not present. When it gets loaded from the > >image it probably runs with the assumption that the hardware was > >initialized > >which is not correct. > > It seems that the module doesn't even get a chance to run after resume. > I've put some printks and udelays into kernel/power/swsusp.c and other > places and I've found that the spontaneous reset occurs already in > swsusp_arch_resume(), ie. before the drivers get their resume methods > called. This is what I have in swsusp_suspend() now: > ... > save_processor_state(); > if ((error = swsusp_arch_suspend())) > printk(KERN_ERR "Error %d suspending\n", error); > /* Restore control flow magically appears here */ > restore_processor_state(); > printk(KERN_INFO "processor state restored!\n");/*I added this*/ > BUG_ON (nr_copy_pages_check != nr_copy_pages); > restore_highmem(); > device_power_up(); > ... > > I'm recording the screen during resuming with a digital camera to see if > the added printk is displayed before the reset and I am now sure that > the reset occurs before that. The last thing I see is: > > Stopping tasks: --| > Freeing memory... done (0 pages freed) > swsusp: Need to copy 8121 pages > > Then on the next frame of the recorded MPEG, the display is already > beginning to dim as the computer is resetting. > > I also tried putting a printk before restore_processor_state(), but I'm > not sure if it is safe to use printk there. > So I tried putting a loop of 5000 x udelay(1000) there to see if the > reset would be delayed by 5s. It was not delayed, so I think that the > reset occurs before restore_processor_state(). Long time ago there were i386 problems because we assumed that kernel is mapped in one big mapping and agp broke that assumption. Copying pages backwards "fixed" it (and then we done proper fix). It should not be, but it seems similar to this problem Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] generic_file_sendpage
On Fri, Jul 15, 2005 at 01:22:55PM +0200, Jörn Engel wrote: > On Fri, 15 July 2005 04:06:11 -0700, Andrew Morton wrote: > > > + > > > + /* There is no sane reason to use O_DIRECT */ > > > + BUG_ON(file->f_flags & O_DIRECT); > > > > err, this seems like an easy way for people to make the kernel go BUG. > > Is there a sane use for O_DIRECT in combination with sendfile()? > > If not, I'd like to change sys_sendfile() and return -EINVAL for > O_DIRECT file descriptors. > > > > + if (unlikely(signal_pending(current))) > > > + return -EINTR; > > > > This doesn't help. The reason we've avoided file-to-file sendfile() is > > that it can cause applications to get uninterruptibly stuck in the kernel > > for ages. This code doesn't solve that problem. It needs to handle > > signal_pending() inside the main loop. > > > > And it probably needs to return a sane value (number of bytes copied) > > rather than -EINTR. > > Makes sense. > > > I don't know if we want to add this feature, really. It's such a > > specialised thing. > > With union mount and cowlink, there are two users already. cp(1) > could use it as well, even if the improvement is quite minimal. you might soon add linux-vserver to the list, as we will be using this for a special version of the COW links (to break unified links on write) ... best, Herbert > Jörn > > -- > All art is but imitation of nature. > -- Lucius Annaeus Seneca > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message 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: Linux v2.6.13-rc3
>Len, ACPI people - can we fix this regression, please? > >Rafael even pinpoints exactly which patches are causing the >problem, so why didn't they get reverted before sending them off to me? Linus, I'm sorry it was in '-rc3' -- that is as soon as I could muster the bk->git transition. Now that I'm running on git, I expect I'll be able to get the development/testing/push pipeline moving and back on schedule. Yes, we discovered both of these regressions in mm. Yes, Rafael has been a sport in filing good bug reports, and his Asus L5D has been an interesting case. Although we broke this system, I do believe that there is significant value in keeping these changes in the mainline, as I believe that it is the fastest path to improved support for all systems. Specifically... Re: the EC burst mode regression. This is an extremely important fix that has been nagging many systems for years. It has been reported to us by distros as well as on kernel.org: http://bugzilla.kernel.org/show_bug.cgi?id=3851 There has been a lot of discussion about this on the mailing list and there have been several generations of patches. We are confident that this approach is the correct solution, but clearly there are some snags. It is probable that the snags are model specific. Ironically, it would be a benefit if more machines broke like the Asus L5D because we've had a heck of a time trying to reproduce this. Indeed, I purchased an AMD laptop as similar to that model as I could find and shipped it to China explicitly for Luming to debug this very issue. Alas, that model, only slightly different, works perfectly... Re: pci_link.c regression on suspend/resume This is the issue that Patrick was trying to describe in the KS -- that we're knowingly breaking some drivers on suspend/resume. http://bugzilla.kernel.org/show_bug.cgi?id=3469 We intentionally removed a hack we put in to blindly restore PCI interrupt links. The hack can never be reliable because the AML interpreter must run to restore PCI links and it must run arbitrary AML code. But it can sleep on memory allocation and semaphores, and thus can't reliably run before we have interrupts enabled. We discussed this on linux-pm and at the PM-summit, and the consensus was that making the interrupt restoring process on resume more like boot will lead to a more robust design. The down-side is that drivers that worked before will break, and it is not a quick fix as we work our way through it. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LZF Cryptoapi support.
Hi!
> New revision. Anything left to fix up?
It certainly looks better now.
> +static int lzf_compress_init(void *context)
> +{
> + struct lzf_ctx *ctx = (struct lzf_ctx *)context;
> +
> + /* Get LZF ready to go */
> + ctx->hbuf = vmalloc_32((1 << hlog) * sizeof(char *));
> + if (!ctx->hbuf) {
> + printk(KERN_WARNING
> +"Failed to allocate %d bytes for lzf workspace\n",
> +(1 << hlog) * sizeof(char *));
> + return -ENOMEM;
> + }
> +
> + /* Allocate local buffer */
> + ctx->local_buffer = (char *)get_zeroed_page(GFP_ATOMIC);
> +
> + if (!ctx->local_buffer) {
> + lzf_compress_exit(ctx);
> + return -ENOMEM;
> + }
> +
> + /* Allocate page buffer */
> + ctx->page_buffer = (char *)get_zeroed_page(GFP_ATOMIC);
Why GFP_ATOMIC in last two?
> + if (!ctx->page_buffer) {
> + free_page((unsigned long)ctx->local_buffer);
> + lzf_compress_exit(ctx);
> + return -ENOMEM;
> + }
> +
> + ctx->first_call = 1;
> +
> + return 0;
> +}
> +
> +static int lzf_compress(void *context, const u8 * in_data, unsigned int
> in_len,
~ extra space; it
is inconsistent all over the file.
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 suspend/resume support to locomo.c
From: John Lenz <[EMAIL PROTECTED]>
This adds low-level suspend/resume support to locomo.c.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -541,6 +541,103 @@ locomo_init_one_child(struct locomo *lch
return ret;
}
+#ifdef CONFIG_PM
+
+struct locomo_save_data {
+ u16 LCM_GPO;
+ u16 LCM_SPICT;
+ u16 LCM_GPE;
+ u16 LCM_ASD;
+ u16 LCM_SPIMD;
+};
+
+static int locomo_suspend(struct device *dev, u32 pm_message_t, u32 level)
+{
+ struct locomo *lchip = dev_get_drvdata(dev);
+ struct locomo_save_data *save;
+ unsigned long flags;
+
+ if (level != SUSPEND_DISABLE)
+ return 0;
+
+ save = kmalloc(sizeof(struct locomo_save_data), GFP_KERNEL);
+ if (!save)
+ return -ENOMEM;
+
+ dev->power.saved_state = (void *) save;
+
+ spin_lock_irqsave(>lock, flags);
+
+ save->LCM_GPO = locomo_readl(lchip->base + LOCOMO_GPO); /* GPIO
*/
+ locomo_writel(0x00, lchip->base + LOCOMO_GPO);
+ save->LCM_SPICT = locomo_readl(lchip->base + LOCOMO_SPICT); /* SPI
*/
+ locomo_writel(0x40, lchip->base + LOCOMO_SPICT);
+ save->LCM_GPE = locomo_readl(lchip->base + LOCOMO_GPE); /* GPIO
*/
+ locomo_writel(0x00, lchip->base + LOCOMO_GPE);
+ save->LCM_ASD = locomo_readl(lchip->base + LOCOMO_ASD); /*
ADSTART */
+ locomo_writel(0x00, lchip->base + LOCOMO_ASD);
+ save->LCM_SPIMD = locomo_readl(lchip->base + LOCOMO_SPIMD); /* SPI
*/
+ locomo_writel(0x3C14, lchip->base + LOCOMO_SPIMD);
+
+ locomo_writel(0x00, lchip->base + LOCOMO_PAIF);
+ locomo_writel(0x00, lchip->base + LOCOMO_DAC);
+ locomo_writel(0x00, lchip->base + LOCOMO_BACKLIGHT + LOCOMO_TC);
+
+ if ( (locomo_readl(lchip->base + LOCOMO_LED + LOCOMO_LPT0) & 0x88) &&
(locomo_readl(lchip->base + LOCOMO_LED + LOCOMO_LPT1) & 0x88) )
+ locomo_writel(0x00, lchip->base + LOCOMO_C32K); /*
CLK32 off */
+ else
+ /* 18MHz already enabled, so no wait */
+ locomo_writel(0xc1, lchip->base + LOCOMO_C32K); /*
CLK32 on */
+
+ locomo_writel(0x00, lchip->base + LOCOMO_TADC); /* 18MHz clock
off*/
+ locomo_writel(0x00, lchip->base + LOCOMO_AUDIO + LOCOMO_ACC);
/* 22MHz/24MHz clock off */
+ locomo_writel(0x00, lchip->base + LOCOMO_FRONTLIGHT + LOCOMO_ALS);
/* FL */
+
+ spin_unlock_irqrestore(>lock, flags);
+
+ return 0;
+}
+
+static int locomo_resume(struct device *dev, u32 level)
+{
+ struct locomo *lchip = dev_get_drvdata(dev);
+ struct locomo_save_data *save;
+ unsigned long r;
+ unsigned long flags;
+
+ if (level != RESUME_ENABLE)
+ return 0;
+
+ save = (struct locomo_save_data *) dev->power.saved_state;
+ if (!save)
+ return 0;
+
+ spin_lock_irqsave(>lock, flags);
+
+ locomo_writel(save->LCM_GPO, lchip->base + LOCOMO_GPO);
+ locomo_writel(save->LCM_SPICT, lchip->base + LOCOMO_SPICT);
+ locomo_writel(save->LCM_GPE, lchip->base + LOCOMO_GPE);
+ locomo_writel(save->LCM_ASD, lchip->base + LOCOMO_ASD);
+ locomo_writel(save->LCM_SPIMD, lchip->base + LOCOMO_SPIMD);
+
+ locomo_writel(0x00, lchip->base + LOCOMO_C32K);
+ locomo_writel(0x90, lchip->base + LOCOMO_TADC);
+
+ locomo_writel(0, lchip->base + LOCOMO_KEYBOARD + LOCOMO_KSC);
+ r = locomo_readl(lchip->base + LOCOMO_KEYBOARD + LOCOMO_KIC);
+ r &= 0xFEFF;
+ locomo_writel(r, lchip->base + LOCOMO_KEYBOARD + LOCOMO_KIC);
+ locomo_writel(0x1, lchip->base + LOCOMO_KEYBOARD + LOCOMO_KCMD);
+
+ spin_unlock_irqrestore(>lock, flags);
+
+ dev->power.saved_state = NULL;
+ kfree(save);
+
+ return 0;
+}
+#endif
+
/**
* locomo_probe - probe for a single LoCoMo chip.
* @phys_addr: physical address of device.
@@ -707,6 +810,10 @@ static struct device_driver locomo_devic
.bus= _bus_type,
.probe = locomo_probe,
.remove = locomo_remove,
+#ifdef CONFIG_PM
+ .suspend= locomo_suspend,
+ .resume = locomo_resume,
+#endif
};
/*
--
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch,rfc] Support for touchscreen on sharp zaurus sl-5500
Hi!
This adds support for touchscreen of sharp zaurus sl-5500. I got the
patches from John Lenz <[EMAIL PROTECTED]>, but lots of copyrights are
Russell King. To do so, it needs to add quite a bit of
infrastructure. If there's better place for some code, please let me
know (I already moved touchscreen parts to drivers/input).
Pavel
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -36,6 +36,15 @@ config TOUCHSCREEN_CORGI
To compile this driver as a module, choose M here: the
module will be called ads7846_ts.
+config TOUCHSCREEN_COLLIE
+ tristate "Collie touchscreen (for Sharp SL-5500)"
+ depends on MCP_UCB1200 && INPUT
+ help
+ Say Y here to enable the driver for the touchscreen on the
+ Sharp SL-5500 series of PDAs.
+
+ If unsure, say N.
+
config TOUCHSCREEN_GUNZE
tristate "Gunze AHL-51S touchscreen"
select SERIO
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -6,6 +6,7 @@
obj-$(CONFIG_TOUCHSCREEN_BITSY)+= h3600_ts_input.o
obj-$(CONFIG_TOUCHSCREEN_CORGI)+= corgi_ts.o
+obj-$(CONFIG_TOUCHSCREEN_COLLIE)+= collie_ts.o
obj-$(CONFIG_TOUCHSCREEN_GUNZE)+= gunze.o
obj-$(CONFIG_TOUCHSCREEN_ELO) += elo.o
obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o
diff --git a/drivers/input/touchscreen/collie_ts.c
b/drivers/input/touchscreen/collie_ts.c
new file mode 100644
--- /dev/null
+++ b/drivers/input/touchscreen/collie_ts.c
@@ -0,0 +1,437 @@
+/*
+ * linux/drivers/input/touchscreen/collie_ts.c
+ *
+ * Copyright (C) 2001 Russell King, All Rights Reserved.
+ *
+ * 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.
+ *
+ * 21-Jan-2002 <[EMAIL PROTECTED]> :
+ *
+ * Added support for synchronous A/D mode. This mode is useful to
+ * avoid noise induced in the touchpanel by the LCD, provided that
+ * the UCB1x00 has a valid LCD sync signal routed to its ADCSYNC pin.
+ * It is important to note that the signal connected to the ADCSYNC
+ * pin should provide pulses even when the LCD is blanked, otherwise
+ * a pen touch needed to unblank the LCD will never be read.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+
+struct ucb1x00_ts {
+ struct input_devidev;
+ struct ucb1x00 *ucb;
+
+ struct semaphoreirq_wait;
+ struct semaphoresem;
+ struct completion init_exit;
+ struct task_struct *rtask;
+ int use_count;
+ u16 x_res;
+ u16 y_res;
+
+ int restart:1;
+ int adcsync:1;
+};
+
+static int adcsync = UCB_NOSYNC;
+
+static inline void ucb1x00_ts_evt_add(struct ucb1x00_ts *ts, u16 pressure, u16
x, u16 y)
+{
+ input_report_abs(>idev, ABS_X, x);
+ input_report_abs(>idev, ABS_Y, y);
+ input_report_abs(>idev, ABS_PRESSURE, pressure);
+ input_sync(>idev);
+}
+
+static inline void ucb1x00_ts_event_release(struct ucb1x00_ts *ts)
+{
+ input_report_abs(>idev, ABS_PRESSURE, 0);
+ input_sync(>idev);
+}
+
+/*
+ * Switch to interrupt mode.
+ */
+static inline void ucb1x00_ts_mode_int(struct ucb1x00_ts *ts)
+{
+ int val = UCB_TS_CR_TSMX_POW | UCB_TS_CR_TSPX_POW |
+ UCB_TS_CR_TSMY_GND | UCB_TS_CR_TSPY_GND |
+ UCB_TS_CR_MODE_INT;
+ if (ts->ucb->id == UCB_ID_1400_BUGGY)
+ val &= ~(UCB_TS_CR_TSMX_POW | UCB_TS_CR_TSPX_POW);
+ ucb1x00_reg_write(ts->ucb, UCB_TS_CR, val);
+}
+
+/*
+ * Switch to pressure mode, and read pressure. We don't need to wait
+ * here, since both plates are being driven.
+ */
+static inline unsigned int ucb1x00_ts_read_pressure(struct ucb1x00_ts *ts)
+{
+ ucb1x00_reg_write(ts->ucb, UCB_TS_CR,
+ UCB_TS_CR_TSMX_POW | UCB_TS_CR_TSPX_POW |
+ UCB_TS_CR_TSMY_GND | UCB_TS_CR_TSPY_GND |
+ UCB_TS_CR_MODE_PRES | UCB_TS_CR_BIAS_ENA);
+
+ return ucb1x00_adc_read(ts->ucb, UCB_ADC_INP_TSPY, ts->adcsync);
+}
+
+/*
+ * Switch to X position mode and measure Y plate. We switch the plate
+ * configuration in pressure mode, then switch to position mode. This
+ * gives a faster response time. Even so, we need to wait about 55us
+ * for things to stabilise.
+ */
+static inline unsigned int ucb1x00_ts_read_xpos(struct ucb1x00_ts *ts)
+{
+ ucb1x00_reg_write(ts->ucb, UCB_TS_CR,
+
[PATCH] Syncthreads support.
This patch implements a new PF_SYNCTHREAD flag, which allows upcoming
the refrigerator implementation to know that a thread is syncing data to
disk. This allows the refrigerator to be more reliable, even under heavy
load, because it can separate userspace processes that are submitting
I/O from those trying to sync it and freezing the former first. We can
thus ensure that syncing processes complete their work more quickly and
the refrigerator is far less likely to incorrectly give up (thinking a
syncing process is completely failing to enter the refrigerator).
Signed-off by: Nigel Cunningham <[EMAIL PROTECTED]>
fs/buffer.c | 45 +++--
include/linux/sched.h |2 ++
2 files changed, 45 insertions(+), 2 deletions(-)
diff -ruNp 410-syncthreads.patch-old/fs/buffer.c
410-syncthreads.patch-new/fs/buffer.c
--- 410-syncthreads.patch-old/fs/buffer.c 2005-07-18 06:36:58.0
+1000
+++ 410-syncthreads.patch-new/fs/buffer.c 2005-07-21 15:18:42.0
+1000
@@ -171,6 +171,15 @@ EXPORT_SYMBOL(sync_blockdev);
*/
int fsync_super(struct super_block *sb)
{
+ int ret;
+
+ /* A safety net. During suspend, we might overwrite
+* memory containing filesystem info. We don't then
+* want to sync it to disk. */
+ BUG_ON(test_suspend_state(SUSPEND_DISABLE_SYNCING));
+
+ current->flags |= PF_SYNCTHREAD;
+
sync_inodes_sb(sb, 0);
DQUOT_SYNC(sb);
lock_super(sb);
@@ -182,7 +191,10 @@ int fsync_super(struct super_block *sb)
sync_blockdev(sb->s_bdev);
sync_inodes_sb(sb, 1);
- return sync_blockdev(sb->s_bdev);
+ ret = sync_blockdev(sb->s_bdev);
+
+ current->flags &= ~PF_SYNCTHREAD;
+ return ret;
}
/*
@@ -193,12 +205,21 @@ int fsync_super(struct super_block *sb)
int fsync_bdev(struct block_device *bdev)
{
struct super_block *sb = get_super(bdev);
+ int ret;
+
+ BUG_ON(test_suspend_state(SUSPEND_DISABLE_SYNCING));
+
+ current->flags |= PF_SYNCTHREAD;
+
if (sb) {
int res = fsync_super(sb);
drop_super(sb);
+ current->flags &= ~PF_SYNCTHREAD;
return res;
}
- return sync_blockdev(bdev);
+ ret = sync_blockdev(bdev);
+ current->flags &= ~PF_SYNCTHREAD;
+ return ret;
}
/**
@@ -278,6 +299,13 @@ EXPORT_SYMBOL(thaw_bdev);
*/
static void do_sync(unsigned long wait)
{
+ /* A safety net. During suspend, we might overwrite
+* memory containing filesystem info. We don't then
+* want to sync it to disk. */
+ BUG_ON(test_suspend_state(SUSPEND_DISABLE_SYNCING));
+
+ current->flags |= PF_SYNCTHREAD;
+
wakeup_pdflush(0);
sync_inodes(0); /* All mappings, inodes and their blockdevs */
DQUOT_SYNC(NULL);
@@ -289,6 +317,8 @@ static void do_sync(unsigned long wait)
printk("Emergency Sync complete\n");
if (unlikely(laptop_mode))
laptop_sync_completion();
+
+ current->flags &= ~PF_SYNCTHREAD;
}
asmlinkage long sys_sync(void)
@@ -314,6 +344,10 @@ int file_fsync(struct file *filp, struct
struct super_block * sb;
int ret, err;
+ BUG_ON(test_suspend_state(SUSPEND_DISABLE_SYNCING));
+
+ current->flags |= PF_SYNCTHREAD;
+
/* sync the inode to buffers */
ret = write_inode_now(inode, 0);
@@ -328,6 +362,8 @@ int file_fsync(struct file *filp, struct
err = sync_blockdev(sb->s_bdev);
if (!ret)
ret = err;
+
+ current->flags &= ~PF_SYNCTHREAD;
return ret;
}
@@ -337,6 +373,10 @@ static long do_fsync(unsigned int fd, in
struct address_space *mapping;
int ret, err;
+ BUG_ON(test_suspend_state(SUSPEND_DISABLE_SYNCING));
+
+ current->flags |= PF_SYNCTHREAD;
+
ret = -EBADF;
file = fget(fd);
if (!file)
@@ -370,6 +410,7 @@ static long do_fsync(unsigned int fd, in
out_putf:
fput(file);
out:
+ current->flags &= ~PF_SYNCTHREAD;
return ret;
}
diff -ruNp 410-syncthreads.patch-old/include/linux/sched.h
410-syncthreads.patch-new/include/linux/sched.h
--- 410-syncthreads.patch-old/include/linux/sched.h 2005-07-21
15:18:26.0 +1000
+++ 410-syncthreads.patch-new/include/linux/sched.h 2005-07-21
15:18:42.0 +1000
@@ -829,6 +829,8 @@ do { if (atomic_dec_and_test(&(tsk)->usa
#define PF_SYNCWRITE 0x0020 /* I am doing a sync write */
#define PF_BORROWED_MM 0x0040 /* I am a kthread doing use_mm */
#define PF_RANDOMIZE 0x0080 /* randomize virtual address space */
+#define PF_SYNCTHREAD 0x0100 /* this thread can start activity
during the
++ early part of freezing processes */
/*
* Only the _current_ task can read/write to tsk->flags, but other
--
Evolution.
Enumerate the
[patch] fix compilation in collie.c
This fixes wrong number of arguments in call to write_scoop_reg, fixes
map_name and John's email. Please apply,
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/arch/arm/mach-sa1100/collie.c b/arch/arm/mach-sa1100/collie.c
--- a/arch/arm/mach-sa1100/collie.c
+++ b/arch/arm/mach-sa1100/collie.c
@@ -11,7 +11,7 @@
* published by the Free Software Foundation.
*
* ChangeLog:
- * 03-06-2004 John Lenz <[EMAIL PROTECTED]>
+ * 03-06-2004 John Lenz <[EMAIL PROTECTED]>
* 06-04-2002 Chris Larson <[EMAIL PROTECTED]>
* 04-16-2001 Lineo Japan,Inc. ...
*/
@@ -111,16 +180,16 @@ static struct mtd_partition collie_parti
static void collie_set_vpp(int vpp)
{
- write_scoop_reg(SCOOP_GPCR, read_scoop_reg(SCOOP_GPCR) |
COLLIE_SCP_VPEN);
+ write_scoop_reg(NULL, SCOOP_GPCR, read_scoop_reg(NULL, SCOOP_GPCR) |
COLLIE_SCP_VPEN);
if (vpp) {
- write_scoop_reg(SCOOP_GPWR, read_scoop_reg(SCOOP_GPWR) |
COLLIE_SCP_VPEN);
+ write_scoop_reg(NULL, SCOOP_GPWR, read_scoop_reg(NULL,
SCOOP_GPWR) | COLLIE_SCP_VPEN);
} else {
- write_scoop_reg(SCOOP_GPWR, read_scoop_reg(SCOOP_GPWR) &
~COLLIE_SCP_VPEN);
+ write_scoop_reg(NULL, SCOOP_GPWR, read_scoop_reg(NULL,
SCOOP_GPWR) & ~COLLIE_SCP_VPEN);
}
}
static struct flash_platform_data collie_flash_data = {
- .map_name = "cfi_probe",
+ .map_name = "sharp",
.set_vpp= collie_set_vpp,
.parts = collie_partitions,
.nr_parts = ARRAY_SIZE(collie_partitions),
--
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] FAT robustness
Hi! > >[...] > > Q3 : I'm not sure JBD can be used for FAT improvements. Do you > >have any comments ? > > I might not be the best person to answer this, but this just seems so > obvious: > > If you plan to let a recently hot-unplugged device to be used in another > OS that doesn't understand your journaling extensions, your disk will be > corrupted. It will only be corrupted if you unplug it without unmounting, and it will only be corrupted as much as non-journalling disk is. Plus, you might intentionaly damage superblock signature on mount (an fix it on clean umount) so that you force user to plug it back to journalling system Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Where can I find the RPC FSM document?
I'd like to learn some details of how RPC's FSM works (e.g. the changing graph of all states). I know one possibility is to read the source code, but it is a little time consuming. Can someone kindly direct me to some documents about the rpc implementatino? Thanks in advance! -x - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Workqueue freezer support.
This patch implements freezer support for workqueues. The current
refrigerator implementation makes all workqueues NOFREEZE, regardless of
whether they need to be or not.
While this doesn't appear to have caused any problems with swsusp (ie
Pavel's version) to date, this is no guarantee for the future.
Furthermore, it seems better to me to treat kernel and userspace threads
consistently, and it also enables us to err on the side of caution by
default with new workqueues.
Queues can be made unfreezable via the new kthread_nonfreeze_run,
create_nofreeze_workqueue and create_nofreeze_singlethread_workqueue
calls, which take the same parameters as kthread_run, create_workqueue
and create_singlethread_workqueue respectively. Existing call syntax is
unchanged and the vast majority of current workqueue calls are therefore
unaffected.
As far as Suspend2 goes, I don't rate this as critical. May save your
hard disk partition one day, but that depends upon what workqueues get
implemented in the future, what out of tree ones do and whether I've
missed good rationale for having nofreeze on existing in tree instances.
If you must flame me, call me overly careful :>.
Regards,
Nigel
Signed-off by: Nigel Cunningham <[EMAIL PROTECTED]>
drivers/acpi/osl.c |2 +-
drivers/block/ll_rw_blk.c |2 +-
drivers/char/hvc_console.c |2 +-
drivers/char/hvcs.c |2 +-
drivers/input/serio/serio.c |2 +-
drivers/md/dm-crypt.c |2 +-
drivers/scsi/hosts.c|2 +-
drivers/usb/net/pegasus.c |2 +-
include/linux/kthread.h | 20 ++--
include/linux/workqueue.h |9 ++---
kernel/kmod.c |4
kernel/kthread.c| 23 ++-
kernel/sched.c |4 ++--
kernel/softirq.c|3 +--
kernel/workqueue.c | 21 -
15 files changed, 73 insertions(+), 27 deletions(-)
diff -ruNp 400-workthreads.patch-old/drivers/acpi/osl.c
400-workthreads.patch-new/drivers/acpi/osl.c
--- 400-workthreads.patch-old/drivers/acpi/osl.c2005-07-18
06:36:41.0 +1000
+++ 400-workthreads.patch-new/drivers/acpi/osl.c2005-07-20
08:52:31.0 +1000
@@ -98,7 +98,7 @@ acpi_os_initialize1(void)
return AE_NULL_ENTRY;
}
#endif
- kacpid_wq = create_singlethread_workqueue("kacpid");
+ kacpid_wq = create_nofreeze_singlethread_workqueue("kacpid");
BUG_ON(!kacpid_wq);
return AE_OK;
diff -ruNp 400-workthreads.patch-old/drivers/block/ll_rw_blk.c
400-workthreads.patch-new/drivers/block/ll_rw_blk.c
--- 400-workthreads.patch-old/drivers/block/ll_rw_blk.c 2005-07-18
06:36:42.0 +1000
+++ 400-workthreads.patch-new/drivers/block/ll_rw_blk.c 2005-07-21
00:44:30.0 +1000
@@ -3215,7 +3215,7 @@ EXPORT_SYMBOL(kblockd_flush);
int __init blk_dev_init(void)
{
- kblockd_workqueue = create_workqueue("kblockd");
+ kblockd_workqueue = create_nofreeze_workqueue("kblockd");
if (!kblockd_workqueue)
panic("Failed to create kblockd\n");
diff -ruNp 400-workthreads.patch-old/drivers/char/hvc_console.c
400-workthreads.patch-new/drivers/char/hvc_console.c
--- 400-workthreads.patch-old/drivers/char/hvc_console.c2005-07-18
06:36:43.0 +1000
+++ 400-workthreads.patch-new/drivers/char/hvc_console.c2005-07-20
08:52:31.0 +1000
@@ -844,7 +844,7 @@ int __init hvc_init(void)
/* Always start the kthread because there can be hotplug vty adapters
* added later. */
- hvc_task = kthread_run(khvcd, NULL, "khvcd");
+ hvc_task = kthread_nofreeze_run(khvcd, NULL, "khvcd");
if (IS_ERR(hvc_task)) {
panic("Couldn't create kthread for console.\n");
put_tty_driver(hvc_driver);
diff -ruNp 400-workthreads.patch-old/drivers/char/hvcs.c
400-workthreads.patch-new/drivers/char/hvcs.c
--- 400-workthreads.patch-old/drivers/char/hvcs.c 2005-07-18
06:36:43.0 +1000
+++ 400-workthreads.patch-new/drivers/char/hvcs.c 2005-07-20
08:52:31.0 +1000
@@ -1403,7 +1403,7 @@ static int __init hvcs_module_init(void)
return -ENOMEM;
}
- hvcs_task = kthread_run(khvcsd, NULL, "khvcsd");
+ hvcs_task = kthread_nofreeze_run(khvcsd, NULL, "khvcsd");
if (IS_ERR(hvcs_task)) {
printk(KERN_ERR "HVCS: khvcsd creation failed. Driver not
loaded.\n");
kfree(hvcs_pi_buff);
diff -ruNp 400-workthreads.patch-old/drivers/input/serio/serio.c
400-workthreads.patch-new/drivers/input/serio/serio.c
--- 400-workthreads.patch-old/drivers/input/serio/serio.c 2005-07-21
04:00:03.0 +1000
+++ 400-workthreads.patch-new/drivers/input/serio/serio.c 2005-07-20
08:52:31.0 +1000
@@ -889,7 +889,7 @@ irqreturn_t serio_interrupt(struct serio
static int __init serio_init(void)
{
- serio_task =
[PATCH] v850: Add defconfigs
Signed-off-by: Miles Bader <[EMAIL PROTECTED]> arch/v850/Makefile |7 arch/v850/README | 62 ++- arch/v850/configs/rte-ma1-cb_defconfig | 605 + arch/v850/configs/rte-me2-cb_defconfig | 453 arch/v850/configs/sim_defconfig| 442 5 files changed, 1542 insertions(+), 27 deletions(-) diff -ruN -X../cludes linux-2.6.12-uc0/arch/v850/Makefile linux-2.6.12-uc0-v850-20050721/arch/v850/Makefile --- linux-2.6.12-uc0/arch/v850/Makefile 2003-07-28 10:13:57.643115000 +0900 +++ linux-2.6.12-uc0-v850-20050721/arch/v850/Makefile 2005-07-21 11:34:48.550867000 +0900 @@ -1,8 +1,8 @@ # # arch/v850/Makefile # -# Copyright (C) 2001,02,03 NEC Corporation -# Copyright (C) 2001,02,03 Miles Bader <[EMAIL PROTECTED]> +# Copyright (C) 2001,02,03,05 NEC Corporation +# Copyright (C) 2001,02,03,05 Miles Bader <[EMAIL PROTECTED]> # # This file is included by the global makefile so that you can add your own # architecture-specific flags and dependencies. Remember to do have actions @@ -22,6 +22,9 @@ CFLAGS += -fno-builtin CFLAGS += -D__linux__ -DUTS_SYSNAME=\"uClinux\" +# By default, build a kernel that runs on the gdb v850 simulator. +KBUILD_DEFCONFIG := sim_defconfig + # This prevents the linker from consolidating the .gnu.linkonce.this_module # section into .text (which the v850 default linker script for -r does for # some reason) diff -ruN -X../cludes linux-2.6.12-uc0/arch/v850/README linux-2.6.12-uc0-v850-20050721/arch/v850/README --- linux-2.6.12-uc0/arch/v850/README 2003-07-28 10:13:57.663116000 +0900 +++ linux-2.6.12-uc0-v850-20050721/arch/v850/README 2005-07-21 11:48:07.674661000 +0900 @@ -1,31 +1,43 @@ This port to the NEC V850E processor supports the following platforms: - + The gdb v850e simulator (CONFIG_V850E_SIM). + "sim" + The gdb v850e simulator (CONFIG_V850E_SIM). - + The Midas labs RTE-V850E/MA1-CB and RTE-V850E/NB85E-CB evaluation boards - (CONFIG_RTE_CB_MA1 and CONFIG_RTE_CB_NB85E). This support has only been - tested when running with the Multi-debugger monitor ROM (for the Green - Hills Multi debugger). The optional NEC Solution Gear RTE-MOTHER-A - motherboard is also supported, which allows PCI boards to be used - (CONFIG_RTE_MB_A_PCI). - - + The Midas labs RTE-V850E/ME2-CB evaluation board (CONFIG_RTE_CB_ME2). - This has only been tested using a kernel downloaded via an ICE connection - using the Multi debugger. Support for the RTE-MOTHER-A is present, but - hasn't been tested (unlike the other Midas labs cpu boards, the - RTE-V850E/ME2-CB includes an ethernet adaptor). - - + The NEC AS85EP1 V850E evaluation chip/board (CONFIG_V850E_AS85EP1). - - + The NEC `Anna' (board/chip) implementation of the V850E2 processor - (CONFIG_V850E2_ANNA). - - + The sim85e2c and sim85e2s simulators, which are verilog simulations of - the V850E2 NA85E2C/NA85E2S cpu cores (CONFIG_V850E2_SIM85E2C and - CONFIG_V850E2_SIM85E2S). - - + A FPGA implementation of the V850E2 NA85E2C cpu core - (CONFIG_V850E2_FPGA85E2C). + "rte-ma1-cb" + The Midas labs RTE-V850E/MA1-CB and RTE-V850E/NB85E-CB evaluation + boards (CONFIG_RTE_CB_MA1 and CONFIG_RTE_CB_NB85E). This support + has only been tested when running with the Multi-debugger monitor + ROM (for the Green Hills Multi debugger). The optional NEC + Solution Gear RTE-MOTHER-A motherboard is also supported, which + allows PCI boards to be used (CONFIG_RTE_MB_A_PCI). + + "rte-me2-cb" + The Midas labs RTE-V850E/ME2-CB evaluation board (CONFIG_RTE_CB_ME2). + This has only been tested using a kernel downloaded via an ICE + connection using the Multi debugger. Support for the RTE-MOTHER-A is + present, but hasn't been tested (unlike the other Midas labs cpu + boards, the RTE-V850E/ME2-CB includes an ethernet adaptor). + + "as85ep1" + The NEC AS85EP1 V850E evaluation chip/board (CONFIG_V850E_AS85EP1). + + "anna" + The NEC `Anna' (board/chip) implementation of the V850E2 processor + (CONFIG_V850E2_ANNA). + + "sim85e2c", "sim85e2s" + The sim85e2c and sim85e2s simulators, which are verilog simulations + of the V850E2 NA85E2C/NA85E2S cpu cores (CONFIG_V850E2_SIM85E2C and + CONFIG_V850E2_SIM85E2S). + + "fpga85e2c" + A FPGA implementation of the V850E2 NA85E2C cpu core + (CONFIG_V850E2_FPGA85E2C). + +To get a default kernel configuration for a particular platform, you can +use a _defconfig make target (e.g., "make rte-me2-cb_defconfig"); +to see which default configurations are possible, look in the directory +"arch/v850/configs". Porting to anything with a V850E/MA1 or MA2 processor should be simple. See the file and the files it includes for an example of diff -ruN -X../cludes
Re: Obsolete files in 2.6 tree
Jiri Slaby wrote: Are these files obsolete and could be deleted from tree. Does anybody use them? Could anybody compile them? [snip] fs/binfmt_flat.c This is not obsolate, it is used by most MMUless architectures as the primary executable file loader. It compiles (and works). Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a CyberGuard CompanyPHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.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: LZF Cryptoapi support.
Howdy.
New revision. Anything left to fix up?
Regards,
Nigel
Kconfig |7 +
Makefile |1
lzf.c| 377 +++
3 files changed, 385 insertions(+)
diff -ruNp 260-crypto-api-lzf-support.patch-old/crypto/Kconfig
260-crypto-api-lzf-support.patch-new/crypto/Kconfig
--- 260-crypto-api-lzf-support.patch-old/crypto/Kconfig 2005-07-18
06:36:39.0 +1000
+++ 260-crypto-api-lzf-support.patch-new/crypto/Kconfig 2005-07-20
08:52:31.0 +1000
@@ -282,6 +282,13 @@ config CRYPTO_DEFLATE
You will most probably want this if using IPSec.
+config CRYPTO_LZF
+ tristate "LZF compression algorithm"
+ depends on CRYPTO
+ help
+ This is the LZF algorithm. It is especially useful for Suspend2,
+ because it achieves good compression quickly.
+
config CRYPTO_MICHAEL_MIC
tristate "Michael MIC keyed digest algorithm"
depends on CRYPTO
diff -ruNp 260-crypto-api-lzf-support.patch-old/crypto/lzf.c
260-crypto-api-lzf-support.patch-new/crypto/lzf.c
--- 260-crypto-api-lzf-support.patch-old/crypto/lzf.c 1970-01-01
10:00:00.0 +1000
+++ 260-crypto-api-lzf-support.patch-new/crypto/lzf.c 2005-07-21
05:10:49.0 +1000
@@ -0,0 +1,377 @@
+/*
+ * Cryptoapi LZF compression module.
+ *
+ * Copyright (c) 2004-2005 Nigel Cunningham <[EMAIL PROTECTED]>
+ *
+ * based on the deflate.c file:
+ *
+ * Copyright (c) 2003 James Morris <[EMAIL PROTECTED]>
+ *
+ * and upon the LZF compression module donated to the Suspend2 project with
+ * the following copyright:
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ * Copyright (c) 2000-2003 Marc Alexander Lehmann <[EMAIL PROTECTED]>
+ *
+ * Redistribution and use in source and binary forms, with or without modifica-
+ * tion, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ * this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * 3. The name of the author may not be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MER-
+ * CHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ * EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPE-
+ * CIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTH-
+ * ERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Alternatively, the contents of this file may be used under the terms of
+ * the GNU General Public License version 2 (the "GPL"), in which case the
+ * provisions of the GPL are applicable instead of the above. If you wish to
+ * allow the use of your version of this file only under the terms of the
+ * GPL and not to allow others to use your version of this file under the
+ * BSD license, indicate your decision by deleting the provisions above and
+ * replace them with the notice and other provisions required by the GPL. If
+ * you do not delete the provisions above, a recipient may use your version
+ * of this file under either the BSD or the GPL.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct lzf_ctx {
+ void *hbuf;
+ char *local_buffer;
+ char *page_buffer;
+ unsigned int bufofs;
+ int first_call;
+};
+
+/*
+ * size of hashtable is (1 << hlog) * sizeof (char *)
+ * decompression is independent of the hash table size
+ * the difference between 15 and 14 is very small
+ * for small blocks (and 14 is also faster).
+ * For a low-memory configuration, use hlog == 13;
+ * For best compression, use 15 or 16.
+ */
+static const int hlog = 14;
+
+/*
+ * don't play with this unless you benchmark!
+ * decompression is not dependent on the hash function
+ * the hashing function might seem strange, just believe me
+ * it works ;)
+ */
+static inline u16 first(const u8 * p)
+{
+ return ((p[0]) << 8) + p[1];
+}
+
+static inline u16 next(u8 v, const u8 * p)
+{
+
2.6.12 PREEMPT_RT && PPC
Ingo, Attached is a patch for 51-28 which brings PPC up to date for 2.6.12 PREEMPT_RT. My goal was to get a more recent vintage of this work building and minimally booting for PPC. Yet this has been stable even under our internal stress tests. We now have this running on 8560 and 8260 PPC targets with a few others in the pipe. Remaining are a few known BUG asserts to address, but as we've historically been chasing seemingly PPC-specific (or perhaps usage-specific) problems in a fairly old code base it seemed high time to move forward. I've also applied the same patch to 51-33 which not being very far from 51-28 did apply clean, builds, boots, and appears equally stable as 51-28. In the process of producing the patch I stumbled across a change introduced in 51-15 where in the case of PREEMPT_RT it appears hw_irq_controller.end() is never being called at the end of do_hardirq(). This appears to be an oversight in the code and the existing PPC openpic code does register a end() handler which it expects to be called in order to terminate the interrupt. Otherwise interrupts at the current level are effectively disabled. There is also what I suspect to be some "leaking" of the __RAW_LOCAL_ILLEGAL_MASK bit out of the local_irq*() API primitives as the *flags argument. This may subsequently be used by non-local_irq*() primitives and wind up unintentionally setting the __RAW_LOCAL_ILLEGAL_MASK bit in the machine control register with unpredictable results. Lastly there is a problem I've yet to isolate in kernel/printk.c:release_console_sem() where the expansion of spin_unlock_irq(_lock) generating a call to __raw_local_irq_enable() will lockup console output on PPC. In the interim this has been reverted to a spin_unlock() call for the case of PREEMPT_RT && PPC. Feedback, comments welcome. -john -- [EMAIL PROTECTED] ./arch/ppc/kernel/entry.S ./arch/ppc/kernel/temp.c ./arch/ppc/kernel/smp.c ./arch/ppc/kernel/dma-mapping.c ./arch/ppc/kernel/process.c ./arch/ppc/kernel/smp-tbsync.c ./arch/ppc/kernel/misc.S ./arch/ppc/kernel/irq.c ./arch/ppc/kernel/idle.c ./arch/ppc/kernel/time.c ./arch/ppc/kernel/traps.c ./arch/ppc/kernel/head_fsl_booke.S ./arch/ppc/mm/fault.c ./arch/ppc/mm/init.c ./arch/ppc/platforms/4xx/xilinx_ml300.c ./arch/ppc/platforms/adir_setup.c ./arch/ppc/platforms/apus_setup.c ./arch/ppc/platforms/chestnut.c ./arch/ppc/platforms/cpci690.c ./arch/ppc/platforms/ev64260.c ./arch/ppc/platforms/gemini_setup.c ./arch/ppc/platforms/hdpu.c ./arch/ppc/platforms/k2.c ./arch/ppc/platforms/lopec.c ./arch/ppc/platforms/mcpn765.c ./arch/ppc/platforms/mvme5100.c ./arch/ppc/platforms/pal4_setup.c ./arch/ppc/platforms/pcore.c ./arch/ppc/platforms/pmac_cpufreq.c ./arch/ppc/platforms/pmac_smp.c ./arch/ppc/platforms/powerpmc250.c ./arch/ppc/platforms/pplus.c ./arch/ppc/platforms/prep_setup.c ./arch/ppc/platforms/prpmc750.c ./arch/ppc/platforms/prpmc800.c ./arch/ppc/platforms/radstone_ppc7d.c ./arch/ppc/platforms/sandpoint.c ./arch/ppc/platforms/spruce.c ./arch/ppc/syslib/ibm440gx_common.c ./arch/ppc/syslib/ibm44x_common.c ./arch/ppc/syslib/m8260_pci_erratum9.c ./arch/ppc/syslib/m8260_setup.c ./arch/ppc/syslib/m8xx_setup.c ./arch/ppc/syslib/mpc52xx_setup.c ./arch/ppc/syslib/ppc4xx_setup.c ./arch/ppc/syslib/ppc83xx_setup.c ./arch/ppc/syslib/ppc85xx_setup.c ./arch/ppc/xmon/xmon.c ./arch/ppc/Kconfig ./drivers/char/blocker.c ./drivers/char/lpptest.c ./include/asm-ppc/thread_info.h ./include/asm-ppc/hw_irq.h ./include/asm-ppc/tlb.h ./include/linux/rt_irq.h ./kernel/irq/manage.c ./kernel/latency.c ./kernel/softirq.c ./kernel/sys.c ./kernel/timer.c ./kernel/printk.c ./lib/Kconfig.debug = --- ./arch/ppc/kernel/entry.S.ORG 2005-07-12 10:19:24.0 -0400 +++ ./arch/ppc/kernel/entry.S 2005-07-12 11:29:26.0 -0400 @@ -237,7 +237,7 @@ ret_from_syscall: SYNC MTMSRD(r10) lwz r9,TI_FLAGS(r12) - andi. r0,r9,(_TIF_SYSCALL_TRACE|_TIF_SIGPENDING|_TIF_NEED_RESCHED) + andi. r0,r9,(_TIF_SYSCALL_TRACE|_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_NEED_RESCHED_DELAYED) bne-syscall_exit_work syscall_exit_cont: #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE) @@ -313,7 +313,7 @@ syscall_exit_work: rlwinm r12,r1,0,0,18 /* current_thread_info() */ lwz r9,TI_FLAGS(r12) 5: - andi. r0,r9,_TIF_NEED_RESCHED + andi. r0,r9,(_TIF_NEED_RESCHED|_TIF_NEED_RESCHED_DELAYED) bne 1f lwz r5,_MSR(r1) andi. r5,r5,MSR_PR @@ -653,7 +653,7 @@ user_exc_return:/* r10 contains MSR_KE /* Check current_thread_info()->flags */ rlwinm r9,r1,0,0,18 lwz r9,TI_FLAGS(r9) - andi. r0,r9,(_TIF_SIGPENDING|_TIF_NEED_RESCHED) + andi. r0,r9,(_TIF_SIGPENDING|_TIF_NEED_RESCHED|_TIF_NEED_RESCHED_DELAYED) bne do_work restore_user: @@ -902,7 +902,7 @@ load_dbcr0: #endif /* !(CONFIG_4xx ||
Re: [PATCH] Convert refrigerator() to try_to_freeze()
Hi. On the testing twice, fair enough. I'll send a new version with the refrigerator changes, as jbd won't need that dirty big if..else then since there's no danger of a deadlock. Regards, Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.12] printk: add sysctl to control printk_time
On Wed, 20 Jul 2005 16:08:35 -0400 (EDT) Mark Whittington wrote: > Added a sysctl (KERN_PRINTK_TIME) and by proxy an entry in > /proc/sys/kernel to enable and disable printk interval information when > CONFIG_PRINTK_TIME is compiled in. 1/ That explains "what." How about "why?" 2/ The patch does not apply cleanly. It looks like some tabs are messed up, but I'm not sure about it. [EMAIL PROTECTED]:linux-2612> patch -p1 -b --dry-run < ~/fixes/printk_time.patch patching file Documentation/sysctl/kernel.txt Hunk #1 FAILED at 39. Hunk #2 FAILED at 261. 2 out of 2 hunks FAILED -- saving rejects to file Documentation/sysctl/kernel.txt.rej patching file include/linux/sysctl.h Hunk #1 FAILED at 136. 1 out of 1 hunk FAILED -- saving rejects to file include/linux/sysctl.h.rej patching file kernel/printk.c Hunk #1 FAILED at 473. 1 out of 1 hunk FAILED -- saving rejects to file kernel/printk.c.rej patching file kernel/sysctl.c Hunk #1 FAILED at 63. Hunk #2 FAILED at 590. 2 out of 2 hunks FAILED -- saving rejects to file kernel/sysctl.c.rej patching file lib/Kconfig.debug Hunk #1 FAILED at 6. 1 out of 1 hunk FAILED -- saving rejects to file lib/Kconfig.debug.rej 3/ The patch should be made against a more recent kernel version, like 2.6.13-rc3 or 2.6.13-rc3-git4. > Signed-off-by: Mark Whittington <[EMAIL PROTECTED]> > > diff -ruN linux-2.6.12/kernel/printk.c linux-2.6.12-work/kernel/printk.c > --- linux-2.6.12/kernel/printk.c 2005-06-17 15:48:29.0 -0400 > +++ linux-2.6.12-work/kernel/printk.c 2005-07-20 15:32:03.0 -0400 > @@ -473,7 +473,8 @@ > } > > #if defined(CONFIG_PRINTK_TIME) > -static int printk_time = 1; > +int printk_time = 1; > +EXPORT_SYMBOL(printk_time); I wouldn't think that the EXPORT_SYMBOL() is needed. That just makes it visible to modules. Not being 'static' should be enough to make it visible to other built-in-kernel files... so, did you try it without the EXPORT_SYMBOL()? > #else > static int printk_time = 0; > #endif > diff -ruN linux-2.6.12/lib/Kconfig.debug linux-2.6.12-work/lib/Kconfig.debug > --- linux-2.6.12/lib/Kconfig.debug2005-06-17 15:48:29.0 -0400 > +++ linux-2.6.12-work/lib/Kconfig.debug 2005-07-20 15:09:07.0 > -0400 > @@ -6,7 +6,9 @@ > included in printk output. This allows you to measure > the interval between kernel operations, including bootup > operations. This is useful for identifying long delays > - in kernel startup. > + in kernel startup. If this option is enabled, you can turn > + off and on the timing information by echoing a 1 or 0 to > + /proc/kernel/sys/printk_time. Those last 2 lines should line up with the lines above them. However, the last 2 lines use only spaces and not tab(s), which is incorrect. Basically, fix your email client and justify the patch. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: IDE PIIX vs libata piix with software raid
>> My question is, what is the recommended driver to use for the PATA >>channel? > >If you're just using hard drives, there should be no problem using >libata for both PATA and SATA. > >However, in general, the IDE driver (CONFIG_IDE) is recommended for PATA. > > Jeff I took Jeff's suggestion and left the (CONFIG_IDE) in the kernel as well as (CONFIG_BLK_DEV_PIIX) (see .config below). When the system comes up, I do indeed have two drives as hda and hdb on ide0 and two drives as sda and sdb. What I cannot resolve is that ide0 is using the Uniform Multi-Platform E-IDE driver and not the piix/ICH driver. It does not identify ide0 as being ICH5-R. I have included the dmesg and lspci below. The kernel version is 2.6.12-rc2-mm3 and I get the same behaviour under 2.6.12. I have tried 2.6.13-rc3 and 2.6.13-rc3-mm1 but both of those reboot the system immediately upon it coming up, but watching the console messages I can see that those kernels use the non-piix driver also. The motherboard is an Intel SE7520BD2 with two PATA drives and 2 SATA drives. On a side note, the second NIC on this motherboard is a Marvell GigE adapter. I could not get it to work with the sk98lin or skge driver in the kernel source, but when I patched the kernel with the driver source from the chipset manufacturer, SysKonnect, it worked fine. That patch is at http://www.syskonnect.de/syskonnect/support/driver/d0102_driver.html. If there is any info I have left out, please let me know. I will have one of these boards available for quite a while to do any testing that anyone needs. Thanks! David Lewis :00:00.0 Host bridge: Intel Corp. E7520 Memory Controller Hub (rev 0c) Subsystem: Intel Corp.: Unknown device 3439 Flags: bus master, fast devsel, latency 0 Capabilities: [40] #09 [4105] :00:00.1 Class ff00: Intel Corp. E7525/E7520 Error Reporting Registers (rev 0c) Subsystem: Intel Corp.: Unknown device 3439 Flags: fast devsel :00:01.0 System peripheral: Intel Corp. E7520 DMA Controller (rev 0c) Subsystem: Intel Corp.: Unknown device 3439 Flags: fast devsel, IRQ 10 Memory at fcdff000 (32-bit, non-prefetchable) Capabilities: [b0] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- :00:02.0 PCI bridge: Intel Corp. E7525/E7520/E7320 PCI Express Port A (rev 0c) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=03, sec-latency=0 Memory behind bridge: fce0-fcef Capabilities: [50] Power Management version 2 Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- Capabilities: [64] #10 [0041] :00:04.0 PCI bridge: Intel Corp. E7525/E7520 PCI Express Port B (rev 0c) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Capabilities: [50] Power Management version 2 Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- Capabilities: [64] #10 [0041] :00:05.0 PCI bridge: Intel Corp. E7520 PCI Express Port B1 (rev 0c) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: fcf0-fcff Expansion ROM at d000 [disabled] [size=4K] Capabilities: [50] Power Management version 2 Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- Capabilities: [64] #10 [0041] :00:06.0 PCI bridge: Intel Corp. E7520 PCI Express Port C (rev 0c) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=06, subordinate=06, sec-latency=0 Capabilities: [50] Power Management version 2 Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- Capabilities: [64] #10 [0041] :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=07, subordinate=07, sec-latency=32 I/O behind bridge: e000-efff Memory behind bridge: fd00-febf Expansion ROM at e000 [disabled] [size=4K] :00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) Flags: bus master, medium devsel, latency 0 :00:1f.2 IDE interface: Intel Corp. 82801EB (ICH5) SATA Controller (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: Intel Corp.: Unknown device 3439 Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 18 I/O ports at I/O ports at I/O ports at I/O ports at I/O ports at fc00 [size=16] :00:1f.3 SMBus: Intel Corp. 82801EB/ER (ICH5/ICH5R) SMBus
[2.6.13 PATCH 3/4] 03-lgdt3302-suppress-compile-warning.patch
Michael Krufky wrote: This patch series spans both video4linux and linux-dvb trees. Remove the dvb_pll_desc from the lgdt3302 frontend and replace with a pll_set-callback to isolate the tuner programming from the frontend. Select the RF input connector based upon the type of demodulation selected. ANT RF connector is selected for 8-VSB and CABLE RF connector is selected for QAM64/QAM256. Implement this along the lines posted to linux-dvb list (subscribers only) by Patrick Boettcher. ( http://linuxtv.org/pipermail/linux-dvb/2005-July/003557.html ) This only affects the cards that use the Microtune 4042 tuner. This is not ideal, but there is no current specification for selecting RF inputs. It makes the card work the same way as the Windows driver thus it may reduce user confusion. Suppress the following during compile: warning: `i2c_readbytes' defined but not used This code will either be re-enabled or deleted in a future patch. Signed-off-by: Michael Krufky <[EMAIL PROTECTED]> lgdt3302.c |2 ++ 1 files changed, 2 insertions(+) diff -u linux-2.6.13/drivers/media/dvb/frontends/lgdt3302.c linux/drivers/media/dvb/frontends/lgdt3302.c --- linux-2.6.13/drivers/media/dvb/frontends/lgdt3302.c 2005-07-20 22:53:42.0 + +++ linux/drivers/media/dvb/frontends/lgdt3302.c2005-07-20 23:01:58.0 + @@ -94,6 +94,7 @@ return 0; } +#if 0 static int i2c_readbytes (struct lgdt3302_state* state, u8 addr, /* demod_address or pll_address */ u8 *buf, /* holds data bytes read */ @@ -109,6 +110,7 @@ } return 0; } +#endif /* * This routine writes the register (reg) to the demod bus
[2.6.13 PATCH 4/4] 04-cx88-dvb-cleanup.patch
Michael Krufky wrote: This patch series spans both video4linux and linux-dvb trees. Remove the dvb_pll_desc from the lgdt3302 frontend and replace with a pll_set-callback to isolate the tuner programming from the frontend. Select the RF input connector based upon the type of demodulation selected. ANT RF connector is selected for 8-VSB and CABLE RF connector is selected for QAM64/QAM256. Implement this along the lines posted to linux-dvb list (subscribers only) by Patrick Boettcher. ( http://linuxtv.org/pipermail/linux-dvb/2005-July/003557.html ) This only affects the cards that use the Microtune 4042 tuner. This is not ideal, but there is no current specification for selecting RF inputs. It makes the card work the same way as the Windows driver thus it may reduce user confusion. Remove unneeded comment. Signed-off-by: Michael Krufky <[EMAIL PROTECTED]> cx88-dvb.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -u linux-2.6.13/drivers/media/video/cx88/cx88-dvb.c linux/drivers/media/video/cx88/cx88-dvb.c --- linux-2.6.13/drivers/media/video/cx88/cx88-dvb.c2005-07-20 22:53:42.0 + +++ linux/drivers/media/video/cx88/cx88-dvb.c 2005-07-20 23:01:58.0 + @@ -1,5 +1,5 @@ /* - * $Id: cx88-dvb.c,v 1.48 2005/07/20 05:33:33 mkrufky Exp $ + * $Id: cx88-dvb.c,v 1.49 2005/07/20 05:38:09 mkrufky Exp $ * * device driver for Conexant 2388x based TV cards * MPEG Transport Stream (DVB) routines @@ -328,7 +328,7 @@ cx_clear(MO_GP0_IO, 1); mdelay(100); - cx_set(MO_GP0_IO, 9); /* ANT connector too FIXME */ + cx_set(MO_GP0_IO, 9); mdelay(200); dev->core->pll_addr = 0x61; dev->core->pll_desc = _pll_thomson_dtt7611;
[2.6.13 PATCH 2/4] 02-lgdt3302-rf-input.patch
Michael Krufky wrote:
This patch series spans both video4linux and linux-dvb trees.
Remove the dvb_pll_desc from the lgdt3302 frontend and replace with a
pll_set-callback to isolate the tuner programming from the frontend.
Select the RF input connector based upon the type of demodulation
selected. ANT RF connector is selected for 8-VSB and CABLE RF
connector is selected for QAM64/QAM256. Implement this along the lines
posted to linux-dvb list (subscribers only) by Patrick Boettcher. (
http://linuxtv.org/pipermail/linux-dvb/2005-July/003557.html ) This
only affects the cards that use the Microtune 4042 tuner. This is not
ideal, but there is no current specification for selecting RF inputs.
It makes the card work the same way as the Windows driver thus it may
reduce user confusion.
Select the RF input connector based upon the type of
demodulation selected. ANT RF connector is selected for
8-VSB and CABLE RF connector is selected for QAM64/QAM256.
This only affects the cards that use the Microtune 4042 tuner.
Signed-off-by: Mac Michaels <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
linux/drivers/media/dvb/frontends/lgdt3302.c | 12 +++
linux/drivers/media/dvb/frontends/lgdt3302.h |1
linux/drivers/media/video/cx88/cx88-dvb.c| 20 +--
3 files changed, 31 insertions(+), 2 deletions(-)
diff -u linux-2.6.13/drivers/media/dvb/frontends/lgdt3302.c
linux/drivers/media/dvb/frontends/lgdt3302.c
--- linux-2.6.13/drivers/media/dvb/frontends/lgdt3302.c 2005-07-20
22:50:39.0 +
+++ linux/drivers/media/dvb/frontends/lgdt3302.c2005-07-20
22:53:29.0 +
@@ -214,6 +214,10 @@
/* Select VSB mode and serial MPEG interface */
top_ctrl_cfg[1] = 0x07;
+
+ /* Select ANT connector if supported by card */
+ if (state->config->pll_rf_set)
+ state->config->pll_rf_set(fe, 1);
break;
case QAM_64:
@@ -221,6 +225,10 @@
/* Select QAM_64 mode and serial MPEG interface */
top_ctrl_cfg[1] = 0x04;
+
+ /* Select CABLE connector if supported by card */
+ if (state->config->pll_rf_set)
+ state->config->pll_rf_set(fe, 0);
break;
case QAM_256:
@@ -228,6 +236,10 @@
/* Select QAM_256 mode and serial MPEG interface */
top_ctrl_cfg[1] = 0x05;
+
+ /* Select CABLE connector if supported by card */
+ if (state->config->pll_rf_set)
+ state->config->pll_rf_set(fe, 0);
break;
default:
printk(KERN_WARNING "lgdt3302: %s: Modulation type(%d)
UNSUPPORTED\n", __FUNCTION__, param->u.vsb.modulation);
diff -u linux-2.6.13/drivers/media/dvb/frontends/lgdt3302.h
linux/drivers/media/dvb/frontends/lgdt3302.h
--- linux-2.6.13/drivers/media/dvb/frontends/lgdt3302.h 2005-07-20
22:50:39.0 +
+++ linux/drivers/media/dvb/frontends/lgdt3302.h2005-07-20
22:53:29.0 +
@@ -30,6 +30,7 @@
u8 demod_address;
/* PLL interface */
+ int (*pll_rf_set) (struct dvb_frontend* fe, int index);
int (*pll_set)(struct dvb_frontend* fe, struct dvb_frontend_parameters*
params, u8* pll_address);
/* Need to set device param for start_dma */
diff -u linux-2.6.13/drivers/media/video/cx88/cx88-dvb.c
linux/drivers/media/video/cx88/cx88-dvb.c
--- linux-2.6.13/drivers/media/video/cx88/cx88-dvb.c2005-07-20
22:50:39.0 +
+++ linux/drivers/media/video/cx88/cx88-dvb.c 2005-07-20 22:53:29.0
+
@@ -1,5 +1,5 @@
/*
- * $Id: cx88-dvb.c,v 1.47 2005/07/20 05:20:37 mkrufky Exp $
+ * $Id: cx88-dvb.c,v 1.48 2005/07/20 05:33:33 mkrufky Exp $
*
* device driver for Conexant 2388x based TV cards
* MPEG Transport Stream (DVB) routines
@@ -223,6 +223,19 @@
return 0;
}
+static int lgdt3302_pll_rf_set(struct dvb_frontend* fe, int index)
+{
+ struct cx8802_dev *dev= fe->dvb->priv;
+ struct cx88_core *core = dev->core;
+
+ dprintk(1, "%s: index = %d\n", __FUNCTION__, index);
+ if (index == 0)
+ cx_clear(MO_GP0_IO, 8);
+ else
+ cx_set(MO_GP0_IO, 8);
+ return 0;
+}
+
static int lgdt3302_set_ts_param(struct dvb_frontend* fe, int is_punctured)
{
struct cx8802_dev *dev= fe->dvb->priv;
@@ -296,8 +309,11 @@
cx_clear(MO_GP0_IO, 1);
mdelay(100);
- cx_set(MO_GP0_IO, 9); // ANT connector too FIXME
+ cx_set(MO_GP0_IO, 1);
mdelay(200);
+
+ /* Select RF connector callback */
+ fusionhdtv_3_gold.pll_rf_set =
[2.6.13 PATCH 1/4] 01-lgdt3302-isolate-tuner.patch
Michael Krufky wrote:
This patch series spans both video4linux and linux-dvb trees.
Remove the dvb_pll_desc from the lgdt3302 frontend and replace with a
pll_set-callback to isolate the tuner programming from the frontend.
Select the RF input connector based upon the type of demodulation
selected. ANT RF connector is selected for 8-VSB and CABLE RF
connector is selected for QAM64/QAM256. Implement this along the lines
posted to linux-dvb list (subscribers only) by Patrick Boettcher. (
http://linuxtv.org/pipermail/linux-dvb/2005-July/003557.html ) This
only affects the cards that use the Microtune 4042 tuner. This is not
ideal, but there is no current specification for selecting RF inputs.
It makes the card work the same way as the Windows driver thus it may
reduce user confusion.
Remove the dvb_pll_desc from the frontend and replace with a
pll_set-callback to isolate the tuner programming from the frontend.
Signed-off-by: Mac Michaels <[EMAIL PROTECTED]>
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
linux/drivers/media/dvb/frontends/lgdt3302.c | 68 ---
linux/drivers/media/dvb/frontends/lgdt3302.h |7 -
linux/drivers/media/video/cx88/cx88-dvb.c| 34 +
3 files changed, 55 insertions(+), 54 deletions(-)
diff -u linux-2.6.13/drivers/media/dvb/frontends/lgdt3302.c
linux/drivers/media/dvb/frontends/lgdt3302.c
--- linux-2.6.13/drivers/media/dvb/frontends/lgdt3302.c 2005-07-20
22:29:42.0 +
+++ linux/drivers/media/dvb/frontends/lgdt3302.c2005-07-20
22:44:44.0 +
@@ -74,11 +74,14 @@
u8 *buf, /* data bytes to send */
int len /* number of bytes to send */ )
{
- if (addr == state->config->pll_address) {
- struct i2c_msg msg =
- { .addr = addr, .flags = 0, .buf = buf, .len = len };
- int err;
+ u8 tmp[] = { buf[0], buf[1] };
+ struct i2c_msg msg =
+ { .addr = addr, .flags = 0, .buf = tmp, .len = 2 };
+ int err;
+ int i;
+ for (i=1; ii2c, , 1)) != 1) {
printk(KERN_WARNING "lgdt3302: %s error (addr %02x <-
%02x, err == %i)\n", __FUNCTION__, addr, buf[0], err);
if (err < 0)
@@ -86,27 +89,11 @@
else
return -EREMOTEIO;
}
- } else {
- u8 tmp[] = { buf[0], buf[1] };
- struct i2c_msg msg =
- { .addr = addr, .flags = 0, .buf = tmp, .len = 2 };
- int err;
- int i;
-
- for (i=1; ii2c, , 1)) != 1) {
- printk(KERN_WARNING "lgdt3302: %s error (addr
%02x <- %02x, err == %i)\n", __FUNCTION__, addr, buf[0], err);
- if (err < 0)
- return err;
- else
- return -EREMOTEIO;
- }
- tmp[0]++;
- }
+ tmp[0]++;
}
return 0;
}
+
static int i2c_readbytes (struct lgdt3302_state* state,
u8 addr, /* demod_address or pll_address */
u8 *buf, /* holds data bytes read */
@@ -207,7 +194,6 @@
static int lgdt3302_set_parameters(struct dvb_frontend* fe,
struct dvb_frontend_parameters *param)
{
- u8 buf[4];
struct lgdt3302_state* state =
(struct lgdt3302_state*) fe->demodulator_priv;
@@ -290,16 +276,30 @@
/* Change only if we are actually changing the channel */
if (state->current_frequency != param->frequency) {
- dvb_pll_configure(state->config->pll_desc, buf,
- param->frequency, 0);
- dprintk("%s: tuner bytes: 0x%02x 0x%02x "
- "0x%02x 0x%02x\n", __FUNCTION__,
buf[0],buf[1],buf[2],buf[3]);
- i2c_writebytes(state, state->config->pll_address ,buf, 4);
+ u8 buf[5];
- /* Check the status of the tuner pll */
- i2c_readbytes(state, state->config->pll_address, buf, 1);
- dprintk("%s: tuner status byte = 0x%02x\n", __FUNCTION__,
buf[0]);
+ /* This must be done before the initialized msg is declared */
+ state->config->pll_set(fe, param, buf);
+ struct i2c_msg msg =
+ { .addr = buf[0], .flags = 0, .buf = [1], .len = 4
};
+ int err;
+
+ dprintk("%s: tuner at 0x%02x bytes: 0x%02x 0x%02x "
+ "0x%02x 0x%02x\n", __FUNCTION__,
+ buf[0],buf[1],buf[2],buf[3],buf[4]);
+ if ((err = i2c_transfer(state->i2c, , 1)) != 1) {
+ printk(KERN_WARNING "lgdt3302: %s error (addr %02x <-
%02x, err = %i)\n",
[2.6.13 PATCH 0/4]
This patch series spans both video4linux and linux-dvb trees. Remove the dvb_pll_desc from the lgdt3302 frontend and replace with a pll_set-callback to isolate the tuner programming from the frontend. Select the RF input connector based upon the type of demodulation selected. ANT RF connector is selected for 8-VSB and CABLE RF connector is selected for QAM64/QAM256. Implement this along the lines posted to linux-dvb list (subscribers only) by Patrick Boettcher. ( http://linuxtv.org/pipermail/linux-dvb/2005-July/003557.html ) This only affects the cards that use the Microtune 4042 tuner. This is not ideal, but there is no current specification for selecting RF inputs. It makes the card work the same way as the Windows driver thus it may reduce user confusion. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.13 PATCH] v4l: fix regression modprobe bttv freezes the computer
Johannes Stezenbach wrote: Graeme Christie wrote: It seems to me as if this bug has resurfaced again. It probably got lost because it was applied to the kernel which v4l was maintainer- and CVS-less. http://groups-beta.google.com/group/linux.kernel/msg/6a27dd3dc46a5b5b?dmode=source=en It would be cool if you could apply this patch to v4l CVS and send it to akpm for inclusion into 2.6.13 (hopefully), as the "hang at boot" issue is quite nasty. Fix Bug 4395: modprobe bttv freezes the computer http://bugme.osdl.org/show_bug.cgi?id=4395. (link is dead now) Date: Wed, 13 Apr 2005 03:20:08 Patch by Manu Abraham and Gerd Knorr: Remove redundant bttv_reset_audio() which caused the computer to freeze with some bt8xx based DVB cards when loading the bttv driver. Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Michael Krufky <[EMAIL PROTECTED]> linux/drivers/media/video/bttv-cards.c |4 +--- 1 files changed, 1 insertion(+), 3 deletions(-) diff -u linux-2.6.13-rc3-git3/drivers/media/video/bttv-cards.c linux/drivers/media/video/bttv-cards.c --- linux-2.6.13-rc3-git3/drivers/media/video/bttv-cards.c 2005-07-16 15:25:34.0 + +++ linux/drivers/media/video/bttv-cards.c 2005-07-20 22:00:26.0 + @@ -1,5 +1,5 @@ /* -$Id: bttv-cards.c,v 1.53 2005/07/05 17:37:35 nsh Exp $ +$Id: bttv-cards.c,v 1.54 2005/07/19 18:26:46 mkrufky Exp $ bttv-cards.c @@ -2772,8 +2772,6 @@ } btv->pll.pll_current = -1; - bttv_reset_audio(btv); - /* tuner configuration (from card list / autodetect / insmod option) */ if (UNSET != bttv_tvcards[btv->c.type].tuner_type) if(UNSET == btv->tuner_type)
[PATCH] kill bio->bi_set
Hi,
Dunno why I didn't notice before, but ->bi_set is totally unnecessary
bloat of struct bio. Just define a proper destructor for the bio and it
already knows what bio_set it belongs too.
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
diff --git a/drivers/md/dm-io.c b/drivers/md/dm-io.c
--- a/drivers/md/dm-io.c
+++ b/drivers/md/dm-io.c
@@ -239,6 +239,11 @@ static void vm_dp_init(struct dpages *dp
dp->context_ptr = data;
}
+static void dm_bio_destructor(struct bio *bio)
+{
+ bio_free(bio, _bios);
+}
+
/*-
* IO routines that accept a list of pages.
*---*/
@@ -263,6 +268,7 @@ static void do_region(int rw, unsigned i
bio->bi_bdev = where->bdev;
bio->bi_end_io = endio;
bio->bi_private = io;
+ bio->bi_destructor = dm_bio_destructor;
bio_set_region(bio, region);
/*
diff --git a/fs/bio.c b/fs/bio.c
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -104,18 +104,22 @@ static inline struct bio_vec *bvec_alloc
return bvl;
}
-/*
- * default destructor for a bio allocated with bio_alloc_bioset()
- */
-static void bio_destructor(struct bio *bio)
+void bio_free(struct bio *bio, struct bio_set *bio_set)
{
const int pool_idx = BIO_POOL_IDX(bio);
- struct bio_set *bs = bio->bi_set;
BIO_BUG_ON(pool_idx >= BIOVEC_NR_POOLS);
- mempool_free(bio->bi_io_vec, bs->bvec_pools[pool_idx]);
- mempool_free(bio, bs->bio_pool);
+ mempool_free(bio->bi_io_vec, fs_bio_set->bvec_pools[pool_idx]);
+ mempool_free(bio, fs_bio_set->bio_pool);
+}
+
+/*
+ * default destructor for a bio allocated with bio_alloc_bioset()
+ */
+static void bio_fs_destructor(struct bio *bio)
+{
+ bio_free(bio, fs_bio_set);
}
inline void bio_init(struct bio *bio)
@@ -171,8 +175,6 @@ struct bio *bio_alloc_bioset(unsigned in
bio->bi_max_vecs = bvec_slabs[idx].nr_vecs;
}
bio->bi_io_vec = bvl;
- bio->bi_destructor = bio_destructor;
- bio->bi_set = bs;
}
out:
return bio;
@@ -180,7 +182,12 @@ out:
struct bio *bio_alloc(unsigned int __nocast gfp_mask, int nr_iovecs)
{
- return bio_alloc_bioset(gfp_mask, nr_iovecs, fs_bio_set);
+ struct bio *bio = bio_alloc_bioset(gfp_mask, nr_iovecs, fs_bio_set);
+
+ if (bio)
+ bio->bi_destructor = bio_fs_destructor;
+
+ return bio;
}
void zero_fill_bio(struct bio *bio)
@@ -1078,6 +1085,7 @@ subsys_initcall(init_bio);
EXPORT_SYMBOL(bio_alloc);
EXPORT_SYMBOL(bio_put);
+EXPORT_SYMBOL(bio_free);
EXPORT_SYMBOL(bio_endio);
EXPORT_SYMBOL(bio_init);
EXPORT_SYMBOL(__bio_clone);
diff --git a/include/linux/bio.h b/include/linux/bio.h
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -111,7 +111,6 @@ struct bio {
void*bi_private;
bio_destructor_t*bi_destructor; /* destructor */
- struct bio_set *bi_set;/* memory pools set */
};
/*
@@ -280,6 +279,7 @@ extern void bioset_free(struct bio_set *
extern struct bio *bio_alloc(unsigned int __nocast, int);
extern struct bio *bio_alloc_bioset(unsigned int __nocast, int, struct bio_set
*);
extern void bio_put(struct bio *);
+extern void bio_free(struct bio *, struct bio_set *);
extern void bio_endio(struct bio *, unsigned int, int);
struct request_queue;
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Obsolete files in 2.6 tree
Jiri Slaby wrote: > Are these files obsolete and could be deleted from tree. > Does anybody use them? Could anybody compile them? > > (...) > drivers/scsi/NCR5380.c > drivers/scsi/NCR5380.h > (...) The above are used by (at least) the PAS16 SCSI driver. The PAS16 is a 16-bit ISA soundcard that, in its "studio" incarnation, has a slow- speed (intended for the CD-ROM drives of the time) SCSI interface based on the NCR 5380. As I recall, the Linux driver operated in polled mode only: no interrupt handling capability. That deficiency was never corrected while I was a user of that card, and I quit using the card somewhere in the 2.2 kernel version timeframe. -- --- Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org [EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sharp Zaurus sl-5500 broken in 2.6.12
On Wed, July 20, 2005 12:57 pm, Pavel Machek said: > BTW is there some place where I can find modifications Sharp did to > mainline 2.4 kernel? First, sharp's modifications were not to the base 2.4 kernels, but you first applied the rmk patch and then the pxa patch. I have tried to split up the huge patch http://www.cs.wisc.edu/~lenz/zaurus/files/slc860-patches.tar.bz2 But the original patch is hosted around here somewhere. To find where, take a look inside the .bb file inside OE... you should be able to check out openembedded (from www.openembedded.org) and find the .bb file that builds the kernel. John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel guide to space
Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 7/11/05, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> [snip]
> > 3e. sizeof
> > space after the operator
> > sizeof a
> I don't think that's a hard rule, there's plenty of code that does
> "sizeof(type)" and not "sizeof (type)", and whitespace cleanup
> patches I've done that change "sizeof (type)" into "sizeof(type)" have
> generally been accepted.
It is necessary /not/ to put space between "function name" and '(', because
if it is a function-like macro, it does matter. For uniformity, do it for
functions and operations like sizeof too.
> [snip]
> >
> > 4. Indentation rules for C
> > Use tabs, not spaces, for indentation. Tabs should be 8 characters
> > wide.
> A tab is a tab is a tab, how it's displayed is up to the editor
> showing the file.
But editing a file with tab==4 and editing it later with tab==8 guarantees
a mess.
[...]
> > 6. One-line statement does not need a {} block, so dont put it into one
> > if (foo)
> > bar;
> Not always so, if `bar' is a macro adding {} may be safer.
Such macros are /very/ dangerous. That's one reason why multi-line macros
must be wrapped in "do { ... } while(0)"
>Also
> sometimes adding {} improves readability, which is important.
Or leaves an old C hand wondering what is going on...
> > 7. Comments
> > Dont use C99 // comments.
> >
>
> s/Dont/Don't/
>
>
> > 9a. Integer types
> > int is the default integer type.
> > Use unsigned type if you perform bit operations (<<,>>,&,|,~).
> > Use unsigned long if you have to fit a pointer into integer.
> > long long is at least 64 bit wide on all platforms.
> > char is for ASCII characters and strings.
> > Use u8,u16,u32,u64 if you need an integer of a specific size.
>
> u8,s8,u16,s16,u32,s32,u64,s64
Plus annotations for bitwise and such. See Documentation/sparse.txt
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, ChileFax: +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Preserve hibenate-system-image on startup
Hi. On Wed, 2005-07-20 at 20:54, Hiroyuki Machida wrote: > Hi, > > > With this function, system needs to mount read-write file systems on > every boot cycle, due to avoid inconsistency between FS and memory. > How did you address this problem? Did kernel check RW FS remained as > mounted on boot up or hibernate time ? You're right. We don't seek to address this problem, just document clearly that filesystems in use when creating the image need to be mounted readonly. You can of course mount another filesystem read/write while the system is up. > I think I need to discuss with you at San Jose at the beginning of > this year. Yes, I think we did meet. Nice to talk to you again. Regards, Nigel > > Regards, > Hiroyuki Machida > > Nigel Cunningham wrote: > > Hi. > > > > We've had this feature in Suspend2 for a couple of years and I can > > confirm that the approach works, provided that the on-disk filesystem > > remains unchanged throughout this. (Useful mainly for kiosks etc). > > > > This is not to say that I've reviewed the code below for correctness. > > > > Regards, > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm1 (ckrm)
Well said, Mark. Thanks. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 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/
kdb v4.4 supports OHCI keyboard in 2.6
The 2.6.13-rc3 version of KDB (Linux Kernel Debugger) supports a USB keyboard (CONFIG_KDB_USB). At the moment it only supports the OHCI interface, this is what SGI hardware uses. If anybody has hardware that uses the UHCI interface for the keyboard and can create a kdb patch, that patch will be gratefully accepted. ftp://oss.sgi.com/projects/kdb/download/v4.4/ ftp://ftp.ocs.com.au/pub/mirrors/oss.sgi.com/projects/kdb/download/v4.4/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: amd64-agp vs. swsusp
Rafael J. Wysocki wrote: On Thursday, 21 of July 2005 00:07, Michal Schmidt wrote: I also tried putting a printk before restore_processor_state(), but I'm not sure if it is safe to use printk there. Yes, it is, but you may be unable to see the message if the box reboots before it can be displayed. OK, but then I also tried putting a 5s long busy wait there and the reset was not delayed. Therefore, the reset must be occurring before restore_processor_state(). Or is there a reason why for(i=0; i<5000; i++) udelay(1000); wouldn't work as expected? Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel guide to space
Jan wrote: > (Find source files, expand tab chars to their on-screen length, print if > >= 80, count lines) The bulk of the longest lines are in the sound and drivers subtrees. One example on the "high end", with 546 chars in one line: == drivers/scsi/BusLogic.c: %2d%5d %5d %5d%5d %5d %5d%5d %5d %5d\n", TargetID, TargetStatistics[TargetID].CommandAbortsRequested, TargetStatistics[TargetID].CommandAbortsAttempted, TargetStatistics[TargetID].CommandAbortsCompleted, TargetStatistics[TargetID].BusDeviceResetsRequested, TargetStatistics[TargetID].BusDeviceResetsAttempted, TargetStatistics[TargetID].BusDeviceResetsCompleted, TargetStatistics[TargetID].HostAdapterResetsRequested, TargetStatistics[TargetID].HostAdapterResetsAttempted, TargetStatistics[TargetID].HostAdapterResetsCompleted); == Clearly, it would be unrepresentative of certain coding styles in drivers and sound to claim they closely followed an 80 column constraint. Perhaps the spacing guide should acknowledge this, with some qualification such as: The core kernel code (as apposed to some driver code) tends to keep source line lengths below 80 columns. When changing such code, respect the line length constraints of nearby code. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 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] Re: relayfs documentation sucks?
Bert wrote: > the diskstat tools require relayfs That way might lay the real value of relayfs, as a common technology basis for specific tools that are developed and maintained on top of relayfs. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 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] Remove Comtrol mail address from MAINTAINERS [next 1 address]
Rolf Eike Beer wrotes: Send a patch, you know the addresses. kernel 2.6.13-rc3-git4 Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]> --- a/MAINTAINERS 2005-07-21 01:13:32.0 +0200 +++ b/MAINTAINERS 2005-07-21 01:17:41.0 +0200 @@ -204,8 +204,6 @@ ADVANSYS SCSI DRIVER P: Bob Frey -M: [EMAIL PROTECTED] -W: http://www.advansys.com/linux.html L: linux-scsi@vger.kernel.org S: Maintained - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: amd64-agp vs. swsusp
On Thursday, 21 of July 2005 00:07, Michal Schmidt wrote: > Rafael J. Wysocki wrote: > > On Tuesday, 19 of July 2005 23:26, Michal Schmidt wrote: > >>I have rebuilt agpgart and amd64-agp into the kernel and now it has > >>resumed successfully for the first time. Thank you for the hint! > >> > >>But I still wonder, why that makes a difference. > > > > > > Before resume the module is not present. When it gets loaded from the > > image it probably runs with the assumption that the hardware was initialized > > which is not correct. > > It seems that the module doesn't even get a chance to run after resume. > I've put some printks and udelays into kernel/power/swsusp.c and other > places and I've found that the spontaneous reset occurs already in > swsusp_arch_resume(), ie. before the drivers get their resume methods > called. This is what I have in swsusp_suspend() now: > ... > save_processor_state(); > if ((error = swsusp_arch_suspend())) > printk(KERN_ERR "Error %d suspending\n", error); > /* Restore control flow magically appears here */ > restore_processor_state(); > printk(KERN_INFO "processor state restored!\n");/*I added this*/ > BUG_ON (nr_copy_pages_check != nr_copy_pages); > restore_highmem(); > device_power_up(); > ... > > I'm recording the screen during resuming with a digital camera to see if > the added printk is displayed before the reset and I am now sure that > the reset occurs before that. The last thing I see is: > > Stopping tasks: --| > Freeing memory... done (0 pages freed) > swsusp: Need to copy 8121 pages Please note that printk() only places the string in a buffer and it does not get actually printed before it can be displayed which is probably after your screen is set up (including the AGP resume, I'd guess). :-) You may be able to get more from eg. the serial console, but this requires some tampering with the serial code, AFAIR. > Then on the next frame of the recorded MPEG, the display is already > beginning to dim as the computer is resetting. > > I also tried putting a printk before restore_processor_state(), but I'm > not sure if it is safe to use printk there. Yes, it is, but you may be unable to see the message if the box reboots before it can be displayed. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel oops with x64_86 crossing 4Gb boundary
Hi,
I am getting pseudo-random kernel oops on my Opteron box (Tyan Thunder
K8W) with 4Gb RAM. I am running RedHad FC3 with kernel
2.6.11-1.35_FC3smp.
It runs well with default BIOS settings, but only 3.5Gb RAM are visible.
Using the "Software Memory Hole" option in the BIOS (version 3.02)
remaps the last 2Gb to 4-6Gb. This causes kernel oops with various
applications, generally killing them.
I can reproduce it by loading lots of data into R (which caused the oops
below). Various other applications have caused it too.
Oops: [1] SMP
CPU 1
Modules linked in: nfs lockd parport_pc lp parport autofs4 sunrpc pcmcia
yenta_socket rsrc_nonstatic pcmcia_core dm_mod video button battery ac
nvidia(U) md5 ipv6 ohci1394 ieee1394 ohci_hcd uhci_hcd ehci_hcd
i2c_amd8111 i2c_core hw_random sata_sil libata scsi_mod snd_intel8x0
snd_ca0106 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer
snd soundcore snd_page_alloc e1000 floppy ext3 jbd
Pid: 5288, comm: R Tainted: P 2.6.11-1.35_FC3smp
RIP: 0010:[] {pte_alloc_map+170}
RSP: :8101553f5db8 EFLAGS: 00010293
RAX: 7fff RBX: 2aaad0c0 RCX:
RDX: 810107c95000 RSI: 8100f800 RDI: 8100f000
RBP: 81012d20a430 R08: R09:
R10: 0007f71c R11: R12:
R13: 810173270040 R14: 8101732700b8 R15: 81012d20a430
FS: 2ae6b900() GS:804dd680()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 2730 CR3: 000156775000 CR4: 06e0
Process R (pid: 5288, threadinfo 8101553f4000, task
8101559f3810)
Stack: 8101567752a8 2aaad0c0 810159fe9a68
810173270040
0001 8016ed05
8101732700b8
81015a033a80 2d975000
Call Trace:{handle_mm_fault+293}
{do_page_fault+1172}
{autoremove_wake_function+0}
{dnotify_parent+46}
{vfs_read+268} {error_exit+0}
Code: 48 8b b1 30 27 00 00 76 0d b8 00 00 00 80 eb 10 66 66 90 66
RIP {pte_alloc_map+170} RSP
CR2: 2730
Please tell me if more information is necessary.
Francois
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
HELP: NFS mount hangs when attempting to copy file
My research suggests that NFS client mounting is kernel-based, so that's why I'm posting here. If there's a more appropriate list to post to, I apologise, but I am not a list member. I'm having a bit of a problem doing simple copies over an NFS mount. The client is running Linux (2.6.11), and the server is running Solaris (5.8). When I first boot the client, getting NFS directory listings works just fine. But the instant I try to copy a file (to or from), the NFS mount hangs. While I can still do other network activity (even rlogin to the server), any NFS access I try to do after that point hangs, including directory listings. I have had this same client and server working flawlessly for years. The only change is that the client is now on a VPN (Watchguard SOHO box). However, I have a Sun machine on the same VPN network segment, and it can copy files with no problem, so it's not the router/SOHO that's blocking anything. (NIS and DNS also work just fine for both machines.) Also, after it hangs like that, I cannot reboot the machine normally. When attempting to unmount the network filesystems, the shutdown hangs, and I have to hard-reset the machine. Is there anyone who could please help me to debug this problem? As far as I know, I have NFS setup properly, but I don't know enough about it to know what options I might try. I don't even care if the fix degrades performance; I just want it to not hang. Does anyone have any ideas? Thanks very much in advance! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: amd64 Interbench Results
If these are reasonable numbers, is there any methods available to improve the responsiveness of X? I find I can't get smooth drawing, both scrolling text (in konsole) and dragging windows around, yields "skips" where the drawing isn't fluid. Secondly, what are the suggested settings for preempt in the ck kernel configuration? Thanks for your time. -- Gabriel Devenyi [EMAIL PROTECTED] On July 20, 2005 00:42, Con Kolivas wrote: > On Wed, 20 Jul 2005 12:46 pm, Gabriel Devenyi wrote: > > I've been using the the -ck patchset for a very long time, and I recently > > switched to a amd64 arch. I found that while my throughput improved, my > > system responsiveness has "felt" much lower than it did on my old x86 > > machine. > > > > Now that interbench is around, I have some quantitative results. Attached > > is my interbench results with *nothing* running other than agetty and a > > single bash console. My system is an AMD Athlon(tm) 64 Processor 3200+, > > with 1gig DDR400 RAM. Also attached is my kernel config. > > > > Seems to me there are some pretty high latencies for such a powerful > > system, is there anything I can do to improve this? Thanks for all your > > help. > > Those results don't look too bad to me. Absolute numbers don't mean much in > their own right unless you compare them to something else. Try a vanilla > kernel and then compare the results side by side. > > Cheers, > Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel guide to space
Jesper Juhl <[EMAIL PROTECTED]> writes: > I don't think that's a hard rule, there's plenty of code that does > "sizeof(type)" and not "sizeof (type)", and whitespace cleanup > patches I've done that change "sizeof (type)" into "sizeof(type)" have > generally been accepted. Sure, the common rule is that function names and alike (including "sizeof") are not followed by a space. Statements such as "if", "while" etc. - are. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
USB Wireless IntelliMouse Explorer 2.0 ON LINUX
Hi list, I have the Wireless IntelliMouse Explorer USB In my linux , and when I try to configure (mouseconf , USB mouse) the mouse on the X dont work properly, when I move the mouse , the cursor only go to up and down. Anyone can help me to make my mouse work good ? My distro is Slack 10.1 Kernel 2.4.31 if makes diference Sorry for english BYE ! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: amd64-agp vs. swsusp
Rafael J. Wysocki wrote: On Tuesday, 19 of July 2005 23:26, Michal Schmidt wrote: I have rebuilt agpgart and amd64-agp into the kernel and now it has resumed successfully for the first time. Thank you for the hint! But I still wonder, why that makes a difference. Before resume the module is not present. When it gets loaded from the image it probably runs with the assumption that the hardware was initialized which is not correct. It seems that the module doesn't even get a chance to run after resume. I've put some printks and udelays into kernel/power/swsusp.c and other places and I've found that the spontaneous reset occurs already in swsusp_arch_resume(), ie. before the drivers get their resume methods called. This is what I have in swsusp_suspend() now: ... save_processor_state(); if ((error = swsusp_arch_suspend())) printk(KERN_ERR "Error %d suspending\n", error); /* Restore control flow magically appears here */ restore_processor_state(); printk(KERN_INFO "processor state restored!\n");/*I added this*/ BUG_ON (nr_copy_pages_check != nr_copy_pages); restore_highmem(); device_power_up(); ... I'm recording the screen during resuming with a digital camera to see if the added printk is displayed before the reset and I am now sure that the reset occurs before that. The last thing I see is: Stopping tasks: --| Freeing memory... done (0 pages freed) swsusp: Need to copy 8121 pages Then on the next frame of the recorded MPEG, the display is already beginning to dim as the computer is resetting. I also tried putting a printk before restore_processor_state(), but I'm not sure if it is safe to use printk there. So I tried putting a loop of 5000 x udelay(1000) there to see if the reset would be delayed by 5s. It was not delayed, so I think that the reset occurs before restore_processor_state(). Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] I2C: Separate non-i2c hwmon drivers from i2c-core (2/9)
Hi Greg,
> > Convert i2c-isa from a dumb i2c_adapter into a pseudo i2c-core for
> > ISA hardware monitoring drivers. The isa i2c_adapter is no more
> > registered with i2c-core, drivers have to explicitely connect to it
> > using the new i2c_isa_{add,del}_driver interface.
>
> Ick, when I did this originally it was a hack, and it's still a hack.
> It's sad to see it spreading around, but that's proably my fault...
I didn't know that, I'm sorry. As I don't really know how the driver
core works, I just copied from the nearest working driver, which
happened to be i2c-core. If this isn't good and you want me to do it
differently, just tell me how and I'll tackle this. Actually it might be
more important for i2c-core than i2c-isa, as i2c-isa will die in the
long run.
> Anyway, what are your plans for after this? How long will this code
> stay around? What do you want to do next?
>
> I don't have any real objections to this patch series at all, just
> very curious as to your proposed roadmap after this.
I'm sorry, I thought I had explained it in the first post of the set,
but now I realize that I explained in detail *what* I am doing, not
*why* nor the whole picture.
The whole point is to end with the current state where i2c and hardware
monitoring are the same subsystem. There are more and more non-i2c
hardware monitoring chip, in particular Super-I/O integrated sensors
(IT8712F, W83627HF, PC87366 and all their variants), which have a very
high overhead currently due to being linked to the i2c core for no
reason but historical.
The positive side effect is that there are a few ugly hooks in the
i2c-core (expecially the sensors part) to handle the non-i2c chips, and
we will be able to get rid of them and clean up a few things - as
details in my original post.
The reason why I am going into this now is that a totally different
hardware monitoring driver is in the process of being added to the Linux
kernel: bmcsensors, which is IPMI based. This would be yet another
driver articifially linked to the i2c subsystem, requiring yet other
hooks. So I wanted to clean up the mess first.
Another reason is that I now have a Super-I/O chip with integrated
sensors on one of my systems, as well as a legacy ISA hardware
monitoring chip on another one, so I should be able to test my changes
more efficiently than before in that field (although more hardware would
be even better, as usual).
The major steps in the process are:
1* Define a hardware monitoring class, which all hardware monitoring
drivers would register with. Mark M. Hoffman just did that a few weeks
ago.
2* Separate the non-i2c hardware monitoring drivers from the i2c-core.
This is what I am doing right now.
3* Have the user-space tools (libsensors) search for hardware monitoring
drivers through /sys/class/hwmon rather than (or, for the time being,
additionally to) /sys/bus/i2c. Next on my list.
4* Clean up the i2c core. This isn't directly related, but needs to be
done, and will be much easier now that the isa hooks are gone. This
includes a full rewrite of the way the i2c chip driver module parameters
are handled, and a merge of i2c_probe and i2c_detect, to name only the
two major ones. We might also get rid of some IDs that don't seem to be
strictly needed (in i2c_algorithm and i2c_driver). And maybe split the
SMBus 1 and 2 implementations away from i2c-core, not too sure what it
would take.
5* Really attach the non-i2c drivers to their right location in the
sysfs tree. I don't know exactly where the correct location is, but
we'll have to find. Once the hwmon class is in use, moving the drivers
around in the sysfs tree will not break the user-space compatibility.
Note that 3* depends on 1* and 4* depends on 2*. Also, we will need to
wait some time (6 months? 1 year?) between 3* and 5* so as to not break
user-space compatibility too much. This is the reason why I made 2* and
5* different points even though it would sound saner to do them in a
single step. This approach also lets me parallelize with 4*, which I
want to do now rather than wait for 5* to happen.
So, the approximate timeline would be 1* to 3* right now, 4* after that
as time permits, and 5* when we estimate that 3* happened long enough
ago (roughly 1st half of 2006?)
I hope I explained it correctly this time. If not, just complain ;)
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Re: relayfs documentation sucks?
> > When I'm debugging something requiring detailed tracing, I don't want > to have to think about whether the tracing tool has the particular > behaviour, performance, data loss, and other such characteristics > needed for my immediate needs. It is easier to code up some little > ad hoc mechanism than it is to try to figure out whether some general > purpose mechanism is suitable and how to use the generic mechanism. You can do lots of modes with relayfs already - no ping-pong buffer, n-buffer, lossy, not lossy etc etc. I currently use it in 'flight-recorder' mode where new messages overwrite old ones. It might be good to document different possible ways of using relayfs. > If there are enough specific purposes for relayfs, fine. But beware > of over generalizing its potential usefulness. There is always the > risk of over designing it, adding additional flexibility and options > in an effort to gain customers, at the expense of making it less and > less obviously useful in a trivial way for any specific purpose. It's currently pretty limited - but you can add more features on top of it, in a modular fashion. I tend not to use the complex stuff, but you can layer it if you want. It'd be nice if we had some basic relaying infrastructure available that'd cover most needs successfully. Advanced users can do advanced things if they want. Btw, the diskstat tools (http://ds9a.nl/diskstat) require relayfs. It'll be released this Friday or so. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: relayfs documentation sucks?
Steve wrote: > The reason I would like to see this merged, so kernel hackers don't need > to constantly write there own logging buffers everytime you need to > debug a complex area of the kernel. But I doubt that relayfs, or anything resembling it, will accomplish this purpose, at least for some of us, in many such situations. When I'm debugging something requiring detailed tracing, I don't want to have to think about whether the tracing tool has the particular behaviour, performance, data loss, and other such characteristics needed for my immediate needs. It is easier to code up some little ad hoc mechanism than it is to try to figure out whether some general purpose mechanism is suitable and how to use the generic mechanism. Invariably in any particular situation, there is some almost trivial way to hack in something adequate, for very little effort, doing things that would be utterly useless in some other case. Such tracing mechanisms work to obtain major subsystem isolation, by exposing the flow of data and control back and forth across a major boundary, such as using strace for the initial isolation of a problem that might be in user space, or might be in the kernel. But for detailed work within a subsystem, the corners that one can cut with ad hoc tools often make them vastly superior to general purpose tools. Even the best equipped of carpenters sometimes throw together some temporary scaffolding using rough cut 2x4's (2 inch by 4 inch cross section lumbar; I don't know what they're called in metric nations.) If there are enough specific purposes for relayfs, fine. But beware of over generalizing its potential usefulness. There is always the risk of over designing it, adding additional flexibility and options in an effort to gain customers, at the expense of making it less and less obviously useful in a trivial way for any specific purpose. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 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] forcedeth: TX handler changes (experimental)
Manfred Spraul wrote: Autsch. Yes, you are right. Sorry for that, I should have reread the patch once more. No problem :) I've been running v0.38 since my last mail. No problems at all. Thanks for your continued work on the driver. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel guide to space
> > 3c. * in types > > Leave space between name and * in types. > > Multiple * dont need additional space between them. > > > > struct foo **bar; > > > Don't put spaces between `*' and the name when declaring variables, > even if it's not a double pointer. int * foo; is ugly. Common > convention is int *foo; The "Leave space between name and *" is confusing. Does 'name' refer to the type or variable. I hope Michael was not recommending: char * p; How about saying: Do not leave a space between a * and the following variable name, nor between multiple *, when used to declare pointers: char *p; struct foo **bar; -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 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 2.6] I2C: Separate non-i2c hwmon drivers from i2c-core (1/9)
Hi Greg,
> > +/* Next four are needed by i2c-isa */
> > +EXPORT_SYMBOL(i2c_adapter_dev_release);
> > +EXPORT_SYMBOL(i2c_adapter_driver);
> > +EXPORT_SYMBOL(i2c_adapter_class);
> > +EXPORT_SYMBOL(i2c_bus_type);
>
> EXPORT_SYMBOL_GPL() instead? As these were, core, GPL only symbols
> before you exported them.
Sure, no problem. I would even use EXPORT_SYMBOL_I2C_ISA_ONLY() if it
happened to exist ;)
Updated patch follows, thanks.
Temporarily export a few structures and functions from i2c-core, because we
will soon need them in i2c-isa.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
drivers/i2c/i2c-core.c | 14 ++
include/linux/i2c.h|7 +++
2 files changed, 17 insertions(+), 4 deletions(-)
--- linux-2.6.13-rc3.orig/drivers/i2c/i2c-core.c2005-07-17
20:15:52.0 +0200
+++ linux-2.6.13-rc3/drivers/i2c/i2c-core.c 2005-07-20 18:19:46.0
+0200
@@ -61,7 +61,7 @@
return rc;
}
-static struct bus_type i2c_bus_type = {
+struct bus_type i2c_bus_type = {
.name = "i2c",
.match =i2c_device_match,
.suspend = i2c_bus_suspend,
@@ -78,13 +78,13 @@
return 0;
}
-static void i2c_adapter_dev_release(struct device *dev)
+void i2c_adapter_dev_release(struct device *dev)
{
struct i2c_adapter *adap = dev_to_i2c_adapter(dev);
complete(>dev_released);
}
-static struct device_driver i2c_adapter_driver = {
+struct device_driver i2c_adapter_driver = {
.name = "i2c_adapter",
.bus = _bus_type,
.probe = i2c_device_probe,
@@ -97,7 +97,7 @@
complete(>class_dev_released);
}
-static struct class i2c_adapter_class = {
+struct class i2c_adapter_class = {
.name = "i2c-adapter",
.release = _adapter_class_dev_release,
};
@@ -1171,6 +1171,12 @@
}
+/* Next four are needed by i2c-isa */
+EXPORT_SYMBOL_GPL(i2c_adapter_dev_release);
+EXPORT_SYMBOL_GPL(i2c_adapter_driver);
+EXPORT_SYMBOL_GPL(i2c_adapter_class);
+EXPORT_SYMBOL_GPL(i2c_bus_type);
+
EXPORT_SYMBOL(i2c_add_adapter);
EXPORT_SYMBOL(i2c_del_adapter);
EXPORT_SYMBOL(i2c_add_driver);
--- linux-2.6.13-rc3.orig/include/linux/i2c.h 2005-07-17 20:15:52.0
+0200
+++ linux-2.6.13-rc3/include/linux/i2c.h2005-07-20 18:19:01.0
+0200
@@ -34,6 +34,13 @@
#include /* for struct device */
#include
+/* --- For i2c-isa */
+
+extern void i2c_adapter_dev_release(struct device *dev);
+extern struct device_driver i2c_adapter_driver;
+extern struct class i2c_adapter_class;
+extern struct bus_type i2c_bus_type;
+
/* --- General options
*/
struct i2c_msg;
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: page allocation/attributes question (i386/x86_64 specific)
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Oh, sorry, we're talking about two different patches. I sent in a > different patch yesterday, because Andi Kleen didn't seem very > enthusiastic about fixnx2.patch. Here's the patch that I sent > yesterday (attached as file init.c.patch). ah - ok - this patch indeed should solve it. 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: [RFC][PATCH - 1/12] NTP cleanup: Move NTP code into ntp.c
On Mon, 2005-07-18 at 13:42 +0200, Pavel Machek wrote:
> Hi!
> > Any comments or feedback would be greatly appreciated.
> > +#ifdef CONFIG_TIME_INTERPOLATION
> > +void time_interpolator_update(long delta_nsec);
> > +#else
> > +#define time_interpolator_update(x)
>
> do {} while (0) is safer...
Applied.
> > + result = time_state; /* mostly `TIME_OK' */
> > +
> > + /* Save for later - semantics of adjtime is to return old value */
> > + save_adjust = time_next_adjust ? time_next_adjust : time_adjust;
> > +
> > +#if 0 /* STA_CLOCKERR is never set yet */
> > + time_status &= ~STA_CLOCKERR; /* reset STA_CLOCKERR */
> > +#endif
>
> Please remove deleted code completely.
Done in a later patch, but good point, I'll kill it in the first one.
Thanks for the review and feedback!
-john
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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]: kernel oops, fast ethernet bridge, 2.4.31
On Wednesday, July 20, 2005, 9:44:57 PM, Willy Tarreau wrote: > Hello, Hello Willy, > just some basic questions : > - did your configuration change before the oopses started ? (eg: new > matches, etc...) One new machine appears but it generates small traffic rate (by now it's almost unused). > - did the traffic change recently (protocols, data rate) ? eg: new > applications on the network, etc... No - firewall is bridging IPv4 only. There was no dramatic topology change. Those VLANs which are going through this firewall were untouched. > - is it possible that it's being targetted by an attack where it is > installed (unfiltered internet, holiday employees who like to play > with the network, etc...) ? I don't think so that managed IP of firewall was targetet, maybe machines behid firewall but problem appears on eth2 interface which is: internet <-trunk-> eth1(firewall/iptables)eth2<-trunk->(switch ports) <-> servers So it's after iptables ... > I really find it strange that it suddenly started oopsing if nothing > changed. At least it should have been oopsing from day one. It is strange to me too. There is no dependency when it happens. Sometimes traffic is small, sometimes it's normal. Packet rates are around ~2000-3000 pkt/sec - so not so high. Regards, Lukasz -- lspaleniak on wroc zigzag pl GCM dpu s: a--- C++ UL P+ L+++ E--- W+ N+ K- w O- M V- PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.12] printk: add sysctl to control printk_time
Added a sysctl (KERN_PRINTK_TIME) and by proxy an entry in
/proc/sys/kernel to enable and disable printk interval information when
CONFIG_PRINTK_TIME is compiled in.
Signed-off-by: Mark Whittington <[EMAIL PROTECTED]>
diff -ruN linux-2.6.12/Documentation/sysctl/kernel.txt
linux-2.6.12-work/Documentation/sysctl/kernel.txt
--- linux-2.6.12/Documentation/sysctl/kernel.txt2005-06-17
15:48:29.0 -0400
+++ linux-2.6.12-work/Documentation/sysctl/kernel.txt 2005-07-20
14:58:15.0 -0400
@@ -39,6 +39,7 @@
- pid_max
- powersave-nap [ PPC only ]
- printk
+- printk_time [ CONFIG_PRINTK_TIME=y ]
- real-root-dev ==> Documentation/initrd.txt
- reboot-cmd [ SPARC only ]
- rtsig-max
@@ -260,6 +261,14 @@
==
+printk_time:
+
+If CONFIG_PRINTK_TIME is on at compile time, you can enable
+and disable time printing by echoing 1 or 0 to this file. You
+can also read the current value from this file.
+
+==
+
reboot-cmd: (Sparc only)
??? This seems to be a way to give an argument to the Sparc
diff -ruN linux-2.6.12/include/linux/sysctl.h
linux-2.6.12-work/include/linux/sysctl.h
--- linux-2.6.12/include/linux/sysctl.h 2005-06-17 15:48:29.0 -0400
+++ linux-2.6.12-work/include/linux/sysctl.h2005-07-20 14:54:29.0
-0400
@@ -136,6 +136,9 @@
KERN_UNKNOWN_NMI_PANIC=66, /* int: unknown nmi panic flag */
KERN_BOOTLOADER_TYPE=67, /* int: boot loader type */
KERN_RANDOMIZE=68, /* int: randomize virtual address space */
+#if defined(CONFIG_PRINTK_TIME)
+ KERN_PRINTK_TIME=69, /* int: printk times enabled */
+#endif
};
diff -ruN linux-2.6.12/kernel/printk.c linux-2.6.12-work/kernel/printk.c
--- linux-2.6.12/kernel/printk.c2005-06-17 15:48:29.0 -0400
+++ linux-2.6.12-work/kernel/printk.c 2005-07-20 15:32:03.0 -0400
@@ -473,7 +473,8 @@
}
#if defined(CONFIG_PRINTK_TIME)
-static int printk_time = 1;
+int printk_time = 1;
+EXPORT_SYMBOL(printk_time);
#else
static int printk_time = 0;
#endif
diff -ruN linux-2.6.12/kernel/sysctl.c linux-2.6.12-work/kernel/sysctl.c
--- linux-2.6.12/kernel/sysctl.c2005-06-17 15:48:29.0 -0400
+++ linux-2.6.12-work/kernel/sysctl.c 2005-07-20 14:53:54.0 -0400
@@ -63,6 +63,7 @@
extern int pid_max;
extern int min_free_kbytes;
extern int printk_ratelimit_jiffies;
+extern int printk_time;
extern int printk_ratelimit_burst;
extern int pid_max_min, pid_max_max;
@@ -589,6 +590,16 @@
.mode = 0644,
.proc_handler = _dointvec,
},
+#if defined(CONFIG_PRINTK_TIME)
+ {
+ .ctl_name = KERN_PRINTK_TIME,
+ .procname = "printk_time",
+ .data = _time,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = _dointvec,
+ },
+#endif
{
.ctl_name = KERN_PRINTK_RATELIMIT,
.procname = "printk_ratelimit",
diff -ruN linux-2.6.12/lib/Kconfig.debug linux-2.6.12-work/lib/Kconfig.debug
--- linux-2.6.12/lib/Kconfig.debug 2005-06-17 15:48:29.0 -0400
+++ linux-2.6.12-work/lib/Kconfig.debug 2005-07-20 15:09:07.0 -0400
@@ -6,7 +6,9 @@
included in printk output. This allows you to measure
the interval between kernel operations, including bootup
operations. This is useful for identifying long delays
- in kernel startup.
+ in kernel startup. If this option is enabled, you can turn
+ off and on the timing information by echoing a 1 or 0 to
+ /proc/kernel/sys/printk_time.
config DEBUG_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: kernel oops, fast ethernet bridge, 2.4.31
Hello, just some basic questions : - did your configuration change before the oopses started ? (eg: new matches, etc...) - did the traffic change recently (protocols, data rate) ? eg: new applications on the network, etc... - is it possible that it's being targetted by an attack where it is installed (unfiltered internet, holiday employees who like to play with the network, etc...) ? I really find it strange that it suddenly started oopsing if nothing changed. At least it should have been oopsing from day one. Regards, willy On Wed, Jul 20, 2005 at 05:00:25PM +0200, Lukasz Spaleniak wrote: > Hello, > > I have bridge firewall (linux box) with three fast ethernet cards (one > rtl8139 for management and two e100 for bridge). It is running 2.4.31 > kernel and iptables v1.2.11. It works ok about one month. Few weeks > ago It started ooopsing. First thought was hardware, but it was > replaced with a new one and problem still exist. I'm attaching > ksymoops analysis of ooops message. I hope I'll help. > > Some facts: > Traffic over this bridge is about ~30 MBit/sec and every frame is > tagged with VID (802.1q). Problem exist also on 2.4.30 kernel. > Kernel is patched with ebtables patch. Ooops completeley freezes > machine, only hard reset takes effect. Nothing is placed into syslog. > > The ksymooops analisis is attached as text file. > > Anyone know this bug/problem ? > > Regards, > Lukasz Spaleniak > > -- > spalek on wroc zigzag pl > GCM dpu s: a--- C++ UL P+ L+++ E--- W+ N+ K- w O- M V- > PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 PIIX vs libata piix with software raid
David Lewis wrote: Greetings, I am developing a system using the Intel SE7520BD2 motherboard. It has an ICH5 with two SATA ports and one PATA channel. I am able to drive the PATA channel with either the normal PIIX IDE driver or the libata driver which I am using for the SATA ports. Ultimately all 4 ports will be in use with the md driver creating a stripe volume (RAID0) that spans a partition on each of the 4 drives (not for boot). My question is, what is the recommended driver to use for the PATA channel? Is it better to let libata support both types of drives, or use the IDE driver for the PATA? Searching I have found that the support is there in libata for the PATA channel (and I have it working on the system), but I can't find a clear recommendation on which driver is considered 'better' in this situation. If you're just using hard drives, there should be no problem using libata for both PATA and SATA. However, in general, the IDE driver (CONFIG_IDE) is recommended for PATA. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: page allocation/attributes question (i386/x86_64 specific)
Hayes, Stuart wrote: > Ingo Molnar wrote: >> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >>> Ingo Molnar wrote: there's one problem with the patch: it breaks things that need the low 1MB executable (e.g. APM bios32 calls). It would at a minimum be needed to exclude the BIOS area in 0xd-0xf. Ingo >>> >>> I wrote it to make everything below 1MB executable, if it isn't RAM >>> according to the e820 map, which should include the BIOS area. This >>> includes 0xd-0x on my system. Do you think I should >>> explicity make 0xd-0xf executable regardless of the e820 >>> map? >> >> hm ... which portion does this? I'm looking at fixnx2.patch. I >> definitely saw a APM bootup crash due to this, but that was on a >> 2.4-ish backport of the patch. >> >> Ingo > > Oh, sorry, we're talking about two different patches. I sent in a > different patch yesterday, because Andi Kleen didn't seem very > enthusiastic about fixnx2.patch. Here's the patch that I sent > yesterday (attached as file init.c.patch). > > Thanks > Stuart Although... if you like the fixnx2.patch better, I can modify it. I'm ok with either approach. Stuart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.13-rc3 dma_timer_expiry
I just changed kernels from 2.6.11.4 to 2.6.13-rc3 and upon boot I now
see these errors on the console and in the syslog:
localhost kernel: hda: dma_timer_expiry: dma status == 0x21
localhost kernel: hda: DMA timeout error
localhost kernel: hda: dma timeout error: status=0x58 { DriveReady SeekComplete
DataRequest }
localhost kernel: ide: failed opcode was: unknown
The errors appeared shortly before X started up (so pretty late in the
boot sequence). With 2.6.11.4 the drive had been working perfectly (no
errors at all), and is working fine now that I rebooted with 2.6.11.4.
DMA is turned on with 2.6.11.4, according to hdparm:
/dev/hda:
multcount= 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
geometry = 65535/16/63, sectors = 78140160, start = 0
The system is a Thinkpad 600X laptop (Pentium III) with a 40GB
IBM/Hitachi TravelStar 40GNX drive. Here's the disk info as recognized
on boot:
localhost kernel: hda: IC25N040ATCS05-0, ATA DISK drive
Anything I can do to debug it? Or is it just a simple setting that I
missed?
2.6.13-rc3 kernel config included below. The lilo append was:
idebus=66 apm=off acpi=force pci=noacpi acpi_sleep=s3_bios
-Sanjoy
`A society of sheep must in time beget a government of wolves.'
- Bertrand de Jouvenal
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.13-rc3-200507201
# Wed Jul 20 11:14:11 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_CLEAN_COMPILE is not set
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
# CONFIG_HPET_EMULATE_RTC is not set
# CONFIG_SMP is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_REGPARM is not set
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PHYSICAL_START=0x10
# CONFIG_KEXEC is not set
#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_DEBUG=y
Re: [PATCH] generic_file_sendpage
Linus Torvalds wrote: "sendfile()" in general I think has been a mistake. It's too specialized, and the interface has always sucked. Ok, you're right. I will have a look at the pipe buffer stuff. As Andrew pointed out, it actually needs to limit the number of buffers in flight partly because otherwise you have uninterruptible kernel work etc etc. Hmm, sendfile() uses do_generic_mapping_read() which is calling the file_send_actor() per page. The actor calls ->sendpage(). I don't see any situation how this could lead to uninterruptible kernel work when the sendpage() itself is checking for signals. There are only 2 pages in flight in this case. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ramfs: pretend dirent sizes
Jan Blunck wrote: I don't want to tell where these are in general, I need an easy way to seek to the m'th directory + offset position without reading every single dirent. With i_sizes != 0 it is straight forward to use "the sum of the m directory's i_sizes + offset" as the f_pos to seek to. For this purpose it is not necessary to have a "honest" i_size as long as the i_size is bigger than the offset of the last dirent in the directory. You are not going to get this functionality. It is simply not how directories work nowadays. Very few file systems are going to be usable if you insist upon this semantic. It is simply not possible to guess, with variable sized entries and with distributed directory structures. ps - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ramfs: pretend dirent sizes
Jan Blunck wrote: Also, how is lseek + readdir supposed to work in general? This is how libc is reading directories (at least on arch s390x): getdents() != 0 lseek() to d_off of last dirent getdents() != 0 lseek() to d_off of last dirent getdents() == 0 return Therefore I really need values that make sense for d_off. Therefore I really need values that make (some kind of) sense for i_size. Please be aware that not all filesystems treat directories as sequential files, filled with with odd sized records. Some directories are distributed across the entire file system and the d_off fields really contain the address on disk of the next entry in the directory. The d_off field is really just a cookie and is not meant to be interpreted as an offset into the directory. The lseek() system call is used, but only because that was a handy way of positioning the pointer into the directory. It is unfortunate that the getdents(2) system call was not defined with a cookie as one of its arguments to indicate where to start fetching entries from. This would have reduced the confusion about treating directories as files or not. Thanx... ps - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.12-rc3]dell_rbu: Resubmitting patch for new Dell BIOS update driver
Resending dell_rbu driver after making a few more improvements and also using the new request_firmware_nowait kernel API sent in the firmware_class.c patch. This patch has been tested on i386 and x86-64 systems along with the firmware_class.c patch and it works fine. Signed-off-by: Abhay Salunke <[EMAIL PROTECTED]> Thanks Abhay diff -uprN linux-2.6.11.11.orig/Documentation/dell_rbu.txt linux-2.6.11.11.new/Documentation/dell_rbu.txt --- linux-2.6.11.11.orig/Documentation/dell_rbu.txt 1969-12-31 18:00:00.0 -0600 +++ linux-2.6.11.11.new/Documentation/dell_rbu.txt 2005-07-14 14:59:10.0 -0500 @@ -0,0 +1,74 @@ +Purpose: +Demonstrate the usage of the new open sourced rbu (Remote BIOS Update) driver +for updating BIOS images on Dell servers and desktops. + +Scope: +This document discusses the functionality of the rbu driver only. +It does not cover the support needed from aplications to enable the BIOS to +update itself with the image downloaded in to the memory. + +Overview: +This driver works with Dell OpenManage or Dell Update Packages for updating +the BIOS on Dell servers (starting from servers sold since 1999), desktops +and notebooks (starting from those sold in 2005). +Please go to http://support.dell.com register and you can find info on +OpenManage and Dell Update packages (DUP). + +Dell_RBU driver supports BIOS update using the monilothic image and packetized +image methods. In case of moniolithic the driver allocates a contiguous chunk +of physical pages having the BIOS image. In case of packetized the app +using the driver breaks the image in to packets of fixed sizes and the driver +would place each packet in contiguous physical memory. The driver also +maintains a link list of packets for reading them back. +If the dell_rbu driver is unloaded all the allocated memory is freed. + +The rbu driver needs to have an application which will inform the BIOS to +enable the update in the next system reboot. + +The user should not unload the rbu driver after downloading the BIOS image +or updating. + +The driver load creates the following directories under the /sys file system. +/sys/class/firmware/dell_rbu/loading +/sys/class/firmware/dell_rbu/data +/sys/devices/platform/dell_rbu/image_type +/sys/devices/platform/dell_rbu/data + +The driver supports two types of update mechanism; monolithic and packetized. +These update mechanism depends upon the BIOS currently running on the system. +Most of the Dell systems support a monolithic update where the BIOS image is +copied to a single contiguous block of physical memory. +In case of packet mechanism the single memory can be broken in smaller chuks +of contiguous memory and the BIOS image is scattered in these packets. + +By default the driver uses monolithic memory for the update type. This can be +changed to contiguous during the driver load time by specifying the load +parameter image_type=packet. This can also be changed later as below +echo "packet" > /sys/devices/platform/dell_rbu/image_type + +Do the steps below to download the BIOS image. +1) echo 1 > /sys/class/firmware/dell_rbu/loading +2) cp bios_image.hdr /sys/class/firmware/dell_rbu/data +3) echo 0 > /sys/class/firmware/dell_rbu/loading + +The /sys/class/firmware/dell_rbu/ entries will remain till the following is +done. +echo -1 > /sys/class/firmware/dell_rbu/loading + +Until this step is completed the drivr cannot be unloaded. + +Also the driver provides /sys/devices/platform/dell_rbu/data readonly file to +read back the image downloaded. This is useful in case of packet update +mechanism where the above steps 1,2,3 will repeated for every packet. +By reading the /sys/devices/platform/dell_rbu/data file all packet data +downloaded can be verified in a single file. +The packets are arranged in this file one after the other in a FIFO order. + +NOTE: +This driver requires a patch for firmware_class.c which has the addition +of request_firmware_nowait_nohotplug function to wortk +Also after updating the BIOS image an user mdoe application neeeds to execute +code which message the BIOS update request to the BIOS. So on the next reboot +the BIOS knows about the new image downloaded and it updates it self. +Also don't unload the rbu drive if the image has to be updated. + diff -uprN linux-2.6.11.11.orig/drivers/firmware/dell_rbu.c linux-2.6.11.11.new/drivers/firmware/dell_rbu.c --- linux-2.6.11.11.orig/drivers/firmware/dell_rbu.c1969-12-31 18:00:00.0 -0600 +++ linux-2.6.11.11.new/drivers/firmware/dell_rbu.c 2005-07-20 18:30:51.0 -0500 @@ -0,0 +1,656 @@ +/* + * dell_rbu.c + * Bios Update driver for Dell systems + * Author: Dell Inc + * Abhay Salunke <[EMAIL PROTECTED]> + * + * Copyright (C) 2005 Dell Inc. + * + * Remote BIOS Update (rbu) driver is used for updating DELL BIOS by + * creating entries in the /sys file systems on Linux 2.6 and higher + * kernels. The driver supports two mechanism to update the BIOS namely + *
[patch 2.6.12-rc3] modified firmware_class.c to support no hotplug
Reseending the patch for firmware_class.c submitted earlier ,the patch
upgrades the request_firmware_nowait function to not start the hotplug
action on a firmware update.
This patch is tested along with dell_rbu driver on i386 and x86-64 systems.
Andrew, could you please add this patch to the -mm tree.
Signed-off-by: Abhay Salunke <[EMAIL PROTECTED]>
Thanks
Abhay
diff -uprN linux-2.6.11.11.orig/drivers/base/firmware_class.c
linux-2.6.11.11.new/drivers/base/firmware_class.c
--- linux-2.6.11.11.orig/drivers/base/firmware_class.c 2005-06-17
22:02:47.0 -0500
+++ linux-2.6.11.11.new/drivers/base/firmware_class.c 2005-07-12
15:40:52.0 -0500
@@ -28,6 +28,7 @@ enum {
FW_STATUS_DONE,
FW_STATUS_ABORT,
FW_STATUS_READY,
+ FW_STATUS_READY_NOHOTPLUG,
};
static int loading_timeout = 10; /* In seconds */
@@ -334,7 +335,7 @@ error_kfree:
static int
fw_setup_class_device(struct firmware *fw, struct class_device **class_dev_p,
- const char *fw_name, struct device *device)
+ const char *fw_name, struct device *device, int hotplug)
{
struct class_device *class_dev;
struct firmware_priv *fw_priv;
@@ -365,8 +366,11 @@ fw_setup_class_device(struct firmware *f
__FUNCTION__);
goto error_unreg;
}
-
- set_bit(FW_STATUS_READY, _priv->status);
+
+ if (hotplug)
+ set_bit(FW_STATUS_READY, _priv->status);
+ else
+ set_bit(FW_STATUS_READY_NOHOTPLUG, _priv->status);
*class_dev_p = class_dev;
goto out;
@@ -376,21 +380,9 @@ out:
return retval;
}
-/**
- * request_firmware: - request firmware to hotplug and wait for it
- * Description:
- * @firmware will be used to return a firmware image by the name
- * of @name for device @device.
- *
- * Should be called from user context where sleeping is allowed.
- *
- * @name will be use as $FIRMWARE in the hotplug environment and
- * should be distinctive enough not to be confused with any other
- * firmware image for this or any other device.
- **/
-int
-request_firmware(const struct firmware **firmware_p, const char *name,
-struct device *device)
+static int
+_request_firmware(const struct firmware **firmware_p, const char *name,
+struct device *device, int hotplug)
{
struct class_device *class_dev;
struct firmware_priv *fw_priv;
@@ -409,22 +401,25 @@ request_firmware(const struct firmware *
}
memset(firmware, 0, sizeof (*firmware));
- retval = fw_setup_class_device(firmware, _dev, name, device);
+ retval = fw_setup_class_device(firmware, _dev, name, device,
+ hotplug);
if (retval)
goto error_kfree_fw;
fw_priv = class_get_devdata(class_dev);
+
+ if (hotplug) {
+ if (loading_timeout) {
+ fw_priv->timeout.expires = jiffies + loading_timeout *
HZ;
+ add_timer(_priv->timeout);
+ }
- if (loading_timeout) {
- fw_priv->timeout.expires = jiffies + loading_timeout * HZ;
- add_timer(_priv->timeout);
- }
-
- kobject_hotplug(_dev->kobj, KOBJ_ADD);
- wait_for_completion(_priv->completion);
- set_bit(FW_STATUS_DONE, _priv->status);
-
- del_timer_sync(_priv->timeout);
+ kobject_hotplug(_dev->kobj, KOBJ_ADD);
+ wait_for_completion(_priv->completion);
+ set_bit(FW_STATUS_DONE, _priv->status);
+ del_timer_sync(_priv->timeout);
+ } else
+ wait_for_completion(_priv->completion);
down(_lock);
if (!fw_priv->fw->size || test_bit(FW_STATUS_ABORT, _priv->status)) {
@@ -445,6 +440,26 @@ out:
}
/**
+ * request_firmware: - request firmware to hotplug and wait for it
+ * Description:
+ * @firmware will be used to return a firmware image by the name
+ * of @name for device @device.
+ *
+ * Should be called from user context where sleeping is allowed.
+ *
+ * @name will be use as $FIRMWARE in the hotplug environment and
+ * should be distinctive enough not to be confused with any other
+ * firmware image for this or any other device.
+ **/
+int
+request_firmware(const struct firmware **firmware_p, const char *name,
+ struct device *device)
+{
+ int hotplug = 1;
+ return _request_firmware(firmware_p, name, device, hotplug);
+}
+
+/**
* release_firmware: - release the resource associated with a firmware image
**/
void
@@ -481,6 +496,7 @@ struct firmware_work {
struct device *device;
void *context;
void (*cont)(const struct firmware *fw, void *context);
+ int hotplug;
};
static int
@@ -493,7 +509,8 @@ request_firmware_work_func(void *arg)
return 0;
}
Re: [PATCH] ramfs: pretend dirent sizes
Chris Wedgwood wrote: To my understanding, you can lseek to any "proper" offset inside a directory. Proper means that the offset marks the beginning of a new dirent (or end of file) in the interpretation of the filesystem. But you can never tell where these are in general. I don't want to tell where these are in general, I need an easy way to seek to the m'th directory + offset position without reading every single dirent. With i_sizes != 0 it is straight forward to use "the sum of the m directory's i_sizes + offset" as the f_pos to seek to. For this purpose it is not necessary to have a "honest" i_size as long as the i_size is bigger than the offset of the last dirent in the directory. I don't see why or how this can be true in general (it might be, but I don't see how myself). If we are half way through scanning a directory and people start messing with it we could end up somewhere bogus (in which case f_op->readdir I guess is expected to try and do something sane here?) E.g.: ext2_validate_entry() is called if filp->f_version != inode->i_version. Reopening the same directory may result in a formerly proper offset isn't anymore. Which is a user problem again. Might be that you are opening a different directory with the same name ... or even a regular file! Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]IOAPIC_CACHE for PREEMPT_RT @ x86_64
Hi,
attached patch implements IOAPIC_CACHE on x86_64,
if I haven't forgotten something
Note that in the patch, IOAPIC_POSTFLUSH is initially not set.
Thats different to plain -51-32.
Works fine here on a K8T800 Mobo.
Would be fine, if some guys could give this a try ontop of -51-32.
Thanks,
Karsten
--- linux-2.6.12-RT-51-32/arch/x86_64/kernel/io_apic.c 2005-07-19 11:00:17.0 +0200
+++ linux-2.6.12-RT/arch/x86_64/kernel/io_apic.c 2005-07-20 18:15:10.0 +0200
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -41,16 +42,11 @@
#define __apicdebuginit __init
-int sis_apic_bug; /* not actually supported, dummy for compile */
static int no_timer_check;
static DEFINE_RAW_SPINLOCK(ioapic_lock);
-/*
- * # of IRQ routing registers
- */
-int nr_ioapic_registers[MAX_IO_APICS];
/*
* Rough estimation of how many shared IRQs there are, can
@@ -101,22 +97,123 @@
entry->pin = pin;
}
+#ifdef CONFIG_X86_IOAPIC_FAST
+# define IOAPIC_CACHE
+#endif
+
+/*
+ * some chips need this commented out:
+ */
+// #define IOAPIC_POSTFLUSH
+/*
+ * K8T800 seams not to need it.
+ */
+
+struct ioapic_data_struct {
+ volatile unsigned int *base;
+#ifdef IOAPIC_CACHE
+ unsigned int reg_set;
+#endif
+ int nr_registers; // # of IRQ routing registers
+ struct sys_device dev;
+ struct IO_APIC_route_entry *entry;
+#ifdef IOAPIC_CACHE
+ u32 cached_val[0];
+#endif
+};
+
+static struct ioapic_data_struct *ioapic_data[MAX_IO_APICS];
+
+
+static inline unsigned int __raw_io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
+{
+#ifdef IOAPIC_CACHE
+ ioapic->reg_set = reg;
+#endif
+ ioapic->base[0] = reg;
+ return ioapic->base[4];
+}
+
+
+#ifdef IOAPIC_CACHE
+static void __init ioapic_cache_init(struct ioapic_data_struct *ioapic)
+{
+ int reg;
+ for (reg = 0; reg < (0x10 + 2 * ioapic->nr_registers); reg++)
+ ioapic->cached_val[reg] = __raw_io_apic_read(ioapic, reg);
+}
+#endif
+
+#if !defined(IOAPIC_CACHE) || defined(IOAPIC_POSTFLUSH)
+static unsigned int raw_io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
+{
+ unsigned int val = __raw_io_apic_read(ioapic, reg);
+
+#ifdef IOAPIC_CACHE
+ ioapic->cached_val[reg] = val;
+#endif
+ return val;
+}
+#endif
+
+static inline unsigned int io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
+{
+#ifdef IOAPIC_CACHE
+ ioapic->reg_set = -1;
+ return ioapic->cached_val[reg];
+#else
+ return raw_io_apic_read(ioapic, reg);
+#endif
+}
+
+static void io_apic_write(struct ioapic_data_struct *ioapic, unsigned int reg, unsigned int val)
+{
+#ifdef IOAPIC_CACHE
+ ioapic->cached_val[reg] = val;
+ ioapic->reg_set = reg;
+#endif
+ ioapic->base[0] = reg;
+ ioapic->base[4] = val;
+}
+
+/*
+ * Re-write a value: to be used for read-modify-write
+ * cycles where the read already set up the index register.
+ */
+static inline void io_apic_modify(struct ioapic_data_struct *ioapic, unsigned int reg, unsigned int val)
+{
+#ifdef IOAPIC_CACHE
+ if (ioapic->reg_set != reg) {
+ ioapic->base[0] = reg;
+ ioapic->reg_set = reg;
+ }
+ ioapic->cached_val[reg] = val;
+#endif
+ ioapic->base[4] = val;
+
+#ifdef IOAPIC_POSTFLUSH
+ /* Force POST flush by reading: */
+ val = raw_io_apic_read(ioapic, reg);
+#endif
+}
+
#define __DO_ACTION(R, ACTION, FINAL) \
\
{ \
int pin; \
struct irq_pin_list *entry = irq_2_pin + irq; \
+ struct ioapic_data_struct *ioapic;\
\
for (;;) { \
- unsigned int reg; \
+ unsigned int reg, val; \
pin = entry->pin; \
if (pin == -1) \
break; \
- reg = io_apic_read(entry->apic, 0x10 + R + pin*2); \
- reg ACTION; \
- io_apic_modify(entry->apic, reg); \
- /* Force POST flush by reading: */ \
- reg = io_apic_read(entry->apic, 0x10 + R + pin*2); \
+ ioapic = ioapic_data[entry->apic]; \
+ reg = 0x10 + R + pin*2; \
+ val = io_apic_read(ioapic, reg); \
+ val ACTION; \
+ io_apic_modify(ioapic, reg, val); \
\
if (!entry->next) \
break; \
@@ -151,15 +248,15 @@
spin_unlock_irqrestore(_lock, flags);
}
-static void clear_IO_APIC_pin(unsigned int apic, unsigned int pin)
+static void clear_IO_APIC_pin(struct ioapic_data_struct *ioapic, unsigned int pin)
{
struct IO_APIC_route_entry entry;
unsigned long flags;
/* Check delivery_mode to be sure we're not clearing an SMI pin */
spin_lock_irqsave(_lock, flags);
- *(((int*)) + 0) = io_apic_read(apic, 0x10 + 2 * pin);
- *(((int*)) + 1) = io_apic_read(apic, 0x11 + 2 * pin);
+ *(((int*)) + 0) = io_apic_read(ioapic, 0x10 + 2 * pin);
+ *(((int*)) + 1) = io_apic_read(ioapic, 0x11 + 2 * pin);
spin_unlock_irqrestore(_lock, flags);
if (entry.delivery_mode == dest_SMI)
return;
@@ -169,8 +266,8 @@
memset(, 0, sizeof(entry));
entry.mask = 1;
spin_lock_irqsave(_lock, flags);
- io_apic_write(apic, 0x10 + 2 * pin, *(((int *)) + 0));
- io_apic_write(apic, 0x11 + 2 * pin, *(((int *)) + 1));
+
Re: [Clusters_sig] RE: [Linux-cluster] Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
On Wed, Jul 20, 2005 at 08:09:18PM +0200, Lars Marowsky-Bree wrote: > On 2005-07-20T09:55:31, "Walker, Bruce J (HP-Labs)" <[EMAIL PROTECTED]> wrote: > > > Like Lars, I too was under the wrong impression about this configfs > > "nodemanager" kernel component. Our discussions in the cluster > > meeting Monday and Tuesday were assuming it was a general service that > > other kernel components could/would utilize and possibly also > > something that could send uevents to non-kernel components wanting a > > std. way to see membership information/events. > > Let me clarify that this was something we briefly touched on in > Walldorf: The node manager would (re-)export the current data via sysfs > (which would result in uevents being sent, too), and not something we > dreamed up just Monday ;-) In turn, let me clarify a little where configfs fits in to things. Configfs is merely a convenient and transparent method to communicate configuration to kernel objects. It's not a place for uevents, for netlink sockets, or for fancy communication. It allows userspace to create an in-kernel object and set/get values on that object. It also allows userspace and kernelspace to share the same representation of that object and its values. For more complex interaction, sysfs and procfs are often more appropriate. While you might "configure" all known nodes in configfs, the node up/down state might live in sysfs. A netlink socket for up/down events might live in procfs. And so on. Joel -- "But all my words come back to me In shades of mediocrity. Like emptiness in harmony I need someone to comfort me." Joel Becker Senior Member of Technical Staff Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] ramfs: pretend dirent sizes
Chris Wedgwood wrote: Hos does that work if offset >= m? Eerrh, did you actually read my patch? The i_size of a directory is increased by SIMPLE_BOGO_DIRENT_SIZE for every entry in the directory. >>So you can seek to m*+ to access an offset into >>> >something at depth m? >>> > >> >> Yes. I got that one wrong! You can seek to the "sum of i_sizes (of the m directories) + offset" to access offset in the m'th directory/stack-depth. lseek talks about bytes --- yes, it means for files specifically but I still don't see why we need to define more counter-intuitive semantics for directories when we don't need them. It is counter-intuitive to have a value which is information less, like in the zero case. Also, how is lseek + readdir supposed to work in general? This is how libc is reading directories (at least on arch s390x): getdents() != 0 lseek() to d_off of last dirent getdents() != 0 lseek() to d_off of last dirent getdents() == 0 return Therefore I really need values that make sense for d_off. Therefore I really need values that make (some kind of) sense for i_size. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 22/82] remove linux/version.h from drivers/message/fus ion
On Wed, Jul 20, 2005 at 12:54:09PM -0500, Nathan Lynch wrote:
> Matt Domsch wrote:
> > On Tue, Jul 19, 2005 at 06:07:41PM -0600, Moore, Eric Dean wrote:
> > > On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
> > > > In general, this construct:
> > > >
> > > > > > -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
> > > > > > -static int inline scsi_device_online(struct scsi_device *sdev)
> > > > > > -{
> > > > > > - return sdev->online;
> > > > > > -}
> > > > > > -#endif
> > > >
> > > > is better tested as:
> > > >
> > > > #ifndef scsi_device_inline
> > > > static int inline scsi_device_online(struct scsi_device *sdev)
> > > > {
> > > > return sdev->online;
> > > > }
> > > > #endif
> > > >
> > > > when you can. It cleanly eliminates the version test, and tests for
> > > > exactly what you're looking for - is this function defined.
> > > >
> > >
> > > What you illustrated above is not going to work.
> > > If your doing #ifndef around a function, such as scsi_device_online, it's
> > > not going to compile
> > > when scsi_device_online is already implemented in the kernel tree.
> > > The routine scsi_device_online is a function, not a define. For a define
> > > this would work.
> >
> > Sure it does, function names are defined symbols.
> >
>
> $ cat foo.c
> static int foo(void) { return 0; }
> #ifndef foo
> static int foo(void) { return 0; }
> #endif
>
> $ gcc -c foo.c
> foo.c:3: error: redefinition of 'foo'
> foo.c:1: error: previous definition of 'foo' was here
>
> I believe #ifdef/#ifndef can test only preprocessor symbols.
I was mistaken. Christoph explained to me that it worked on 2.4 due to
the way module symbol versions worked, but isn't that way on 2.6
anymore. My apologies.
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ramfs: pretend dirent sizes
On Wed, Jul 20, 2005 at 01:21:27PM +0200, J?rn Engel wrote: > To my understanding, you can lseek to any "proper" offset inside a > directory. Proper means that the offset marks the beginning of a > new dirent (or end of file) in the interpretation of the filesystem. But you can never tell where these are in general. > Userspace doesn't have any means to figure out, which addresses are > proper and which aren't. Except that getdents(2) moves the fd > offset to a proper address, which likely will remain proper until > the fd is closed. I don't see why or how this can be true in general (it might be, but I don't see how myself). If we are half way through scanning a directory and people start messing with it we could end up somewhere bogus (in which case f_op->readdir I guess is expected to try and do something sane here?) > Reopening the same directory may result in a formerly proper offset > isn't anymore. For that to be the case where is the state kept to ensure your current offset is valid? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Clusters_sig] RE: [Linux-cluster] Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
On 2005-07-20T09:55:31, "Walker, Bruce J (HP-Labs)" <[EMAIL PROTECTED]> wrote: > Like Lars, I too was under the wrong impression about this configfs > "nodemanager" kernel component. Our discussions in the cluster > meeting Monday and Tuesday were assuming it was a general service that > other kernel components could/would utilize and possibly also > something that could send uevents to non-kernel components wanting a > std. way to see membership information/events. Let me clarify that this was something we briefly touched on in Walldorf: The node manager would (re-)export the current data via sysfs (which would result in uevents being sent, too), and not something we dreamed up just Monday ;-) > As to kernel components without corresponding user-level "managers", > look no farther than OpenSSI. Our hope was that we could adapt to a > user-land membership service and this interface thru configfs would > drive all our kernel subsystems. Well, node manager still can provide you the input as to which nodes are configured, which in a way translates to "membership". The thing it doesn't seem to provide yet is the supsend/modify/resume cycle which for example the RHAT DLM seems to require. Sincerely, Lars Marowsky-Brée <[EMAIL PROTECTED]> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sharp Zaurus sl-5500 broken in 2.6.12
Hi!
> > > ...and that's well known; but now I did some back tracking, and
> > > 2.6.12-rc1 works, 2.6.12-rc2 does *not* and 2.6.12-rc2 with arm
> > > changes reverted works. I'll play a bit more.
> >
> > This fixes at least one break-the-boot bug in -rc2...
> >
> > Pavel
> >
> > --- linux-z11.rc2bad/arch/arm/mach-sa1100/collie.c 2005-07-19
> > 20:49:07.0 +0200
> > +++ linux-z11/arch/arm/mach-sa1100/collie.c 2005-07-19 21:05:54.0
> > +0200
> > @@ -235,7 +235,7 @@
> > sa11x0_set_flash_data(_flash_data, collie_flash_resources,
> > ARRAY_SIZE(collie_flash_resources));
> >
> > - sharpsl_save_param();
> > +// sharpsl_save_param();
> > }
> >
> > static struct map_desc collie_io_desc[] __initdata = {
>
> Could you check this wasn't caused by this typo please:
>
> http://www.rpsys.net/openzaurus/patches/collie_typofix-r0.patch
>
> (this has been fixed in recent kernels)
Oops, you are right, it is now fixed. I screwed up some config or
something... It works now.
BTW is there some place where I can find modifications Sharp did to
mainline 2.4 kernel?
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 22/82] remove linux/version.h from drivers/message/fus ion
On 7/19/05, Moore, Eric Dean <[EMAIL PROTECTED]> wrote:
> On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
> > In general, this construct:
> >
> > > > -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
> > > > -static int inline scsi_device_online(struct scsi_device *sdev)
> > > > -{
> > > > - return sdev->online;
> > > > -}
> > > > -#endif
> >
> > is better tested as:
> >
> > #ifndef scsi_device_inline
> > static int inline scsi_device_online(struct scsi_device *sdev)
> > {
> > return sdev->online;
> > }
> > #endif
> >
> > when you can. It cleanly eliminates the version test, and tests for
> > exactly what you're looking for - is this function defined.
> >
>
> What you illustrated above is not going to work.
> If your doing #ifndef around a function, such as scsi_device_online, it's
> not going to compile
> when scsi_device_online is already implemented in the kernel tree.
> The routine scsi_device_online is a function, not a define. For a define
> this would work.
>
> I'm trying your example around msleep, msleep_interruptible, and
> msecs_to_jiffies, and
> my code simply won't compile in SLES9 SP2(-191). In SLES9 SP1(-139), these
> three routines were not implemented and
> your suggestion works. I won't be able to to a linux version check as this
> change occurred between service packs
> of the 2.6.5 kernel suse tree. Anybody on the linux forums have any ideas?
>
> Example:
>
> #ifdef msleep
> static void inline msleep(unsigned long msecs)
> {
> set_current_state(TASK_UNINTERRUPTIBLE);
> schedule_timeout(msecs_to_jiffies(msecs) + 1);
> }
> #endif
Just an FYI, if you are trying to emulate the actual behavior of
msleep() in the current kernel via this function, then you need to
place the sleep in a while-loop. Please see kernel/timer.c::msleep().
Your version will wake up on wait-queue events, while msleep() in the
current kernel does not.
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 22/82] remove linux/version.h from drivers/message/fus ion
Matt Domsch wrote:
> On Tue, Jul 19, 2005 at 06:07:41PM -0600, Moore, Eric Dean wrote:
> > On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
> > > In general, this construct:
> > >
> > > > > -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
> > > > > -static int inline scsi_device_online(struct scsi_device *sdev)
> > > > > -{
> > > > > - return sdev->online;
> > > > > -}
> > > > > -#endif
> > >
> > > is better tested as:
> > >
> > > #ifndef scsi_device_inline
> > > static int inline scsi_device_online(struct scsi_device *sdev)
> > > {
> > > return sdev->online;
> > > }
> > > #endif
> > >
> > > when you can. It cleanly eliminates the version test, and tests for
> > > exactly what you're looking for - is this function defined.
> > >
> >
> > What you illustrated above is not going to work.
> > If your doing #ifndef around a function, such as scsi_device_online, it's
> > not going to compile
> > when scsi_device_online is already implemented in the kernel tree.
> > The routine scsi_device_online is a function, not a define. For a define
> > this would work.
>
> Sure it does, function names are defined symbols.
>
$ cat foo.c
static int foo(void) { return 0; }
#ifndef foo
static int foo(void) { return 0; }
#endif
$ gcc -c foo.c
foo.c:3: error: redefinition of 'foo'
foo.c:1: error: previous definition of 'foo' was here
I believe #ifdef/#ifndef can test only preprocessor symbols.
Nathan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [new] kernel-desktop 2.6.12-1.1398_FC4.desktop_1
On Wed, 2005-07-20 at 17:29 +0200, Jean-Eric Cuendet wrote: > Hi, "You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at [EMAIL PROTECTED]" Please don't cc: subscribers only lists when posting to LKML. 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: kernel guide to space
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> 3) If a normal line of code is more than 80 characters, one of the
>> following is probably true: you need to break the line up and use temps
>> for clarity, or your function is so big that you're tabbing over too
>> far.
>
> (Find source files, expand tab chars to their on-screen length, print if
>>= 80, count lines)
>
> ~/linux-2.6.12 >
> find . -type f "(" -iname "*.c" -o -iname "*.h" -o -iname "*.S" ")"
... -exec expand -t 8 '{}' \; | egrep '^.{80}' | wc -l
233941
You didn't take \t[^\t]\t into account.
--
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [new] kernel-desktop 2.6.12-1.1398_FC4.desktop_1
On Wed, 2005-07-20 at 17:29 +0200, Jean-Eric Cuendet wrote: > Hi, > I just released a new version of kernel-desktop. New features are: > - Realtime LSM module (Useful for jack audio server) 2.6.12 supports RLIMIT_RTPRIO and RLIMIT_NICE so this is no longer needed. The distros need to get with the program, AFAIK none of them have even released updated pam, bash, and glibc packages to support the new rlimits yet. 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: [Linux-cluster] Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
Like Lars, I too was under the wrong impression about this configfs "nodemanager" kernel component. Our discussions in the cluster meeting Monday and Tuesday were assuming it was a general service that other kernel components could/would utilize and possibly also something that could send uevents to non-kernel components wanting a std. way to see membership information/events. As to kernel components without corresponding user-level "managers", look no farther than OpenSSI. Our hope was that we could adapt to a user-land membership service and this interface thru configfs would drive all our kernel subsystems. Bruce Walker OpenSSI Cluster project -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lars Marowsky-Bree Sent: Wednesday, July 20, 2005 9:27 AM To: David Teigland Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: [Linux-cluster] Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm On 2005-07-20T11:35:46, David Teigland <[EMAIL PROTECTED]> wrote: > > Also, eventually we obviously need to have state for the nodes - > > up/down et cetera. I think the node manager also ought to track this. > We don't have a need for that information yet; I'm hoping we won't > ever need it in the kernel, but we'll see. Hm, I'm thinking a service might have a good reason to want to know the possible list of nodes as opposed to the currently active membership; though the DLM as the service in question right now does not appear to need such. But, see below. > There are at least two ways to handle this: > > 1. Pass cluster events and data into the kernel (this sounds like what > you're talking about above), notify the effected kernel components, > each kernel component takes the cluster data and does whatever it > needs to with it (internal adjustments, recovery, etc). > > 2. Each kernel component "foo-kernel" has an associated user space > component "foo-user". Cluster events (from userland clustering > infrastructure) are passed to foo-user -- not into the kernel. > foo-user determines what the specific consequences are for foo-kernel. > foo-user then manipulates foo-kernel accordingly, through user/kernel > hooks (sysfs, configfs, etc). These control hooks would largely be specific > to foo. > > We're following option 2 with the dlm and gfs and have been for quite > a while, which means we don't need 1. I think ocfs2 is moving that > way, too. Someone could still try 1, of course, but it would be of no > use or interest to me. I'm not aware of any actual projects pushing > forward with something like 1, so the persistent reference to it is somewhat > baffling. Right. I thought that the node manager changes for generalizing it where pushing into sort-of direction 1. Thanks for clearing this up. Sincerely, Lars Marowsky-Brée <[EMAIL PROTECTED]> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge" -- Linux-cluster mailing list [EMAIL PROTECTED] http://www.redhat.com/mailman/listinfo/linux-cluster - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
On 2005-07-20T11:35:46, David Teigland <[EMAIL PROTECTED]> wrote: > > Also, eventually we obviously need to have state for the nodes - up/down > > et cetera. I think the node manager also ought to track this. > We don't have a need for that information yet; I'm hoping we won't ever > need it in the kernel, but we'll see. Hm, I'm thinking a service might have a good reason to want to know the possible list of nodes as opposed to the currently active membership; though the DLM as the service in question right now does not appear to need such. But, see below. > There are at least two ways to handle this: > > 1. Pass cluster events and data into the kernel (this sounds like what > you're talking about above), notify the effected kernel components, each > kernel component takes the cluster data and does whatever it needs to with > it (internal adjustments, recovery, etc). > > 2. Each kernel component "foo-kernel" has an associated user space > component "foo-user". Cluster events (from userland clustering > infrastructure) are passed to foo-user -- not into the kernel. foo-user > determines what the specific consequences are for foo-kernel. foo-user > then manipulates foo-kernel accordingly, through user/kernel hooks (sysfs, > configfs, etc). These control hooks would largely be specific to foo. > > We're following option 2 with the dlm and gfs and have been for quite a > while, which means we don't need 1. I think ocfs2 is moving that way, > too. Someone could still try 1, of course, but it would be of no use or > interest to me. I'm not aware of any actual projects pushing forward with > something like 1, so the persistent reference to it is somewhat baffling. Right. I thought that the node manager changes for generalizing it where pushing into sort-of direction 1. Thanks for clearing this up. Sincerely, Lars Marowsky-Brée <[EMAIL PROTECTED]> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 - 0/12] NTP cleanup work (v. B4)
On Sun, 2005-07-17 at 20:00 +0200, Roman Zippel wrote: > On Fri, 15 Jul 2005, john stultz wrote: > > > In my attempts to rework the timeofday subsystem, it was suggested I > > try to avoid mixing cleanups with functional changes. In response to the > > suggestion I've tried to break out the majority of the NTP cleanups I've > > been working out of my larger patch and try to feed it in piece meal. > > > > The goal of this patch set is to isolate the in kernel NTP state machine > > in the hope of simplifying the current timeofday code. > > I don't really like, where you taken it with ntp_advance(). With these > patches you put half the ntp state machine in there and execute it at > every single tick. Hmm. While second_overflow() has been integrated into ntp_advance, we are not actually running that code every tick. Instead we keep an internal interval counter that runs the equivalent second_overflow() code only once a second. Maybe I'm not understanding specifically which you're talking about? > From the previous patches I can guess where you want to go with this, but > I think it's the wrong direction. The code is currently as is for a > reason, it's optimized for tick based system and I don't see a reason to > change this for tick based system. Well, with the exception of the last two patches, these changes should just be cleanups. If you notice a change in behavior in the first 10 patches, please let me know. > If you want to change this for cycle based system, you have to give more > control to the arch/timer source, which simply call a different set of > functions and the ntp core system basically just acts as a library to the > timer source. > Tick based timer sources continue to update xtime and cycle based system > will modify the cycle multiplier (e.g. what ppc64 does). Don't force > everything to use the same set of functions, you'll make it only more > complex. In a sense that's what I'm trying to provide, the NTP state machine will provide the adjustment that you can either apply completely at tick time or continually w/ a timesource. I really don't think the NTP changes I've mailed is very complex. Please, be specific and point to something you think is an issue and I'll do my best to fix it. > Larger ntp state updates don't have to be done more than once a > second and leave the details of how the clock is updated to the clock > source (just provide some library functions it can use). Again, I'm not be doing larger NTP state machine changes every tick. Thanks again for the feedback, I really do appreciate the review. thanks -john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sandisk Compact Flash
On Wed, Jul 20, 2005 at 12:49:00PM +0530, [EMAIL PROTECTED] wrote: > > Hi David , > > On my controller CF INPACK pin is connected to 3.3v. so Comapct > flash with DMA capabilty will not be supported , i understood this . > but i did not undesrtand why only PIO mode 1 is supported is it , > why not PIO mode 4 , is it a limitation of pcmcia driver , correct > me if i am wrong The 16-bit PCMCIA bus is maxed out at about 1 MB/sec; that's all the bandwidth there is. What your card supports is irrelevant. I'm not sure whether the PCMCIA mode actually corresponds to any of the official PIO modes 0, 1, etc. It is just "slow". -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] fs/jbd/: cleanups
On Jul 19, 2005 16:15 +0200, Adrian Bunk wrote:
> This patch contains the following cleanups:
> - make needlessly global functions static
> - journal.c: remove the unused global function __journal_internal_check
> and move the check to journal_init
> - remove the following write-only global variable:
> - journal.c: current_journal
> - remove the following unneeded EXPORT_SYMBOL:
> - journal.c: journal_recover
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Andreas Dilger <[EMAIL PROTECTED]>
> ---
>
> fs/jbd/journal.c| 34 ++
> fs/jbd/revoke.c |3 ++-
> include/linux/jbd.h |1 -
> 3 files changed, 16 insertions(+), 22 deletions(-)
>
> --- linux-2.6.12-rc6-mm1-full/include/linux/jbd.h.old 2005-06-14
> 03:58:20.0 +0200
> +++ linux-2.6.12-rc6-mm1-full/include/linux/jbd.h 2005-06-14
> 04:00:56.0 +0200
> @@ -914,7 +912,6 @@
> extern int journal_skip_recovery(journal_t *);
> extern void journal_update_superblock(journal_t *, int);
> extern void __journal_abort_hard (journal_t *);
> -extern void __journal_abort_soft (journal_t *, int);
> extern void journal_abort (journal_t *, int);
> extern int journal_errno (journal_t *);
> extern void journal_ack_err(journal_t *);
> --- linux-2.6.12-rc6-mm1-full/fs/jbd/revoke.c.old 2005-06-14
> 03:58:36.0 +0200
> +++ linux-2.6.12-rc6-mm1-full/fs/jbd/revoke.c 2005-06-14 03:58:41.0
> +0200
> @@ -116,7 +116,8 @@
> (block << (hash_shift - 12))) & (table->hash_size - 1);
> }
>
> -int insert_revoke_hash(journal_t *journal, unsigned long blocknr, tid_t seq)
> +static int insert_revoke_hash(journal_t *journal, unsigned long blocknr,
> + tid_t seq)
> {
> struct list_head *hash_list;
> struct jbd_revoke_record_s *record;
>
> --- linux-2.6.13-rc3-mm1-full/fs/jbd/journal.c.old2005-07-19
> 15:53:16.0 +0200
> +++ linux-2.6.13-rc3-mm1-full/fs/jbd/journal.c2005-07-19
> 15:53:39.0 +0200
> @@ -65,7 +65,6 @@ EXPORT_SYMBOL(journal_set_features);
> EXPORT_SYMBOL(journal_create);
> EXPORT_SYMBOL(journal_load);
> EXPORT_SYMBOL(journal_destroy);
> -EXPORT_SYMBOL(journal_recover);
> EXPORT_SYMBOL(journal_update_superblock);
> EXPORT_SYMBOL(journal_abort);
> EXPORT_SYMBOL(journal_errno);
> @@ -81,6 +80,7 @@ EXPORT_SYMBOL(journal_try_to_free_buffer
> EXPORT_SYMBOL(journal_force_commit);
>
> static int journal_convert_superblock_v1(journal_t *, journal_superblock_t
> *);
> +static void __journal_abort_soft (journal_t *journal, int errno);
>
> /*
> * Helper function used to manage commit timeouts
> @@ -93,16 +93,6 @@ static void commit_timeout(unsigned long
> wake_up_process(p);
> }
>
> -/* Static check for data structure consistency. There's no code
> - * invoked --- we'll just get a linker failure if things aren't right.
> - */
> -void __journal_internal_check(void)
> -{
> - extern void journal_bad_superblock_size(void);
> - if (sizeof(struct journal_superblock_s) != 1024)
> - journal_bad_superblock_size();
> -}
> -
> /*
> * kjournald: The main thread function used to manage a logging device
> * journal.
> @@ -119,16 +109,12 @@ void __journal_internal_check(void)
> *known as checkpointing, and this thread is responsible for that job.
> */
>
> -journal_t *current_journal; // AKPM: debug
> -
> -int kjournald(void *arg)
> +static int kjournald(void *arg)
> {
> journal_t *journal = (journal_t *) arg;
> transaction_t *transaction;
> struct timer_list timer;
>
> - current_journal = journal;
> -
> daemonize("kjournald");
>
> /* Set up an interval timer which can be used to trigger a
> @@ -1441,7 +1427,7 @@ int journal_wipe(journal_t *journal, int
> * device this journal is present.
> */
>
> -const char *journal_dev_name(journal_t *journal, char *buffer)
> +static const char *journal_dev_name(journal_t *journal, char *buffer)
> {
> struct block_device *bdev;
>
> @@ -1487,7 +1473,7 @@ void __journal_abort_hard(journal_t *jou
>
> /* Soft abort: record the abort error status in the journal superblock,
> * but don't do any other IO. */
> -void __journal_abort_soft (journal_t *journal, int errno)
> +static void __journal_abort_soft (journal_t *journal, int errno)
> {
> if (journal->j_flags & JFS_ABORT)
> return;
> @@ -1890,7 +1876,7 @@ EXPORT_SYMBOL(journal_enable_debug);
>
> static struct proc_dir_entry *proc_jbd_debug;
>
> -int read_jbd_debug(char *page, char **start, off_t off,
> +static int read_jbd_debug(char *page, char **start, off_t off,
> int count, int *eof, void *data)
> {
> int ret;
> @@ -1900,7 +1886,7 @@ int read_jbd_debug(char *page, char **st
> return ret;
> }
>
> -int write_jbd_debug(struct file *file, const char __user *buffer,
BUG triggered in Real-Time Preemption, -RT-2.6.12-final-V0.7.51-32
I had the following happen last night while running while running Con's Interbench. Looking back through my log, I do see one other case where the same BUG triggered from running updatedb (2.6.12-RT-V0.7.51-31), but it didn't have all of the ext3 errors that followed this one. I really don't have any idea if this is a problem with RT or upstream. Dell Precision 620 or 630 Dual 933 w/ 512MB ram [EMAIL PROTECTED] ~]$ /sbin/lspci 00:00.0 Host bridge: Intel Corp. 82840 840 (Carmel) Chipset Host Bridge (Hub A)(rev 02) 00:01.0 PCI bridge: Intel Corp. 82840 840 (Carmel) Chipset AGP Bridge (rev 02) 00:02.0 PCI bridge: Intel Corp. 82840 840 (Carmel) Chipset PCI Bridge (Hub B) (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801AA PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801AA IDE (rev 02) 00:1f.2 USB Controller: Intel Corp. 82801AA USB (rev 02) 00:1f.3 SMBus: Intel Corp. 82801AA SMBus (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation NV10GL [Quadro] (rev 10) 02:1f.0 PCI bridge: Intel Corp. 82806AA PCI64 Hub PCI Bridge (rev 03) 03:00.0 PIC: Intel Corp. 82806AA PCI64 Hub Advanced Programmable Interrupt Controller (rev 01) 04:04.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) 04:05.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 04:05.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 04:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 20) ### Relevant portion of the log: Jul 19 23:16:34 porky kernel: ( pdflush-81 |#1): new 62 us maximum-latency wakeup. Jul 19 23:16:34 porky kernel: ( interbench-5583 |#1): new 76 us maximum-latency wakeup. Jul 19 23:16:34 porky kernel: VFS: brelse: Trying to free free buffer Jul 19 23:16:34 porky kernel: swapper/0[CPU#0]: BUG in __brelse at fs/buffer.c:1295 Jul 19 23:16:34 porky kernel: [] dump_stack+0x23/0x30 (20) Jul 19 23:16:34 porky kernel: [] __WARN_ON+0x6b/0x90 (52) Jul 19 23:16:34 porky kernel: [] __brelse+0x4a/0x50 (20) Jul 19 23:16:34 porky kernel: [] invalidate_bh_lru+0x3f/0x80 (20) Jul 19 23:16:34 porky kernel: [] smp_call_function_interrupt+0x48/0x70 (24) Jul 19 23:16:34 porky kernel: [] call_function_interrupt+0x1c/0x24 (60) Jul 19 23:16:34 porky kernel: [] cpu_idle+0x62/0xe0 (40) Jul 19 23:16:34 porky kernel: [] start_kernel+0x1a6/0x220 (32) Jul 19 23:16:34 porky kernel: [] 0xc010020e (1099694095) Jul 19 23:16:34 porky kernel: --- Jul 19 23:16:34 porky kernel: | preempt count: 00010003 ] Jul 19 23:16:34 porky kernel: | 3-level deep critical section nesting: Jul 19 23:16:34 porky kernel: Jul 19 23:16:34 porky kernel: .. [] add_preempt_count+0x1c/0x20 Jul 19 23:16:34 porky kernel: .[] .. ( <= invalidate_bh_lru+0x19/0x80) Jul 19 23:16:34 porky kernel: .. [] add_preempt_count+0x1c/0x20 Jul 19 23:16:34 porky kernel: .[] .. ( <= __WARN_ON+0x27/0x90) Jul 19 23:16:34 porky kernel: .. [] add_preempt_count+0x1c/0x20 Jul 19 23:16:34 porky kernel: .[] .. ( <= print_traces+0x1b/0x50) Jul 19 23:16:34 porky kernel: Jul 19 23:16:34 porky kernel: -- Jul 19 23:16:34 porky kernel: | showing all locks held by: | (swapper/0 [c037fe80, 140]): Jul 19 23:16:34 porky kernel: -- Jul 19 23:16:34 porky kernel: Jul 19 23:16:34 porky kernel: EXT3-fs error (device sdb1): ext3_free_blocks_sb: bit already cleared for block 1440927 Jul 19 23:16:34 porky kernel: Aborting journal on device sdb1. Jul 19 23:16:34 porky kernel: EXT3-fs error (device sdb1): ext3_free_blocks_sb: bit already cleared for block 1440928 Jul 19 23:16:34 porky kernel: EXT3-fs error (device sdb1): ext3_free_blocks_sb: bit already cleared for block 1440929 Jul 19 23:16:34 porky kernel: EXT3-fs error (device sdb1): ext3_free_blocks_sb: bit already cleared for block 1440930 Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_free_blocks_sb: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_free_blocks_sb: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_reserve_inode_write: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_truncate: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_reserve_inode_write: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_orphan_del: Journal has aborted Jul 19 23:17:03 porky kernel: EXT3-fs error (device sdb1) in ext3_reserve_inode_write: Journal has aborted -- kr # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-RT-V0.7.51-32 # Tue Jul 19 10:00:22 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y
Re: How do you accurately determine a process' RAM usage?
Mauricio Lin wrote: Hi Brady, On 7/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: The following shell gets the shared values for the first httpd process: FIRST_HTTPD=`ps -C httpd -o pid= | head -1 | tr -d ' '` HTTPD_STATM_SHARED=$(expr 4 '*' `cut -f3 -d' ' /proc/$FIRST_HTTPD/statm`) HTTPD_SMAPS_SHARED=$(grep Shared /proc/$FIRST_HTTPD/smaps | tr -s ' ' | cut -f2 -d' ' | ( tr '\n' +; echo 0 ) | bc) This shows that "smaps" reports 3060 KB more shared mem than "statm". However adding up all the anon sections in smaps only gives 2456 KB? You are adding up all Shared_Clean and Shared_Dirty as Shared, right? yes. Look at the command I posted. When doing this I also noticed that there are duplicate entries in smaps. Any ideas why? Each pair of address per line indicates the start and end address of a memory area (VMA) such as: b7f7d000-b7f7e000 This means that an specific memory area start on virtual address b7f7d000 and end on b7f7e000 . An mapped file like /lib/ld-2.3.3.so is organized in different memory areas. The memory area can be a text section, data section or bss. So it is normal you find the same filename mapped in more than one memory area. yes. Look at the command I posted. There are multiple entries with the _same addresses_ grep -F - /proc/$FIRST_HTTPD/smaps | sort | uniq -d -c -- Pádraig Brady - http://www.pixelbeat.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/
Re: Synaptics and TrackPoint problems in 2.6.12
On Wed, Jul 20, 2005 at 10:05:13AM -0500, Dmitry Torokhov wrote: > On 7/20/05, Sergey Vlasov <[EMAIL PROTECTED]> wrote: > > Another option is to change the > > PSMOUSE_TRACKPOINT value so that it is less than PSMOUSE_GENPS, > > No, protocol numbers should not be changed as userspace drivers/setups > check them and rely on them being stable. Found that now: psmouse->dev.id.product = psmouse->type; So the type is visible through the input device interface. Probably this should be mentioned in a comment near "enum psmouse_type" - its definition in drivers/input/mouse/psmouse.h looks just like some driver-internal enum. > > In theory, someone could attach a device which uses 6-byte packets to > > the Synaptics pass-thru port; I'm not sure what would happen in this > > case, but with Synaptics confugured for 3-byte packets (as the patch > > below will do) this configuration even has a chance of working. > > I don't think it can support more than 4 byte packets. bytes 0 and 3 > are protocol markers and can't be readily used for transmitting other > protocols data. At least the Synaptics protocol description mentions that its 6-byte protocol was designed to look like two 3-byte PS/2 mouse packets, so that it would work even if the controller looks at those markers; other such protocols are likely to have the same property for the same reason. Now, if the Synaptics touchpad would be able to accept a 6-byte packet from the pass-thru port as two 3-byte packets... pgpUDXsWiQVCK.pgp Description: PGP signature
[PATCH]: Correctly locate RSDP in EBDA
ACPI spec. states that the location of the RSDP structure is found by searching * The first 1 KB of the Extended BIOS Data Area (EBDA). * The BIOS read-only memory space between 0Eh and 0Fh The EBDA scan looks wrong. The patch below against 2.6.12 should correct this. -Udo. --- Calculate correct EBDA address for ACPI RSDP scan. The word at BIOS Data Area 40:0E is the segment address of the EBDA. Signed-off-by: Udo A. Steinberg <[EMAIL PROTECTED]> --- linux-2.6.12/arch/i386/kernel/acpi/boot.c.old 2005-07-20 17:28:32.0 +0200 +++ linux-2.6.12/arch/i386/kernel/acpi/boot.c 2005-07-20 17:31:15.0 +0200 @@ -648,7 +648,7 @@ * Scan memory looking for the RSDP signature. First search EBDA (low * memory) paragraphs and then search upper memory (E-F). */ - rsdp_phys = acpi_scan_rsdp (0, 0x400); + rsdp_phys = acpi_scan_rsdp (*(u16*) 0x40E << 4, 0x400); if (!rsdp_phys) rsdp_phys = acpi_scan_rsdp (0xE, 0x2); pgpGuYcEEEdZD.pgp Description: PGP signature
Re: How do you accurately determine a process' RAM usage?
Hi Brady, On 7/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Mauricio Lin wrote: > > Hi, > > > > On 7/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > >>Andrew Morton wrote: > >> > >>>OK, please let us know how it goes. > >> > >>It went very well. I could find no problems at all. > >>I've updated my script to use the new method, so please merge smaps :) > >>http://www.pixelbeat.org/scripts/ps_mem.py > >> > >>Usually the shared mem reported by /proc/$$/statm > >>is the same as summing all the shared values in in /proc/$$/smaps > >>but there can be large discrepancies. > > > > > > Have you checked how the statm shared is calculated? I guess it does > > something like: > > shared = mm->rss - mm->anon_rss > > yes > > > But in smaps output you can have anonymous area like: > > > > b6e0e000-b6e13000 rw-p > > Size:20 KB > > Rss: 4 KB > > Shared_Clean: 0 KB > > Shared_Dirty: 4 KB > > Private_Clean:0 KB > > Private_Dirty:0 KB > > > > Look that it presents 4 KB of shared value in area considered anonymous. > > > > ANDREW: anon_rss is the rss for anonymous area, right? > > I see your point and I'm not sure. > The following shell gets the shared values for the > first httpd process: > > FIRST_HTTPD=`ps -C httpd -o pid= | head -1 | tr -d ' '` > HTTPD_STATM_SHARED=$(expr 4 '*' `cut -f3 -d' ' /proc/$FIRST_HTTPD/statm`) > HTTPD_SMAPS_SHARED=$(grep Shared /proc/$FIRST_HTTPD/smaps | tr -s ' ' > | cut -f2 -d' ' | ( tr '\n' +; echo 0 ) | bc) > > > This shows that "smaps" reports 3060 KB more shared mem than "statm". > However adding up all the anon sections in smaps only gives 2456 KB? You are adding up all Shared_Clean and Shared_Dirty as Shared, right? > > When doing this I also noticed that there are duplicate > entries in smaps. Any ideas why? Each pair of address per line indicates the start and end address of a memory area (VMA) such as: b7f7d000-b7f7e000 This means that an specific memory area start on virtual address b7f7d000 and end on b7f7e000 . An mapped file like /lib/ld-2.3.3.so is organized in different memory areas. The memory area can be a text section, data section or bss. So it is normal you find the same filename mapped in more than one memory area. You can find more information about VMA on Linux Kernel Development book (chapter 14) written by Robert Love. For instance: > grep -F - /proc/$FIRST_HTTPD/smaps | sort | uniq -d -c > >2 b7f7d000-b7f7e000 r-xp 03:05 246646 > /usr/lib/httpd/modules/mod_auth_anon.so This is a text section. >2 b7f7e000-b7f7f000 rwxp 03:05 246646 > /usr/lib/httpd/modules/mod_auth_anon.so This should be a data section. IMHO, bss section corresponds to the anonymous area where the mapping is not backed by a file. BR, Mauricio Lin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[new] kernel-desktop 2.6.12-1.1398_FC4.desktop_1
Hi, I just released a new version of kernel-desktop. New features are: - Based on FC4 2.6.12-1.1398_FC4 kernel - Include 2.6.12.3pre patch - Include Con Kolivas CK8 patchset (with Staircase11) Kernel-desktop is based on the standard FC3 kernel, with the folowing additions: - NTFS read-only - iNotify (Useful for Beagle, the search engine) - Realtime LSM module (Useful for jack audio server) - Con Kolivas patchset for interactivity Available at http://apt.bea.ki.se/kernel-desktop Happy desktoping! -jec -- Jean-Eric Cuendet Riskpro Technologies SA Av du 14 avril 1b, 1020 Renens Switzerland Principal: +41 21 637 0110 Fax: +41 21 637 01 11 Direct: +41 21 637 0123 E-mail: jean-eric.cuendet at rptec.ch http://www.rptec.ch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a 15 GB file on tmpfs
On 7/20/05, Erik Mouw <[EMAIL PROTECTED]> wrote: > On Wed, Jul 20, 2005 at 01:35:07PM +, Miquel van Smoorenburg wrote: > > In article <[EMAIL PROTECTED]>, > > Erik Mouw <[EMAIL PROTECTED]> wrote: > > >On Wed, Jul 20, 2005 at 02:16:36PM +0200, Bastiaan Naber wrote: > > >AFAIK you can't use a 15 GB tmpfs on i386 because large memory support > > >is basically a hack to support multiple 4GB memory spaces (some VM guru > > >correct me if I'm wrong). > > > > I'm no VM guru but I have a 32 bit machine here with 8 GB of > > memory and 8 GB of swap: > > > > # mount -t tmpfs -o size=$((12*1024*1024*1024)) tmpfs /mnt > > # df > > Filesystem 1K-blocks Used Available Use% Mounted on > > /dev/sda1 19228276 1200132 17051396 7% / > > tmpfs 12582912 0 12582912 0% /mnt > > > > There you go, a 12 GB tmpfs. I haven't tried to create a 12 GB > > file on it, though, since this is a production machine and it > > needs the memory .. > > I stand corrected. > > > So yes that appears to work just fine. > > The question is if it's a good idea to use a 15GB tmpfs on a 32 bit > i386 class machine. I guess a real 64 bit machine will be much faster > in handling suchs amounts of data simply because you don't have to go > through the hurdles needed to address such memory on i386. > > > Erik > On 32bit: you would have to use read() and write() or mmap() munmap() mremap() to perform your own paging, since you can't fit 15GB on a 4GB address space. On 64bit: you would simply mmap() the whole file and you are done. Most probably the cost of programming and debugging the hand-made paging on 32bit machines will cost more than the difference for a 64bit machine. -- Greetz, Antonio Vargas aka winden of network http://wind.codepixel.com/ Las cosas no son lo que parecen, excepto cuando parecen lo que si son. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a 15 GB file on tmpfs
>I want to know if this is possible before spending 10,000 euros on a machine >that has 16 GB of memory. I can get a Dual Opteron 242 with 16G for less than 10K euro. :) Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Synaptics and TrackPoint problems in 2.6.12
On 7/20/05, Sergey Vlasov <[EMAIL PROTECTED]> wrote: > On Tue, 19 Jul 2005 23:40:18 -0400 Stephen Evanchik wrote: > > > I have been receiving a lot of complaints that TrackPoints on > > Synaptics pass-thru ports stopped working with 2.6.12. I retested > > 2.6.9 and 2.6.11-rc3 successfully, I believe 2.6.11.7 may also work > > but that is unconfirmed at this point. > > > > The behavior is always the same .. after sending the read secondary ID > > command, the TrackPoint seems to be disabled from that point forward. > > > > Any ideas? > > Looks like this problem was introduced by the change from PSMOUSE_PS2 to > PSMOUSE_TRACKPOINT in the TrackPoint support patch. The Synaptics > driver needs to know whether the device on the pass-thru port is using > 3-byte or 4-byte packets; however, instead of checking child->pktsize, > it checks child->type >= PSMOUSE_GENPS - and this check is now giving a > wrong result. Therefore the Synaptics driver configures the pass-thru > port for 4-byte packets, and all 3-byte packets from TrackPoint seem to > be thrown away. Oh, yes, that would do it. > The patch below is reported to fix the problem - now the 4-byte mode is > used only if child->pktsize == 4. That is the correct fix. > Another option is to change the > PSMOUSE_TRACKPOINT value so that it is less than PSMOUSE_GENPS, No, protocol numbers should not be changed as userspace drivers/setups check them and rely on them being stable. That's why psmouse->pktsize was introduced to begin with. Unfortunately synaptics pass-through piece was missed and not adjusted. I will add the patch to my tree, thanks! > In theory, someone could attach a device which uses 6-byte packets to > the Synaptics pass-thru port; I'm not sure what would happen in this > case, but with Synaptics confugured for 3-byte packets (as the patch > below will do) this configuration even has a chance of working. I don't think it can support more than 4 byte packets. bytes 0 and 3 are protocol markers and can't be readily used for transmitting other protocols data. -- 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: page allocation/attributes question (i386/x86_64 specific)
Ingo Molnar wrote: > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> Ingo Molnar wrote: >>> there's one problem with the patch: it breaks things that need the >>> low 1MB executable (e.g. APM bios32 calls). It would at a minimum be >>> needed to exclude the BIOS area in 0xd-0xf. >>> >>> Ingo >> >> I wrote it to make everything below 1MB executable, if it isn't RAM >> according to the e820 map, which should include the BIOS area. This >> includes 0xd-0x on my system. Do you think I should >> explicity make 0xd-0xf executable regardless of the e820 map? > > hm ... which portion does this? I'm looking at fixnx2.patch. I > definitely saw a APM bootup crash due to this, but that was on a > 2.4-ish backport of the patch. > > Ingo Oh, sorry, we're talking about two different patches. I sent in a different patch yesterday, because Andi Kleen didn't seem very enthusiastic about fixnx2.patch. Here's the patch that I sent yesterday (attached as file init.c.patch). Thanks Stuart init.c.patch Description: init.c.patch
Re: files_lock deadlock?
Alexander Nyberg wrote: spin_lock_irqsave is only needed when a lock is taken both in normal context and in interrupt context. Clearly this lock is not intended to be taken in interrupt context. According to Rusty's unreliable guide (http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/c214.html) if some code can be called from user context as well as in a softirq, at least spin_lock_bh() is necessary. I am not sure whether that may be true for the code that modifies files_lock. I'll take a look, that spinlock debugging information unfortunately doesn't give too much info :| Thanks! Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: page allocation/attributes question (i386/x86_64 specific)
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Ingo Molnar wrote: > > there's one problem with the patch: it breaks things that need the > > low 1MB executable (e.g. APM bios32 calls). It would at a minimum be > > needed to exclude the BIOS area in 0xd-0xf. > > > > Ingo > > I wrote it to make everything below 1MB executable, if it isn't RAM > according to the e820 map, which should include the BIOS area. This > includes 0xd-0x on my system. Do you think I should explicity > make 0xd-0xf executable regardless of the e820 map? hm ... which portion does this? I'm looking at fixnx2.patch. I definitely saw a APM bootup crash due to this, but that was on a 2.4-ish backport of the patch. 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/
kernel oops, fast ethernet bridge, 2.4.31
Hello, I have bridge firewall (linux box) with three fast ethernet cards (one rtl8139 for management and two e100 for bridge). It is running 2.4.31 kernel and iptables v1.2.11. It works ok about one month. Few weeks ago It started ooopsing. First thought was hardware, but it was replaced with a new one and problem still exist. I'm attaching ksymoops analysis of ooops message. I hope I'll help. Some facts: Traffic over this bridge is about ~30 MBit/sec and every frame is tagged with VID (802.1q). Problem exist also on 2.4.30 kernel. Kernel is patched with ebtables patch. Ooops completeley freezes machine, only hard reset takes effect. Nothing is placed into syslog. The ksymooops analisis is attached as text file. Anyone know this bug/problem ? Regards, Lukasz Spaleniak -- spalek on wroc zigzag pl GCM dpu s: a--- C++ UL P+ L+++ E--- W+ N+ K- w O- M V- PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ lalala Description: Binary data
Re: Weird USB errors on HD
On Tuesday 19 Jul 2005 17:47, Karim Yaghmour wrote: > I have a usb-attached HD that I use from time to time. When it's connected > to my desktop through a hub it works flawlessly. When connected to my Dell > D600 Laptop, however, it sometimes randomly exhibits a loud click (as if > the heads went berzerk) and the device goes unrecognized (i.e. the USB > layer drops the device and then redetects it again; meanwhile there is FS > corruption.) I've noticed my laptop is less able to output the required current for my portable HD than my desktop; either way it's probably not a good idea exceeding the USB specifications for current output @ 5V, so I'd recommend you use a powered hub or external PSU (if the HD supports one). Also a (slightly) nasty but functional trick is to have the power in when the HD initially spins up, then remove the power. Once the drive has spun up it seems to use a lot less power. You can get special USB cables that link two USB ports' 5Vs together in parallel, which seems to help supply the necessary current; after the HD has spun up you can remove the second "dummy" USB connector (my laptop only has two USB ports and I require the second port). -- 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: Automating Kernel Builds
rbt wrote: > I have a script that automatically builds kernels for testing. Would it > be possible to put the kernel version number (2.6.12.3) into the > 'LATEST-IS-VERSION' file on http://www.kernel.org/pub/linux/kernel/v2.6/ > or, is there some other file that traditionally has stored this info? I > searched the repository but could not find one. > > As of now, my script goes to the site and parses the page searching for > a line that contains 'LATEST-IS' and then breaks that line apart and > attempts to extract the kernel version number from it. If > LATEST-IS-VERSION actually contained the version number (2.6.12.3) > instead of being a 0 byte file as it is now, then it my script could > simply read it and not have to do funky html parsing to get the latest > version number ;) Some things from the top of my mind: a) /\d+\.\d+\.\d+(\.\d+)?/ b) use ftp:// c) http://kernel.org/kdist/rss.xml d) http://www.kernel.org/kdist/finger_banner ps: you know http://l4x.org/k/ and kerncomp.sf.net? -- Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: page allocation/attributes question (i386/x86_64 specific)
Ingo Molnar wrote: > there's one problem with the patch: it breaks things that need the > low 1MB executable (e.g. APM bios32 calls). It would at a minimum be > needed to exclude the BIOS area in 0xd-0xf. > > Ingo I wrote it to make everything below 1MB executable, if it isn't RAM according to the e820 map, which should include the BIOS area. This includes 0xd-0x on my system. Do you think I should explicity make 0xd-0xf executable regardless of the e820 map? Thanks Stuart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Synaptics and TrackPoint problems in 2.6.12
On Tue, 19 Jul 2005 23:40:18 -0400 Stephen Evanchik wrote:
> I have been receiving a lot of complaints that TrackPoints on
> Synaptics pass-thru ports stopped working with 2.6.12. I retested
> 2.6.9 and 2.6.11-rc3 successfully, I believe 2.6.11.7 may also work
> but that is unconfirmed at this point.
>
> The behavior is always the same .. after sending the read secondary ID
> command, the TrackPoint seems to be disabled from that point forward.
>
> Any ideas?
Looks like this problem was introduced by the change from PSMOUSE_PS2 to
PSMOUSE_TRACKPOINT in the TrackPoint support patch. The Synaptics
driver needs to know whether the device on the pass-thru port is using
3-byte or 4-byte packets; however, instead of checking child->pktsize,
it checks child->type >= PSMOUSE_GENPS - and this check is now giving a
wrong result. Therefore the Synaptics driver configures the pass-thru
port for 4-byte packets, and all 3-byte packets from TrackPoint seem to
be thrown away.
The patch below is reported to fix the problem - now the 4-byte mode is
used only if child->pktsize == 4. Another option is to change the
PSMOUSE_TRACKPOINT value so that it is less than PSMOUSE_GENPS, however,
I think that checking child->pktsize is more correct in this case.
In theory, someone could attach a device which uses 6-byte packets to
the Synaptics pass-thru port; I'm not sure what would happen in this
case, but with Synaptics confugured for 3-byte packets (as the patch
below will do) this configuration even has a chance of working.
---
Subject: [PATCH] Fix pass-thru port configuration in the Synaptics driver
The Synaptics driver uses child->type to select either 3-byte or 4-byte
packet size for the pass-thru port; this gives wrong results at least
for PSMOUSE_TRACKPOINT. Change the check to use child->pktsize instead.
Signed-off-by: Sergey Vlasov <[EMAIL PROTECTED]>
--- linux-2.6.12/drivers/input/mouse/synaptics.c.alt-synaptics-with-trackpoint
2005-06-17 23:48:29 +0400
+++ linux-2.6.12/drivers/input/mouse/synaptics.c2005-07-09 21:09:01
+0400
@@ -219,7 +219,7 @@ static void synaptics_pass_pt_packet(str
serio_interrupt(ptport, packet[1], 0, NULL);
serio_interrupt(ptport, packet[4], 0, NULL);
serio_interrupt(ptport, packet[5], 0, NULL);
- if (child->type >= PSMOUSE_GENPS)
+ if (child->pktsize == 4)
serio_interrupt(ptport, packet[2], 0, NULL);
} else
serio_interrupt(ptport, packet[1], 0, NULL);
@@ -233,7 +233,7 @@ static void synaptics_pt_activate(struct
/* adjust the touchpad to child's choice of protocol */
if (child) {
- if (child->type >= PSMOUSE_GENPS)
+ if (child->pktsize == 4)
priv->mode |= SYN_BIT_FOUR_BYTE_CLIENT;
else
priv->mode &= ~SYN_BIT_FOUR_BYTE_CLIENT;
pgpjH4BFSX2rM.pgp
Description: PGP signature
