Re: Synaptics probe problem on Acer Travelmate 3004WTMi

[Thomas Sailer]

On Wed, 2005-07-13 at 20:38 +0200, Vojtech Pavlik wrote:

> Also try the usual options ("i8042.nomux=1" and "usb-handoff"). One or
> both may make the problem disappear.

usb-handoff did it, thanks a lot!

Tom


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: High irq load (Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt)

[Herbert Poetzl]

On Thu, Jul 14, 2005 at 04:25:12PM +0200, Peter Osterlund wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
> 
> > On Wed, 13 Jul 2005, Jan Engelhardt wrote:
> > > 
> > > No, some kernel code causes a triple-fault-and-reboot when the HZ is >=
> > > 10KHz. Maybe the highest possible value is 8192 Hz, not sure.
> > 
> > Can you post the triple-fault message? It really shouldn't triple-fault, 
> > although it _will_ obviously spend all time just doing timer interrupts, 
> > so it shouldn't get much (if any) real work done either.
> ...
> > There should be no conceptual "highest possible HZ", although there are 
> > certainly obvious practical limits to it (both on the timer hw itself, and 
> > just the fact that at some point we'll spend all time on the timer 
> > interrupt and won't get anything done..)
> 
> HZ=1 appears to work fine here after some hacks to avoid
> over/underflows in integer arithmetics. gkrellm reports about 3-4% CPU
> usage when the system is idle, on a 3.07 GHz P4.

yep, we've gone up to 20kHz actually, but this
requires some changes to long lasting network
timeouts :)

nevertheless 20Hz-20kHz works fine on 'most'
archs ...

best,
Herbert

> ---
> 
>  Makefile|2 +-
>  arch/i386/kernel/cpu/proc.c |6 ++
>  fs/nfsd/nfssvc.c|2 +-
>  include/linux/jiffies.h |6 ++
>  include/linux/nfsd/stats.h  |4 
>  include/linux/timex.h   |2 +-
>  include/net/tcp.h   |   12 +---
>  init/calibrate.c|   21 +
>  kernel/Kconfig.hz   |6 ++
>  kernel/timer.c  |4 ++--
>  net/ipv4/netfilter/ip_conntrack_proto_tcp.c |2 +-
>  11 files changed, 58 insertions(+), 9 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -1,7 +1,7 @@
>  VERSION = 2
>  PATCHLEVEL = 6
>  SUBLEVEL = 13
> -EXTRAVERSION =-rc3
> +EXTRAVERSION =-rc3-test
>  NAME=Woozy Numbat
>  
>  # *DOCUMENTATION*
> diff --git a/arch/i386/kernel/cpu/proc.c b/arch/i386/kernel/cpu/proc.c
> --- a/arch/i386/kernel/cpu/proc.c
> +++ b/arch/i386/kernel/cpu/proc.c
> @@ -128,9 +128,15 @@ static int show_cpuinfo(struct seq_file 
>x86_cap_flags[i] != NULL )
>   seq_printf(m, " %s", x86_cap_flags[i]);
>  
> +#if HZ <= 5000
>   seq_printf(m, "\nbogomips\t: %lu.%02lu\n\n",
>c->loops_per_jiffy/(50/HZ),
>(c->loops_per_jiffy/(5000/HZ)) % 100);
> +#else
> + seq_printf(m, "\nbogomips\t: %lu.%02lu\n\n",
> +  c->loops_per_jiffy/(50/HZ),
> +  (c->loops_per_jiffy*(HZ/5000)) % 100);
> +#endif
>  
>   return 0;
>  }
> diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c
> --- a/fs/nfsd/nfssvc.c
> +++ b/fs/nfsd/nfssvc.c
> @@ -160,7 +160,7 @@ update_thread_usage(int busy_threads)
>   decile = busy_threads*10/nfsdstats.th_cnt;
>   if (decile>0 && decile <= 10) {
>   diff = nfsd_last_call - prev_call;
> - if ( (nfsdstats.th_usage[decile-1] += diff) >= NFSD_USAGE_WRAP)
> + if ( (nfsdstats.th_usage[decile-1] += diff) >= NFSD_USAGE_WRAP) 
>   nfsdstats.th_usage[decile-1] -= NFSD_USAGE_WRAP;
>   if (decile == 10)
>   nfsdstats.th_fullcnt++;
> diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
> --- a/include/linux/jiffies.h
> +++ b/include/linux/jiffies.h
> @@ -38,6 +38,12 @@
>  # define SHIFT_HZ9
>  #elif HZ >= 768 && HZ < 1536
>  # define SHIFT_HZ10
> +#elif HZ >= 1536 && HZ < 3072
> +# define SHIFT_HZ11
> +#elif HZ >= 3072 && HZ < 6144
> +# define SHIFT_HZ12
> +#elif HZ >= 6144 && HZ < 12288
> +# define SHIFT_HZ13
>  #else
>  # error You lose.
>  #endif
> diff --git a/include/linux/nfsd/stats.h b/include/linux/nfsd/stats.h
> --- a/include/linux/nfsd/stats.h
> +++ b/include/linux/nfsd/stats.h
> @@ -30,7 +30,11 @@ struct nfsd_stats {
>  };
>  
>  /* thread usage wraps very million seconds (approx one fortnight) */
> +#if HZ < 2048
>  #define  NFSD_USAGE_WRAP (HZ*100)
> +#else
> +#define  NFSD_USAGE_WRAP (2048*100)
> +#endif
>  
>  #ifdef __KERNEL__
>  
> diff --git a/include/linux/timex.h b/include/linux/timex.h
> --- a/include/linux/timex.h
> +++ b/include/linux/timex.h
> @@ -90,7 +90,7 @@
>   *
>   * FINENSEC is 1 ns in SHIFT_UPDATE units of the time_phase variable.
>   */
> -#define SHIFT_SCALE 22   /* phase scale (shift) */
> +#define SHIFT_SCALE 25   /* phase scale (shift) */
>  #define SHIFT_UPDATE (SHIFT_KG + MAXTC) /* time offset scale (shift) */
>  #define SHIFT_USEC 16/* frequency offset scale (shift) */
>  #define FINENSEC (1L << (SHIFT_SCALE - 10)) /* ~1 ns in phase units */
> diff --git a/include/net/tcp.h 

Re: Merging relayfs?

[Hareesh Nagarajan]

Tom Zanussi wrote:

Roman Zippel writes:
 > Hi,
 > 
 > On Thu, 14 Jul 2005, Tom Zanussi wrote:
 > 
 > > The netlink control channel seems to work very well, but I can

 > > certainly change the examples to use something different.  Could you
 > > suggest something?
 > 
 > It just looks like a complicated way to do an ioctl, a control file that 
 > you can read/write would be a lot simpler and faster.


You're right - in previous versions, we did use ioctl - we ended up
using netlink as it seemed like least offensive option to most people.
I'll try modifying the example code to use a control file or something
like that instead though.


Having an ioctl() interface will definitely make things less 
complicated. Are the older versions which use ioctl available off the 
relayfs website?


I'm not quite sure if my opinion matters but I'd like to see relayfs 
merged. To me it appears to be the quickest and cleanest way to export 
trace data from the kernel to userspace.


Thanks,

Hareesh Nagarajan
-= Engineering Intern =-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Increasing virtual address space of a process, by treating virtual address's as offsets in secondary memory.

[vamsi krishna]

Hello Alan, mm-hackers,

I have been working this idea of increasing virtual address space of a
process with the help of secondary memory. At first this may seem like
the same virtual memory concept but its not the case.

Imagine all the virtual address the compiler generates while creating
the binary as relocatable offsets on the disk, and the application
specific runtime mmaps and munmaps these dynamically.

I was searching a lot about work on this, and found your reply where
you say that we can increase the virtual address space by mmaping and
munmaping programatically ourself.

So is the bigmem kernel implement this? may be  you can give me some
insight into this.

Some inputs on this would be highly appreciated.

Sincerely,
Vamsi kundeti. 

PS: Please refer this kernel mailing list email.


<--SNIP--->
Re: BIGMEM kernel question
From: Alan Cox ([EMAIL PROTECTED])
Date: Fri Jul 06 2001 - 16:46:16 EST



> Ahh. That makes sense. So how can I change the chunk size from 64k to
> something higher (I assume I could set it to 128k to effectively double
> that 3GB to 6GB)?

I think you misunderstand. If you want more than 3Gb you will have to map and
unmap stuff yourself. You only have 3Gb of per process address space due to
x86 weaknesses (lack of seperate kernel/user spaces without tlb flush
overhead nightmares)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

* Next message: Donald Becker: "Re: why this 1ms delay in
mdio_read? (cont'd from "are ioctl calls supposed to take this
long?")"
* Previous message: Rik van Riel: "Re: BIGMEM kernel question"
* In reply to: Eric Anderson: "Re: BIGMEM kernel question"
* Next in thread: Brian Gerst: "Re: BIGMEM kernel question"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 
<--SNIP->
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

repeated Oops on Kernel 2.6.12.2

[Parminder Chhabra]

Hi,

I get repeated Oops messages on 2.6.12.2. I get the message on inserting a
module that spawns a kernel thread to perform a task on a group of packets.
The thread runs only a stub routine to simulate delay in serving a group of
packets. The above condition is reached before the thread is invoked by the
packets the first time.

I notice from previous postings that there was a problem with the 
free_block in the 2.6.9-rc2 kernel. This appears to be similar 
problem. Any pointers will help.

Unable to handle kernel NULL pointer dereference at virtual address 
  printing eip:
  c0141205
  *pde = 
  Oops: 0002 [#1]
  PREEMPT
  Modules linked in: module1 3c59x eepro100
  CPU:0
  EIP:0060:[]Tainted: P  VLI
  EFLAGS: 00010012   (2.6.12.2)
  EIP is at free_block+0x55/0xe0
  eax: cfa60cc0   ebx: cfa60ec0   ecx: cf077400   edx: 

  EIP is at free_block+0x55/0xe0
  eax: cfa60cc0   ebx: cfa60ec0   ecx: cf077400   edx: 
  esi: cfffd760   edi: 0003   ebp: cfffd76c   esp: cffa3ed8
  ds: 007b   es: 007b   ss: 0068
  Process events/0 (pid: 3, threadinfo=cffa2000 task=cffe2020)
  Stack: 0246 c011dbd5 cfffd77c cfff9150 cfff9140 000b 
cfffd760 c014188f
 cfffd760 cfff9150 000b cfffd7fc cfffd760 cfffd7d0 
0003 c0141963
 cfffd760 cfff9140  cfffd7fc cffa2000 cffa2000 
0296 c05bb444
  Call Trace:
  [] __mod_timer+0x115/0x1c0
  [] drain_array_locked+0x7f/0xb0
  [] cache_reap+0xa3/0x1c0

  [] cache_reap+0x0/0x1c0
  [] default_wake_function+0x0/0x20
  [] default_wake_function+0x0/0x20
  [] worker_thread+0x0/0x2e0
  [] kthread+0xaa/0xb0
  [] kthread+0x0/0xb0
  [] kernel_thread_helper+0x5/0x10
  Code: bc 27 00 00 00 00 8b 44 24 24 8b 15 b0 b4 5b c0 8b 0c b8 8d 
81 00 00 00 40 c1 e8 0c c1 e0 05 8b 5c 02 1c 8b 53 04 8b 03 89 50 04 
<89> 02 8b 43 0c 31 d2 c7 03 00 01 10 00 c7 43 04 00 02 20 00 29
  note: events/0[3] exited with preempt_count 1

The following is the config file with only the [y|m] attributes shown 
for brevity.

CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_X86_PC=y
CONFIG_MPENTIUMIII=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
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_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_SECCOMP=y
CONFIG_PM=y
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_IBM=m
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
CONFIG_MTD=y
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PNP=y
CONFIG_BLK_DEV_FD=y
CONFIG_LBD=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_AHA152X=y
CONFIG_SCSI_AHA1542=y
CONFIG_SCSI_AACRAID=y
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_DEBUG_ENABLE=y
CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
CONFIG_SCSI_AIC7XXX_OLD=y
CONFIG_SCSI_AIC79XX=y
CONFIG_AIC79XX_DEBUG_ENABLE=y
CONFIG_AIC79XX_REG_PRETTY_PRINT=y
CONFIG_SCSI_DPT_I2O=y
CONFIG_SCSI_SATA=y
CONFIG_SCSI_ATA_PIIX=y
CONFIG_SCSI_IPR=m
CONFIG_SCSI_QLA2XXX=y
CONFIG_IEEE1394=y
CONFIG_IEEE1394_OHCI1394=y
CONFIG_IEEE1394_RAWIO=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y

Re: 2.6.12-rc2 and as-iosched

[randy_dunlap]

On 17 Jul 2005 06:06:08 GMT Kenneth Parrish wrote:

> 
>  System: FamilyNet HQ
>Area: Internet-Email, Internet E-mail
>Date: Jul 16 2005  22:45
>From: Kenneth Parrish
>  To: linux-kernel@vger.kernel.org
>Subj: 2.6.12-rc2 and as-iosched
> 
> v2.6.13-rc2 as-iosched.c and /sys/block/hda/queue/iosched/* values differ:
> [..]
> Oops, HZ=250, so correct.

Hi,

My ESP isn't working so well tonight.

What are you trying to report here?
Need more info.

---
~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: Kernel Panic: VFS cannot open a root device

[Fawad Lateef]

On 7/18/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I already done that things , and I still getting these errors ... I dont
> no what to do , and I'm getting desesperated...
> 
>  '>'
>  '>'You should compile in the filesystem (reiserfs?) into the kernel (*
> instead
>  '>'of
>  '>'M), or put the correct module in initrd (usually done by mkinitrd).
> 
>  '>'After that run lilo, and it should boot just fine.
>  '>'
>  '>'Norbert
>  '>'
>  '>'Op zaterdag 16 juli 2005 20:57, schreef u:
>  '>'> > Hi , i have kernel 2.4.29 at slack 10.1 and when I upgrade my kernel
>  '>'to
>  '>'> > 2.6.11 I get these erros on booting
>  '>'> >
>  '>'> > VFS: Cannot open a root device "301" or unknow block
>  '>'> > please append a correct "root" boot option
>  '>'> > KERNEL PANIC :  not syncing; VFS; Unable to mount root fs on
>  '>'> > unknown-block (3,1)
>  '>'> >
>  '>'> > I have compiled my kernel with my IDE support and also with my file
>  '>'> > system support with built-in option.
>  '>'> >
>  '>'> > My LILO.CONF
>  '>'> > image = /boot/vmlinuz-2.6.11
>  '>'> > root = /dev/hda1
>  '>'> > label = 2.6.11
>  '>'> > initrd = /boot/initrd.gz
>  '>'> > read-only
>  '>'> >

I saw this prob when my boot device/partition in the bootloader config
was wrong or the filesystem of my root partition is not compiled as a
kernel image rather compiled as module, so plz try to solve this prob
by selecting your desired filesystem in kernel configuration as Y
rather than M .. I hope this will work

>  '>'> > I'm booting with my image of kernel 2.4.29. i'm 5 days tryng
> to solve
>  '>'> > this problem ...

Upgrading from 2.4.xx kernel series to 2.6.xx series what I found is
that the filesystem must be compiled into the kernel image not as a
module b/c in 2.4.xx filesystem compiled as module also work 

And another thing is that I never succedded in booting the 2.6.xx
kernel __successfully__ compiled from 2.4.xx series (distribution with
default 2.4.xx series kernel like Fedora Core 1 or Redhat Linux 9) and
found that my mouse won't work on 2.6.xx series kernel, but the
distribution with 2.6.xx kernel series by default works fine .


-- 
Fawad Lateef
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

status

[Mail Delivery Subsystem]

ALERT!

This e-mail, in its original form, contained one or more attached files that 
were infected with a virus, worm, or other type of security threat. This e-mail 
was sent from a Road Runner IP address. As part of our continuing initiative to 
stop the spread of malicious viruses, Road Runner scans all outbound e-mail 
attachments. If a virus, worm, or other security threat is found, Road Runner 
cleans or deletes the infected attachments as necessary, but continues to send 
the original message content to the recipient. Further information on this 
initiative can be found at http://help.rr.com/faqs/e_mgsp.html.
Please be advised that Road Runner does not contact the original sender of the 
e-mail as part of the scanning process. Road Runner recommends that if the 
sender is known to you, you contact them directly and advise them of their 
issue. If you do not know the sender, we advise you to forward this message in 
its entirety (including full headers) to the Road Runner Abuse Department, at 
[EMAIL PROTECTED]

Message could not be delivered

file attachment: file.zip

This e-mail in its original form contained one or more attached files that were 
infected with the [EMAIL PROTECTED] virus or worm. They have been removed.
For more information on Road Runner's virus filtering initiative, visit our 
Help & Member Services pages at http://help.rr.com, or the virus filtering 
information page directly at http://help.rr.com/faqs/e_mgsp.html. 

Re: Kernel Panic: VFS cannot open a root device

[porranenhuma]

I already done that things , and I still getting these errors ... I dont
no what to do , and I'm getting desesperated...

 '>'-- Mensagem Original --
 '>'From: Norbert van Nobelen <[EMAIL PROTECTED]>
 '>'To: "GlupFire" <[EMAIL PROTECTED]>
 '>'Subject: Re: Kernel Panic: VFS cannot open a root device
 '>'Date: Sun, 17 Jul 2005 10:16:37 +
 '>'
 '>'
 '>'You should compile in the filesystem (reiserfs?) into the kernel (*
instead
 '>'of 
 '>'M), or put the correct module in initrd (usually done by mkinitrd).

 '>'After that run lilo, and it should boot just fine.
 '>'
 '>'Norbert
 '>'
 '>'Op zaterdag 16 juli 2005 20:57, schreef u:
 '>'> > Hi , i have kernel 2.4.29 at slack 10.1 and when I upgrade my kernel
 '>'to
 '>'> > 2.6.11 I get these erros on booting
 '>'> >
 '>'> > VFS: Cannot open a root device "301" or unknow block
 '>'> > please append a correct "root" boot option
 '>'> > KERNEL PANIC :  not syncing; VFS; Unable to mount root fs on
 '>'> > unknown-block (3,1)
 '>'> >
 '>'> > I have compiled my kernel with my IDE support and also with my file
 '>'> > system support with built-in option.
 '>'> >
 '>'> > My LILO.CONF
 '>'> > image = /boot/vmlinuz-2.6.11
 '>'> > root = /dev/hda1
 '>'> > label = 2.6.11
 '>'> > initrd = /boot/initrd.gz
 '>'> > read-only
 '>'> >
 '>'> > I googled this problem, and I think is a kind of bug, and i tryed
to
 '>'> > patch the kernel with Alan Cox patch 2.6.11-ac7.bzip  and I get
these
 '>'::
 '>'> > bzip2 -dc /usr/src/patch-2.6.11.ac7.bzip | patch -p1 -s
 '>'> > 1 out of hunk FAILED --saving rejects to file Makefike.rej
 '>'> >
 '>'> > and I cat the file Makefile.rej
 '>'> >
 '>'> > ***
 '>'> > *** 1,8 
 '>'> > VERSION = 2
 '>'> > PATCHLEVEL = 6
 '>'> > SUBLEVEL = 11
 '>'> > - EXTRAVERSION =
 '>'> > - NAME=Woozy Numbat
 '>'> >
 '>'> > # *DOCUMENTATION*
 '>'> > # To see a list of typical targets execute "make help"
 '>'> > --- 1,8 
 '>'> > VERSION = 2
 '>'> > PATCHLEVEL = 6
 '>'> > SUBLEVEL = 11
 '>'> > + EXTRAVERSION = ac7
 '>'> > + NAME=AC
 '>'> >
 '>'> > # *DOCUMENTATION*
 '>'> > # To see a list of typical targets execute "make help"
 '>'> >
 '>'> > I'm stuck! The patch dont work fine ( I think the patch is not installed
 '>'> > succesfully on my kernel )
 '>'> > I'm booting with my image of kernel 2.4.29. i'm 5 days tryng
to solve
 '>'> > this problem ...
 '>'> > any kind of help is wellcome... sorry for my english.
 '>'>
 '>'> -
 '>'> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
 '>'in
 '>'> the body of a message to [EMAIL PROTECTED]
 '>'> More majordomo info at  http://vger.kernel.org/majordomo-info.html
 '>'> Please read the FAQ at  http://www.tux.org/lkml/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

sys_times() return value

[Russell King]

Guys,

ARM folk have recently pointed out a problem with sys_times().
When the kernel boots, we set jiffies to -5 minutes.  This causes
sys_times() to return a negative number, which increments through
zero.

However, some negative numbers are used to return error codes.
Hence, there's a period of time when sys_times() returns values
which are indistinguishable from error codes shortly after boot.

This probably only affects 32-bit architectures.  However, one
wonders whether sys_times() needs force_successful_syscall_return().

Also, it appears that glibc does indeed interpret the return value
from sys_times in the way I describe above on at least ARM and x86.
Other architectures may be similarly affected.  Hopefully the ARM
glibc folk will raise a cross-architecture bug in glibc for this.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.10 Kernel Goes Crazy After Resetting MTU

[Francois Romieu]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> :
[2.6.10 + e1000 + page allocation failure]
> Any ideas? 

- upgrade 
- increase vm.min_free_kbytes
- renice kswapd
- Cc: Nick Piggin and netdev@vger.kernel.org

--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] net/bluetooth/: cleanups

[Adrian Bunk]

On Sun, Jul 17, 2005 at 05:58:03PM +0200, Marcel Holtmann wrote:
> Hi Adrian,
> 
> > This patch contains the following cleanups:
> > - remove BT_DMP/bt_dump
> > - remove the following unneeded EXPORT_SYMBOL's:
> >   - hci_core.c: hci_dev_get
> >   - hci_core.c: hci_send_cmd
> >   - hci_event.c: hci_si_event
> 
> is this the same patch you sent me last time? I still have one of your
> cleanup patches in my queue. I simply was to lazy to get them back into
> mainline.

No problem.

This is the same patch.

Since I didn't hear any answer from you I resended it.
Now I do know that you took it.

> Regards
> 
> Marcel

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

[Jon Smirl]

On 7/17/05, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> >
> > struct fb_super_cmap {
> >struct fb_cmap cmap;
> >__u16 red[255];
> >__u16 blue[255];
> >__u16 green[255];
> >__u16 transp[255];
>   ^^^
> I assume you meant 256?
> 
> > }
> >
> > Then adjust the code as need. Have the embedded cmap struct point to
> > the fields in the super_cmap and the drivers don't have to be changed.
> 
> What if your colormap has more than 256 entries?

I meant 256. Does any hardware exist that takes more that 256 entries? 
They are __u16 values but I have never seen hardware that take more
that __u8 either.

-- 
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.12.3 compile error [ld: saa7134-core.c: undefined reference to `register_sound_dsp']

[Adrian Bunk]

On Sun, Jul 17, 2005 at 11:53:39PM +0200, speedy wrote:

> Hello linux-kernel,
> 
>   another link error, with different .config on a different box.
>   .config made with make menuconfig. Disabling the relevant
>   .config entries fixed the bug.
> 
>   p.s. please CC: me in the replies if any, as I'm not subscribed
>   to the list.
> 
>   p.s.2. I suppose Fedora core 4 GCC 4.0.0 is not recommended for
>   compiling the kernel? or not?

A recent gcc from the 3.3 or 3.4 branches is definitely less likely to 
cause problems. That said, problems are still unlikely with the compiler 
you are using.

> * tail of the compiler output:
>...
>   LD  .tmp_vmlinux1
> drivers/built-in.o(.text+0x2197ed): In function `saa7134_initdev':
> saa7134-core.c: undefined reference to `register_sound_dsp'
> drivers/built-in.o(.text+0x219823):saa7134-core.c: undefined reference to 
> `register_sound_mixer'
> drivers/built-in.o(.text+0x21990e):saa7134-core.c: undefined reference to 
> `unregister_sound_dsp'
> drivers/built-in.o(.text+0x219be6): In function `saa7134_finidev':
> saa7134-core.c: undefined reference to `unregister_sound_mixer'
> drivers/built-in.o(.text+0x219bef):saa7134-core.c: undefined reference to 
> `unregister_sound_dsp'
> make: *** [.tmp_vmlinux1] Error 1
>...

Thanks for this report.
This is a known bug.

Workaround:

Say "Y" to
  Device Drivers
Sound
  Sound card support

> Best regards,
>  speedy  mailto:[EMAIL PROTECTED]


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.12.3 compile error

[Alexey Dobriyan]

On Sun, Jul 17, 2005 at 09:43:01PM +0200, speedy wrote:
>   I've got an error while compiling stock kernel 2.6.12.3
>   downloaded from kernel.org.

>   Of course, disabling all of the ATY FB driver entries fixed the
>   bug.

>   LD  .tmp_vmlinux1
> drivers/built-in.o(.text+0x29259): In function `atyfb_xl_init':
> drivers/video/aty/xlinit.c:256: undefined reference to `aty_st_lcd'
> make: *** [.tmp_vmlinux1] Error 1

Is this correct? Or should another defined() be added to
drivers/video/aty/atyfb_base.c:124 ?

Fix build with CONFIG_FB_ATY_XL_INIT=y, CONFIG_FB_ATY_GENERIC_LCD=n

--- linux-vanilla/drivers/video/Kconfig
+++ linux-test/drivers/video/Kconfig
@@ -1029,6 +1029,7 @@ config FB_ATY_GENERIC_LCD
 config FB_ATY_XL_INIT
bool "Rage XL No-BIOS Init support"
depends on FB_ATY_CT
+   select FB_ATY_GENERIC_LCD
help
  Say Y here to support booting a Rage XL without BIOS support.
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.12.3 compile error [ld: saa7134-core.c: undefined reference to `register_sound_dsp']

[speedy]

Hello linux-kernel,

  another link error, with different .config on a different box.
  .config made with make menuconfig. Disabling the relevant
  .config entries fixed the bug.

  p.s. please CC: me in the replies if any, as I'm not subscribed
  to the list.

  p.s.2. I suppose Fedora core 4 GCC 4.0.0 is not recommended for
  compiling the kernel? or not?

* tail of the compiler output:

  AR  lib/lib.a
  LD  arch/i386/lib/built-in.o
  CC  arch/i386/lib/bitops.o
  AS  arch/i386/lib/checksum.o
  CC  arch/i386/lib/delay.o
  AS  arch/i386/lib/getuser.o
  CC  arch/i386/lib/memcpy.o
  AS  arch/i386/lib/putuser.o
  CC  arch/i386/lib/strstr.o
  CC  arch/i386/lib/usercopy.o
  AR  arch/i386/lib/lib.a
  GEN .version
  CHK include/linux/compile.h
  UPD include/linux/compile.h
  CC  init/version.o
  LD  init/built-in.o
  LD  .tmp_vmlinux1
drivers/built-in.o(.text+0x2197ed): In function `saa7134_initdev':
saa7134-core.c: undefined reference to `register_sound_dsp'
drivers/built-in.o(.text+0x219823):saa7134-core.c: undefined reference to 
`register_sound_mixer'
drivers/built-in.o(.text+0x21990e):saa7134-core.c: undefined reference to 
`unregister_sound_dsp'
drivers/built-in.o(.text+0x219be6): In function `saa7134_finidev':
saa7134-core.c: undefined reference to `unregister_sound_mixer'
drivers/built-in.o(.text+0x219bef):saa7134-core.c: undefined reference to 
`unregister_sound_dsp'
make: *** [.tmp_vmlinux1] Error 1

* GCC version: (Fedora Core 4)

Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --enable-shared --enable-threads=posix 
--enable-checking=release --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-libgcj-multifile 
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk 
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre 
--host=i386-redhat-linux
Thread model: posix
gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)

-- 
Best regards,
 speedy  mailto:[EMAIL PROTECTED]

.config
Description: Binary data

2.6.13.3 flooding my logs

[Ralf Hildebrandt]

2.6.13.2 didn't do this, now I'm getting (from dmesg):

PROTO=17 127.0.0.1:53 127.0.0.1:56872 L=56 S=0x00 I=40463 F=0x4000 T=64
ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING 
skb: pf=2 (unowned) dev=lo len=56
PROTO=17 127.0.0.1:56872 127.0.0.1:53 L=56 S=0x00 I=12024 F=0x4000 T=64
ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING 
skb: pf=2 (unowned) dev=lo len=89
PROTO=17 127.0.0.1:53 127.0.0.1:56872 L=89 S=0x00 I=40464 F=0x4000 T=64
ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING 
skb: pf=2 (unowned) dev=lo len=124
PROTO=17 127.0.0.1:53 127.0.0.1:56729 L=124 S=0x00 I=40465 F=0x4000 T=64
ip_local_deliver: bad skb: PRE_ROUTING LOCAL_IN LOCAL_OUT POST_ROUTING 
skb: pf=2 (unowned) dev=lo len=152
PROTO=1 127.0.0.1:0 127.0.0.1:0 L=152 S=0xC0 I=41998 F=0x T=64

What is it? Looks like debug output, but I haven't turned any of that
on.

-- 
_

  Charité - Universitätsmedizin Berlin
_

  Ralf Hildebrandt
   i.A. Geschäftsbereich Informationsmanagement
   Campus Benjamin Franklin
   Hindenburgdamm 30 | Berlin
   Tel. +49 30 450 570155 | Fax +49 30 450 570962
   [EMAIL PROTECTED]
   http://www.charite.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: VIA KT400 + Kernel 2.6.12 + IO-APIC + uhci_hcd = IRQ trouble

[Michel Bouissou]

Le Dimanche 17 Juillet 2005 23:20, Michel Bouissou a écrit :
>
> I just tried an USB flashdisk that "used to work good with 2.4" and that I
> hadn't tried yet in 2.6. It's identified as "high speed" and ehci would
> like to manage it, but it seems I'm out of luck in some other aspect:
>
> totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address
> 25 totor kernel: usb 4-4: device not accepting address 25, error -71
> totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address
> 35 totor kernel: usb 4-4: device not accepting address 35, error -71
[...]
> ...ad nauseam until I unplug the key...
[...]
> Doesn't like the front panel socket ? Let me try another USB socket... Just
> close to my mouse...
>
> totor kernel: usb 4-2: new high speed USB device using ehci_hcd and address
> 16 totor kernel: SCSI subsystem initialized
> totor kernel: Initializing USB Mass Storage driver...

By the way, the front socket that dislikes the USB 2.0 flashdisk (ehci) feels 
perfectly happy if I plug and USB 1.1 flashdisk (uhci)... Feels good also if 
I plug my Digital Camera there... And I've plugged it there thousands of 
times.

Some posts I googled about this kind of errors tend to indicate this would be 
an IRQ mess ;-))

-- 
Michel Bouissou <[EMAIL PROTECTED]> OpenPGP ID 0xDDE8AC6E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

[Jan Engelhardt]

>> struct fb_super_cmap {
>>struct fb_cmap cmap;
>>__u16 red[255];
>>__u16 blue[255];
>>__u16 green[255];
>>__u16 transp[255];
>  ^^^
>I assume you meant 256?

Even if it really was 255, it should probably be made 256 to have things 
aligned <-- if that matters.


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: VIA KT400 + Kernel 2.6.12 + IO-APIC + uhci_hcd = IRQ trouble

[Michel Bouissou]

Le Dimanche 17 Juillet 2005 22:36, vous avez écrit :
> Determining whether or not the system is working shouldn't be hit-or-miss.

Hum, yes, we're not using Windows ;-)

> To start out, try to determine whether each of the UHCI controllers really
> is mapped to IRQ 21.  Do this by booting with no USB devices plugged in,
> and then plugging a full- or low-speed device (like a USB mouse) into each
> of the ports in turn.  Check to make sure it works in each port and that
> that counts for IRQ 21 in /proc/interrupts increase each time.  To make
> this even more reliable you should run the test twice -- you don't have to
> reboot in between.  The first time, rmmod ehci-hcd before plugging in
> anything; the second time modprobe ehci-hcd before plugging.

I'm afraid I won't have time for this today. It's already more than 11 PM here 
and I'm leaving early tomorrow for travel...

But AFAIR, when I performed previous tests, I had tried about every USB socket 
on my computer (I have 6 of them...) to the same result.

> The results you have reported make me a little suspicious.  The best way
> to see whether the EHCI controller really is at fault is to plug in a
> high-speed USB device.  I'm not totally familiar with the operation of
> ehci-hcd, and it's quite possible that plugging in a low- or full-speed
> device would not cause it to generate enough interrupts to be a problem --
> even though you did trigger the fault by plugging in a low-speed mouse --
> but plugging in a high-speed device ought to, provided ehci-hcd is loaded.
>   Again, monitor the numbers in /proc/interrupts to see which is going up:
> IRQ 19 or IRQ 21.

Humm. I'm not sure about what you call a "full speed" device, for when I plug 
my USB scanner, my kernel reports it as a "full speed" USB device, and says 
it's managed by uhci (not ehci):

Jul 17 22:46:42 totor kernel: usb 3-2: new full speed USB device using 
uhci_hcd and address 3

I just tried an USB flashdisk that "used to work good with 2.4" and that I 
hadn't tried yet in 2.6. It's identified as "high speed" and ehci would like 
to manage it, but it seems I'm out of luck in some other aspect:

totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 25
totor kernel: usb 4-4: device not accepting address 25, error -71
totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 35
totor kernel: usb 4-4: device not accepting address 35, error -71
totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 36
totor kernel: usb 4-4: device not accepting address 36, error -71
totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 38
totor kernel: usb 4-4: device not accepting address 38, error -71
totor kernel: usb 4-4: new high speed USB device using ehci_hcd and address 48
totor kernel: usb 4-4: device not accepting address 48, error -71

...ad nauseam until I unplug the key...

Shhh... 

Doesn't like the front panel socket ? Let me try another USB socket... Just 
close to my mouse...

totor kernel: usb 4-2: new high speed USB device using ehci_hcd and address 16
totor kernel: SCSI subsystem initialized
totor kernel: Initializing USB Mass Storage driver...
totor kernel: scsi0 : SCSI emulation for USB Mass Storage devices
totor kernel: usbcore: registered new driver usb-storage
totor kernel: USB Mass Storage support registered.

Looks better, isn't it ?

Now, I checked that I can mount it and see its contents. That's OK.

I'm currently running with IO-APIC disabled, so my interrupts shows as:
[EMAIL PROTECTED] etc]# cat /proc/interrupts
   CPU0
  0:   12540579  XT-PIC  timer
  1:  22352  XT-PIC  i8042
  2:  0  XT-PIC  cascade
  4:  38647  XT-PIC  serial
  7:  18470  XT-PIC  parport0
 10: 863039  XT-PIC  uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, 
eth0, eth1, VIA8233, nvidia
 11: 155832  XT-PIC  ide0, ide1, ide2, ide3, ehci_hcd:usb4
 14: 112325  XT-PIC  ide4
 15: 112334  XT-PIC  ide5
NMI:  0
LOC:   12539533
ERR:350


> The instability you mention is another cause for concern.  It may indicate
> that at some times, or under certain circumstances, the IRQs are routed
> wrongly whereas at others they are routed correctly.  And without any
> changes to the software!  If this is a random hardware fault it may be
> impossible to fix.  (But then why would it be so reliable under 2.4?)

I know that what I'm going to write will look crazy ;-) because it doesn't 
seem to make any sense, but I've noticed a pattern that tends to emerge from 
the different tests I've made with IO-APIC enabled and different 2.6.12 
kernels (patches, boot options, etc...) :

1/ When I'm testing a new kernel for the first time, I usually call it 
manually by typing the different relevant option manually from my grub 
(bootloader) commandline, and most of the times, it works without "losing IRQ 
21".
That's why I had 

Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

[Geert Uytterhoeven]

On Sun, 17 Jul 2005, Jon Smirl wrote:
> On 7/17/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > Resource freeing functions should generally be safe to call with NULL 
> > pointers.
> > Why?
> >  - there is some precedence in the kernel for this for deallocation 
> > functions.
> >  - removes the need for callers to check pointers for NULL.
> >  - space is saved overall by less code to test pointers for NULL all over 
> > the place.
> >  - removes possible NULL pointer dereferences when a caller forgot to check.
> > 
> > This patch makes  fb_dealloc_cmap()  safe to call with a NULL pointer 
> > argument.
> 
> The fb cmap copde would be a lot simpler if it did everything with a
> single allocation instead of five. Make a super cmap struct:
> 
> struct fb_super_cmap {
>struct fb_cmap cmap;
>__u16 red[255];
>__u16 blue[255];
>__u16 green[255];
>__u16 transp[255];
  ^^^
I assume you meant 256?

> }
> 
> Then adjust the code as need. Have the embedded cmap struct point to
> the fields in the super_cmap and the drivers don't have to be changed.

What if your colormap has more than 256 entries?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] EXIT_CONNECTOR and FORK_CONNECTOR must depend on NET

[Adrian Bunk]

If you select some variable, you have to ensure that the dependencies of 
the select'ed variable are fulfilled.

This patch fixes the following link error:

<--  snip  -->

...
  LD  .tmp_vmlinux1
drivers/built-in.o: In function `cn_netlink_send':
: undefined reference to `alloc_skb'
drivers/built-in.o: In function `cn_netlink_send':
: undefined reference to `netlink_broadcast'
drivers/built-in.o: In function `cn_netlink_send':
: undefined reference to `__kfree_skb'
drivers/built-in.o: In function `cn_netlink_send':
: undefined reference to `skb_over_panic'
drivers/built-in.o: In function `cn_rx_skb':
connector.c:(.text+0x20d809): undefined reference to `__kfree_skb'
drivers/built-in.o: In function `cn_input':
connector.c:(.text+0x20d91e): undefined reference to `skb_dequeue'
drivers/built-in.o: In function `cn_init':
connector.c:(.text+0x20dedc): undefined reference to 
`netlink_kernel_create'
connector.c:(.text+0x20df67): undefined reference to `sock_release'
drivers/built-in.o: In function `kfree_skb':
connector.c:(.text+0x20d756): undefined reference to `__kfree_skb'
drivers/built-in.o: In function `cn_rx_skb':
connector.c:(.text+0x20d7c8): undefined reference to `__kfree_skb'
connector.c:(.text+0x20d87e): undefined reference to `__kfree_skb'
drivers/built-in.o: In function `cn_fini':
connector.c:(.text+0x20dfae): undefined reference to `sock_release'
drivers/built-in.o: In function `w1_alloc_dev':
make: *** [.tmp_vmlinux1] Error 1

<--  snip  -->


Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

--- linux-2.6.13-rc3-mm1-full/drivers/connector/Kconfig.old 2005-07-17 
22:35:33.0 +0200
+++ linux-2.6.13-rc3-mm1-full/drivers/connector/Kconfig 2005-07-17 
22:36:12.0 +0200
@@ -1,35 +1,37 @@
 menu "Connector - unified userspace <-> kernelspace linker"
 
 config CONNECTOR
tristate "Connector - unified userspace <-> kernelspace linker"
depends on NET
---help---
  This is unified userspace <-> kernelspace connector working on top
  of the netlink socket protocol.
 
  Connector support can also be built as a module.  If so, the module
  will be called cn.ko.
 
 config EXIT_CONNECTOR
bool "Enable exit connector"
+   depends on NET
select CONNECTOR
default y
---help---
  It adds a connector in kernel/exit.c:do_exit() function. When a exit
  occurs, netlink is used to transfer information about the process and
  its parent. This information can be used by a user space application.
  The exit connector can be enable/disable by sending a message to the
  connector with the corresponding group id.
 
 config FORK_CONNECTOR
bool "Enable fork connector"
+   depends on NET
select CONNECTOR
default y
---help---
  It adds a connector in kernel/fork.c:do_fork() function. When a fork
  occurs, netlink is used to transfer information about the parent and
  its child. This information can be used by a user space application.
  The fork connector can be enable/disable by sending a message to the
  connector with the corresponding group id.
 
 endmenu

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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?

[Tom Zanussi]

bert hubert writes:
 > On Sun, Jul 17, 2005 at 10:43:40AM -0500, Tom Zanussi wrote:
 > 
 > > It is racey - in this mode, there's nothing to keep the kernel from
 > > writing as much as it wants before the user side has a chance to read
 > > any of it.  The only way this can be used safely is to make sure the
 > > kernel side isn't writing anything when the client is reading.  This
 > > would be typical of a flight-recording usage i.e. kernel writes a
 > > bunch of data continuously, then stops and allows the client to read
 > > whatever's in there.
 > 
 > Or by numbering entries written out, when in flight-recording mode you
 > wouldn't want to block the kernel.
 > 
 > >  > In fact, it appears this might even happen in non-overwrite mode.
 > > 
 > > It shouldn't ever be able to happen in non-overwrite mode - if it
 > > did, it would be a bug.  Can you be more specific as to how you see
 > > this happening in this mode?
 > 
 > Yeah - you're right. The misunderstanding is because in both cases
 > (overwrite and non-overwrite) data is lost, except that in one case you lose
 > old data, and in the other new data.

Just to clarify - in either mode, if you don't have a consumer or the
consumer can't keep up with the amount of data being written by the
kernel, you will of course lose data at some point.  Normally you
wouldn't want to lose data; by using non-overwrite mode you're
implicitly letting relayfs know this i.e. if at any point all the
sub-buffers remain unread and the kernel is still trying to write into
them, let the client know (via the buffer-full callback) that this has
happened.  Presumably you would then increase the buffer size or have
the kernel write less etc.

 > 
 > It might be a good idea to document this as well.
 > 

Yes, I'll make it more explicit in the documentation.

 > Btw, I've already uncovered interesting things using relayfs, but I still
 > don't see the case for having it merged :-)

Glad to hear it.  Can you say what if anything would convince you it
should be merged?

 > 
 > Thanks for your answers, I think I get it all now.

No problem, and thanks for patch and other suggestions.

Tom


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13rc3: crypto horribly broken on all 64bit archs

[Herbert Xu]

On Sun, Jul 17, 2005 at 02:20:21PM +0200, Andreas Steinmetz wrote:
> 
> The compiler first does ~((a)-1)) and then expands the unsigned int to
> unsigned long for the & operation. So we end up with only the lower 32
> bits of the address. Who did smoke what to do this? Patch attached.

Thanks for the patch Andreas.  A similar patch will be in the
mainline kernel as soon as everybody is back home from Canada.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: VIA KT400 + Kernel 2.6.12 + IO-APIC + uhci_hcd = IRQ trouble

[Alan Stern]

On Sun, 17 Jul 2005, Michel Bouissou wrote:

> Hi there,
> 
> Natalie Protasevich and Alan Stern have worked a lot on helping me out with a 
> VIA KT400 chipset / kernel 2.6.12 / IO-APIC / IRQ problem "irq 21: nobody 
> cared!", which so far hasn't found its solution.
> 
> Research done with Alan shows that, on my system, the USB 2.0 controller 
> seems 
> to generate interrupts on the IRQ line attributed to the USB 1.1 controller, 
> which isn't supposed to happen, and puzzles the system, when IO-APIC is 
> enabled.
> 
> However, this didn't cause problems with 2.4 series kernels.
> 
> For the time being, there is no solution (Natalie is still investigating 
> this), and it boils down to the following:
> 
> - If I boot with USB 2.0 enabled in BIOS, AND IO-APIC enabled in the kernel, 
> then it badly breaks.
> 
> - If I either disable USB 2.0 in BIOS, or IO-APIC in the kernel, then it's OK.
> 
> I found today the thread between Bjorn Helgaas and Mathieu Bérard on LKML, 
> where Mathieu reported the same problem, and Bjorn advised him to reverse a 
> kernel patch (http://lkml.org/lkml/2005/6/21/243 ).
> 
> Mathieu (I don't have his email address, Bjorn, could you be so kind to 
> forward this message to him) reports that it apparently solved this problem, 
> so I tried to do the same, and reversed the same patch.
> 
> At first boot it seems to solve the issue, but when I rebooted again, it 
> broke 
> again, so this is not the solution -- the problem is not completely stable, 
> sometimes it doesn't happen for some reason unknown to me... But most of the 
> times it _does_ happen :-/
> 
> So this message is to inform different people who have suffered from this 
> same 
> problem, or are working for finding it a fix...
> 
> I'll be on travel for the coming week, and may or may not have occasional 
> access to my email. (Please copy me on answers, as I'm not subscribed to the 
> linux-kernel ML).

Determining whether or not the system is working shouldn't be hit-or-miss.

To start out, try to determine whether each of the UHCI controllers really 
is mapped to IRQ 21.  Do this by booting with no USB devices plugged in, 
and then plugging a full- or low-speed device (like a USB mouse) into each 
of the ports in turn.  Check to make sure it works in each port and that 
that counts for IRQ 21 in /proc/interrupts increase each time.  To make 
this even more reliable you should run the test twice -- you don't have to 
reboot in between.  The first time, rmmod ehci-hcd before plugging in 
anything; the second time modprobe ehci-hcd before plugging.

The results you have reported make me a little suspicious.  The best way
to see whether the EHCI controller really is at fault is to plug in a
high-speed USB device.  I'm not totally familiar with the operation of
ehci-hcd, and it's quite possible that plugging in a low- or full-speed
device would not cause it to generate enough interrupts to be a problem --
even though you did trigger the fault by plugging in a low-speed mouse --
but plugging in a high-speed device ought to, provided ehci-hcd is loaded.  
Again, monitor the numbers in /proc/interrupts to see which is going up:  
IRQ 19 or IRQ 21.

The instability you mention is another cause for concern.  It may indicate 
that at some times, or under certain circumstances, the IRQs are routed 
wrongly whereas at others they are routed correctly.  And without any 
changes to the software!  If this is a random hardware fault it may be 
impossible to fix.  (But then why would it be so reliable under 2.4?)

Do you have a high-speed USB device?  Has it ever worked at high speed 
under 2.6?

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] CKRM_TYPE_SOCKETCLASS must depend on INET

[Adrian Bunk]

CKRM_TYPE_SOCKETCLASS=y, NET=n, INET=n results in the following link 
error:

<--  snip  -->

...
  LD  .tmp_vmlinux1
kernel/built-in.o: In function `cb_sockclass_listen_stop':
ckrm_sockc.c:(.text+0x27e2b): undefined reference to `sk_free'
kernel/built-in.o: In function `ckrm_sock_forced_reclassify_ns':
ckrm_sockc.c:(.text+0x280d5): undefined reference to 
`tcp_v4_lookup_listener'
ckrm_sockc.c:(.text+0x280e4): undefined reference to `lock_sock'
ckrm_sockc.c:(.text+0x28134): undefined reference to `release_sock'
ckrm_sockc.c:(.text+0x28154): undefined reference to `sk_free'
kernel/built-in.o: In function `ckrm_sock_reclassify_class':
ckrm_sockc.c:(.text+0x2851e): undefined reference to `lock_sock'
ckrm_sockc.c:(.text+0x2853b): undefined reference to `release_sock'
make: *** [.tmp_vmlinux1] Error 1

<--  snip  -->


Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

--- linux-2.6.13-rc3-mm1-full/init/Kconfig.old  2005-07-17 21:45:25.0 
+0200
+++ linux-2.6.13-rc3-mm1-full/init/Kconfig  2005-07-17 21:46:03.0 
+0200
@@ -184,7 +184,7 @@
 
 config CKRM_TYPE_SOCKETCLASS
bool "Class Manager for socket groups"
-   depends on CKRM && RCFS_FS
+   depends on INET && CKRM && RCFS_FS
default y
help
  SOCKET provides the extensions for CKRM to track per socket

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

[Jon Smirl]

On 7/17/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> Resource freeing functions should generally be safe to call with NULL 
> pointers.
> Why?
>  - there is some precedence in the kernel for this for deallocation functions.
>  - removes the need for callers to check pointers for NULL.
>  - space is saved overall by less code to test pointers for NULL all over the 
> place.
>  - removes possible NULL pointer dereferences when a caller forgot to check.
> 
> This patch makes  fb_dealloc_cmap()  safe to call with a NULL pointer 
> argument.

The fb cmap copde would be a lot simpler if it did everything with a
single allocation instead of five. Make a super cmap struct:

struct fb_super_cmap {
   struct fb_cmap cmap;
   __u16 red[255];
   __u16 blue[255];
   __u16 green[255];
   __u16 transp[255];
}

Then adjust the code as need. Have the embedded cmap struct point to
the fields in the super_cmap and the drivers don't have to be changed.




-- 
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc3-mm1: mount problems w/ 3ware on dual Opteron

[Rafael J. Wysocki]

On Friday, 15 of July 2005 10:36, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> 
> (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until
> kernel.org syncs up)

Apparently, mount does not work with partitions located on a 3ware RAID
(8006-2PL controller) in a dual-Opteron box (64-bit kernel).

If the kernel is configured with preemption and NUMA, it cannot mount any
"real" filesystems and the output of "mount" is the following:

rootfs on / type ext3 (rw)
/dev/root on / type ext3 (rw)
proc on /proc type proc (rw,nodiratime)
sysfs on /sys type sysfs (rw)
tmpfs on /dev/shm type tmpfs (rw)

(hand-copied from the screen).  I have tried some other combinations (ie.
preemption w/o NUMA, NUMA w/o preemption etc.) and it seems that it works
better with CONFIG_PREEMPT_NONE set, although even it this case some
filesystems are mounted read-only.

The mainline kernels (ie. -rc3 and -rc3-git[1-4]) have no such problems.

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/

Re: [ANNOUNCE] Interbench v0.21

[Con Kolivas]

On Sat, 16 Jul 2005 06:41 pm, Lee Revell wrote:
> On Fri, 2005-07-15 at 14:01 +1000, Con Kolivas wrote:
> > Interbech is a an application is designed to benchmark interactivity in
> > Linux.
> >
> > Version 0.21 update
> >
> > http://ck.kolivas.org/apps/interbench/interbench-0.21.tar.bz2
>
> I would suggest using microseconds for both the RT and non RT tests.  It
> would allow easier comparison of results.  I have a pretty slow machine
> and the max result would only be ~44000 usecs.

I think the significance of usec values from the non-rt tests makes this an 
inappropriate thing to do. The variation in results will be greater than usec 
resolution.

> Also, if it's run with -r and sched_setscheduler fails, rather than
> saying "you must be root for SCHED_FIFO" the error message should
> encourage the user to try a 2.6.12+ kernel and add themselves to the
> "audio" or "realtime" group, and to file a feature request if their
> distro does not support the new realtime rlimit feature.
>
> We should encourage more applications to take advantage of, and distros
> to support, the non-root RT scheduling available in 2.6.12+.  I really
> think the kernel is good enough at this point that we could achieve
> OSX-like multimedia performance on the desktop if more apps like xmms,
> xine, and mplayer were to adopt a multithreaded model with the
> time-critical rendering threads running RT.  XMMS recently adopted such
> a model, but I don't think the audio thread runs SCHED_FIFO yet.  These
> benchmarks imply that it would be a massive improvement.

While I agree with you in principal on getting the rlimit feature working and 
supported, this benchmark is meant to be run in single user mode for most 
reproducible and valid results. However, clearly there will be people using 
it cautiously as a normal user first. I originally did not include the 
information that you need to be root in v.20 and said in the documentation 
"need rt privileges" but within about 5 minutes of posting it I had someone 
not understanding what "unable to get SCHED_FIFO" meant. I guess a more 
verbose message will be required explaining non-root RT as well.

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: 2.6.13-rc3-mm1: a regression

[Rafael J. Wysocki]

On Saturday, 16 of July 2005 23:39, Andrew Morton wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> >
> > On Friday, 15 of July 2005 10:36, Andrew Morton wrote:
> >  > 
> >  > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> >  > 
> >  > (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until
> >  > kernel.org syncs up)
> > 
> >  There seems to be a regression wrt 2.6.13-rc3 which causes my box (Asus 
> > L5D,
> >  Athlon 64 + nForce3) to hang solid during resume from disk on battery 
> > power.
> > 
> >  First, 2.6.13-rc3-mm1 is affected by the problems described at:
> >  http://bugzilla.kernel.org/show_bug.cgi?id=4416
> >  http://bugzilla.kernel.org/show_bug.cgi?id=4665
> >  These problems go away after applying the two attached patches.  Then, the
> >  box resumes on AC power but hangs solid during resume on battery power.
> >  The problem is 100% reproducible and I think it's related to ACPI.
> 
> That recent acpi merge seems to have damaged a number of people...
> 
> Are you able to test Linus's latest -git spanshot?  See if there's a
> difference between -linus and -mm behaviour?

I was afraid you would say so. ;-)

The -rc3-git-[2-4] kernels are unaffected by the problem described, so it seems
to be specific to -rc3-mm1.

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/

Re: rt-preempt and x86_64?

[Alistair John Strachan]

On Sunday 17 Jul 2005 17:29, Michal Schmidt wrote:
> Alistair John Strachan wrote:
> > Hi Ingo,
> >
> > (I searched the list for rt realtime x86_64 x86-64 before posting this,
> > so I hope it's not a duplicate).
> >
> > I've noticed -31 compiles without notable error or warning on x86-64, so
> > I thought maybe it was a valid time to file a bug report about it not
> > working.
> >
> > The machine currently runs 2.6.12 but when booting with PREEMPT_RT mode
> > on the same machine I get:
> >
> > init[1]: segfault at 8010e9c4 rip 8010e9c4 rsp
> > 7fe28018
> > [...]
>
> Do you have latency tracing enabled in the kernel config? Try disabling
> it. It's a known problem that it doesn't work on x86_64.
>

Thanks Michal, this was the problem. Unless x86_64 is going to receive an 
implementation of LATENCY_TRACE soon, it might be an idea to only let this be 
selectable on x86.

(Unfortunately I couldn't use the resulting kernel anyway, as my lirc modules 
hang the system when modprobe'd; it's probably easy even for me to fix if I 
inspect Ingo's rt-preempt patch.)

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: relayfs documentation sucks?

[bert hubert]

On Sun, Jul 17, 2005 at 10:43:40AM -0500, Tom Zanussi wrote:

> It is racey - in this mode, there's nothing to keep the kernel from
> writing as much as it wants before the user side has a chance to read
> any of it.  The only way this can be used safely is to make sure the
> kernel side isn't writing anything when the client is reading.  This
> would be typical of a flight-recording usage i.e. kernel writes a
> bunch of data continuously, then stops and allows the client to read
> whatever's in there.

Or by numbering entries written out, when in flight-recording mode you
wouldn't want to block the kernel.

>  > In fact, it appears this might even happen in non-overwrite mode.
> 
> It shouldn't ever be able to happen in non-overwrite mode - if it
> did, it would be a bug.  Can you be more specific as to how you see
> this happening in this mode?

Yeah - you're right. The misunderstanding is because in both cases
(overwrite and non-overwrite) data is lost, except that in one case you lose
old data, and in the other new data.

It might be a good idea to document this as well.

Btw, I've already uncovered interesting things using relayfs, but I still
don't see the case for having it merged :-)

Thanks for your answers, I think I get it all now.

-- 
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/

2.6.12.3 compile error

[speedy]

Hello linux,

  I've got an error while compiling stock kernel 2.6.12.3
  downloaded from kernel.org. .config is attached. Bug is probably
  the side effect of the partially stuck enter key over the ssh
  session while doing make config. *brown bag with blushed face
  behind*

  Of course, disabling all of the ATY FB driver entries fixed the
  bug.

  p.s. please CC: me in the replies if any, as I'm not subscribed
  to the list.

* tail of the compiler output:

  LD  arch/i386/lib/built-in.o
  CC  arch/i386/lib/bitops.o
  AS  arch/i386/lib/checksum.o
  CC  arch/i386/lib/delay.o
  AS  arch/i386/lib/getuser.o
  CC  arch/i386/lib/memcpy.o
  CC  arch/i386/lib/mmx.o
  AS  arch/i386/lib/putuser.o
  CC  arch/i386/lib/strstr.o
  CC  arch/i386/lib/usercopy.o
  AR  arch/i386/lib/lib.a
  GEN .version
  CHK include/linux/compile.h
  UPD include/linux/compile.h
  CC  init/version.o
  LD  init/built-in.o
  LD  .tmp_vmlinux1
drivers/built-in.o(.text+0x29259): In function `atyfb_xl_init':
drivers/video/aty/xlinit.c:256: undefined reference to `aty_st_lcd'
make: *** [.tmp_vmlinux1] Error 1
  
* GCC version:

rei:~/speedy/linux-2.6.12.3 # gcc -v
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.3/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr 
--with-local-prefix=/usr/local --infodir=/usr/share/info 
--mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada 
--disable-checking --libdir=/usr/lib --enable-libgcj 
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib 
--enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.3 (SuSE Linux)


-- 
Best regards,
 speedy  mailto:[EMAIL PROTECTED]

.config
Description: Binary data

[-mm patch] OCFS2_FS must depend on NET

[Adrian Bunk]

If you select some variable, you have to ensure that the dependencies of 
the select'ed variable are fulfilled.

OCFS2_FS=y, NET=n, INET=y is not a legal combination (resulting in link 
errors).

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

--- linux-2.6.13-rc3-mm1-full/fs/Kconfig.old2005-07-17 21:35:15.0 
+0200
+++ linux-2.6.13-rc3-mm1-full/fs/Kconfig2005-07-17 21:35:54.0 
+0200
@@ -327,11 +327,11 @@
 
 source "fs/xfs/Kconfig"
 
 config OCFS2_FS
tristate "OCFS2 file system support (EXPERIMENTAL)"
-   depends on EXPERIMENTAL && (X86 || IA64 || X86_64 || BROKEN)
+   depends on NET && EXPERIMENTAL && (X86 || IA64 || X86_64 || BROKEN)
select CONFIGFS_FS
select JBD
select CRC32
select INET
help


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linus's git tree broken?

[Andreas Schwab]

"Nathanael Nerode" <[EMAIL PROTECTED]> writes:

> $ cg-clone 
> http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> defaulting to local storage area
> 06:02:39 
> URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/heads/master
>  [41/41] -> "refs/heads/origin" [1]
> progress: 2 objects, 897 bytes
> error: File 2a7e338ec2fc6aac461a11fe8049799e65639166 
> (http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/2a/7e338ec2fc6aac461a11fe8049799e65639166)
>  corrupt

You need to use the rsync method, http does not work with Linus' tree.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kbuild: When checking depmod version, redirect stderr

[Sam Ravnborg]

On Fri, Jul 15, 2005 at 07:56:36AM -0700, Tom Rini wrote:
> When running depmod to check for the correct version number, extra
> output we don't need to see, such as "depmod: QM_MODULES: Function not
> implemented" may show up.  Redirect stderr to /dev/null as the version
> information that we do care about comes to stdout.

Applied, thanks.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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)

[Mark Hahn]

> I suspect that the main problem is that this patch is not a mainstream
> kernel feature that will gain multiple uses, but rather provides
> support for a specific vendor middleware product used by that
> vendor and a few closely allied vendors.  If it were smaller or
> less intrusive, such as a driver, this would not be a big problem.
> That's not the case.

yes, that's the crux.  CKRM is all about resolving conflicting resource 
demands in a multi-user, multi-server, multi-purpose machine.  this is a 
huge undertaking, and I'd argue that it's completely inappropriate for 
*most* servers.  that is, computers are generally so damn cheap that 
the clear trend is towards dedicating a machine to a specific purpose, 
rather than running eg, shell/MUA/MTA/FS/DB/etc all on a single machine.  

this is *directly* in conflict with certain prominent products, such as 
the Altix and various less-prominent Linux-based mainframes.  they're all
about partitioning/virtualization - the big-iron aesthetic of splitting up 
a single machine.  note that it's not just about "big", since cluster-based 
approaches can clearly scale far past big-iron, and are in effect statically
partitioned.  yes, buying a hideously expensive single box, and then chopping 
it into little pieces is more than a little bizarre, and is mainly based
on a couple assumptions:

- that clusters are hard.  really, they aren't.  they are not 
necessarily higher-maintenance, can be far more robust, usually
do cost less.  just about the only bad thing about clusters is 
that they tend to be somewhat larger in size.

- that partitioning actually makes sense.  the appeal is that if 
you have a partition to yourself, you can only hurt yourself.
but it also follows that burstiness in resource demand cannot be 
overlapped without either constantly tuning the partitions or 
infringing on the guarantee.

CKRM is one of those things that could be done to Linux, and will benefit a
few, but which will almost certainly hurt *most* of the community.

let me say that the CKRM design is actually quite good.  the issue is whether 
the extensive hooks it requires can be done (at all) in a way which does 
not disporportionately hurt maintainability or efficiency.

CKRM requires hooks into every resource-allocation decision fastpath:
- if CKRM is not CONFIG, the only overhead is software maintenance.
- if CKRM is CONFIG but not loaded, the overhead is a pointer check.
- if CKRM is CONFIG and loaded, the overhead is a pointer check
and a nontrivial callback.

but really, this is only for CKRM-enforced limits.  CKRM really wants to
change behavior in a more "weighted" way, not just causing an
allocation/fork/packet to fail.  a really meaningful CKRM needs to 
be tightly integrated into each resource manager - effecting each scheduler
(process, memory, IO, net).  I don't really see how full-on CKRM can be 
compiled out, unless these schedulers are made fully pluggable.

finally, I observe that pluggable, class-based resource _limits_ could 
probably be done without callbacks and potentially with low overhead.
but mere limits doesn't meet CKRM's goal of flexible, wide-spread resource 
partitioning within a large, shared machine.

regards, mark hahn.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 NULL short circuit to fb_dealloc_cmap()

[Jesper Juhl]

Resource freeing functions should generally be safe to call with NULL pointers.
Why?
 - there is some precedence in the kernel for this for deallocation functions.
 - removes the need for callers to check pointers for NULL.
 - space is saved overall by less code to test pointers for NULL all over the 
place.
 - removes possible NULL pointer dereferences when a caller forgot to check.

This patch makes  fb_dealloc_cmap()  safe to call with a NULL pointer argument.


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 drivers/video/fbcmap.c |3 +++
 1 files changed, 3 insertions(+)

--- linux-2.6.13-rc3-orig/drivers/video/fbcmap.c2005-06-17 
21:48:29.0 +0200
+++ linux-2.6.13-rc3/drivers/video/fbcmap.c 2005-07-17 20:33:43.0 
+0200
@@ -130,6 +130,9 @@ fail:
 
 void fb_dealloc_cmap(struct fb_cmap *cmap)
 {
+   if (unlikely(!cmap))
+   return;
+
kfree(cmap->red);
kfree(cmap->green);
kfree(cmap->blue);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] fbdev: Update info->cmap when setting cmap from user-/kernelspace.

[Jesper Juhl]

On 7/17/05, Michal Januszewski <[EMAIL PROTECTED]> wrote:
> Hi.
> 
> The fb_info struct, as defined in include/linux/fb.h, contains an element
> that is supposed to hold the current color map:
>   struct fb_cmap cmap;/* Current cmap */
> 
> This cmap is currently never updated when either fb_set_cmap() or
> fb_set_user_cmap() are called. As a result, info->cmap contains the
> default cmap that was set by a device driver/fbcon and a userspace
> application using the FBIOGETCMAP ioctl will not always get the
> *currently* used color map.
> 
> The patch fixes this by making sure the cmap is copied to info->cmap
> after it is set correctly. It moves most of the code that is responsible
> for setting the cmap to fb_set_cmap() and out of fb_set_user_cmap() to
> avoid code-duplication.
> 
> Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
> ---
> 
> diff -Nupr linux-2.6.12-orig/drivers/video/fbcmap.c 
> linux-2.6.12/drivers/video/fbcmap.c
> --- linux-2.6.12-orig/drivers/video/fbcmap.c2005-06-17 21:48:29.0 
> +0200
> +++ linux-2.6.12/drivers/video/fbcmap.c 2005-07-17 13:32:49.0 +0200
> @@ -212,7 +212,7 @@ int fb_cmap_to_user(struct fb_cmap *from
> 
>  int fb_set_cmap(struct fb_cmap *cmap, struct fb_info *info)
>  {
> -   int i, start;
> +   int i, start, rc = 0;
> u16 *red, *green, *blue, *transp;
> u_int hred, hgreen, hblue, htransp = 0x;
> 
> @@ -225,75 +225,51 @@ int fb_set_cmap(struct fb_cmap *cmap, st
> if (start < 0 || (!info->fbops->fb_setcolreg &&

'start' is initialized here by cmap->start which is an unsigned
integer, so testing start for <0 makes little sense.


>   !info->fbops->fb_setcmap))
> return -EINVAL;
> -   if (info->fbops->fb_setcmap)
> -   return info->fbops->fb_setcmap(cmap, info);
> -   for (i = 0; i < cmap->len; i++) {
> -   hred = *red++;
> -   hgreen = *green++;
> -   hblue = *blue++;
> -   if (transp)
> -   htransp = *transp++;
> -   if (info->fbops->fb_setcolreg(start++,
> - hred, hgreen, hblue, htransp,
> - info))
> -   break;
> +   if (info->fbops->fb_setcmap) {
> +   rc = info->fbops->fb_setcmap(cmap, info);
> +   } else {
> +   for (i = 0; i < cmap->len; i++) {
> +   hred = *red++;
> +   hgreen = *green++;
> +   hblue = *blue++;
> +   if (transp)
> +   htransp = *transp++;
> +   if (info->fbops->fb_setcolreg(start++,
> + hred, hgreen, hblue,
> + htransp, info))
> +   break;
> +   }
> }
> -   return 0;
> +   if (rc == 0)
> +   fb_copy_cmap(cmap, >cmap);
> +
> +   return rc;
>  }
> 
>  int fb_set_user_cmap(struct fb_cmap_user *cmap, struct fb_info *info)
>  {
> -   int i, start;
> -   u16 __user *red, *green, *blue, *transp;
> -   u_int hred, hgreen, hblue, htransp = 0x;
> -
> -   red = cmap->red;
> -   green = cmap->green;
> -   blue = cmap->blue;
> -   transp = cmap->transp;
> -   start = cmap->start;
> -
> -   if (start < 0 || (!info->fbops->fb_setcolreg &&
> - !info->fbops->fb_setcmap))
> +   int rc, size = cmap->len * sizeof(u16);
> +   struct fb_cmap umap;
> +
> +   if (cmap->start < 0 || (!info->fbops->fb_setcolreg &&

cmap->start is of type __u32 as far as I can see, so testing it for <0
makes little sense.

> +   !info->fbops->fb_setcmap))
> return -EINVAL;
> 
> -   /* If we can batch, do it */
> -   if (info->fbops->fb_setcmap && cmap->len > 1) {
> -   struct fb_cmap umap;
> -   int size = cmap->len * sizeof(u16);
> -   int rc;
> -
> -   memset(, 0, sizeof(struct fb_cmap));
> -   rc = fb_alloc_cmap(, cmap->len, transp != NULL);
> -   if (rc)
> -   return rc;
> -   if (copy_from_user(umap.red, red, size) ||
> -   copy_from_user(umap.green, green, size) ||
> -   copy_from_user(umap.blue, blue, size) ||
> -   (transp && copy_from_user(umap.transp, transp, size))) {
> -   rc = -EFAULT;
> -   }
> -   umap.start = start;
> -   if (rc == 0)
> -   rc = info->fbops->fb_setcmap(, info);
> -   fb_dealloc_cmap();
> +   memset(, 0, sizeof(struct fb_cmap));
> +   rc = fb_alloc_cmap(, cmap->len, cmap->transp != NULL);
> +   if (rc)
> return rc;
> +   

Re: [RFC - 0/12] NTP cleanup work (v. B4)

[Roman Zippel]

Hi,

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.
>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.
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. 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).

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

VIA KT400 + Kernel 2.6.12 + IO-APIC + uhci_hcd = IRQ trouble

[Michel Bouissou]

Hi there,

Natalie Protasevich and Alan Stern have worked a lot on helping me out with a 
VIA KT400 chipset / kernel 2.6.12 / IO-APIC / IRQ problem "irq 21: nobody 
cared!", which so far hasn't found its solution.

Research done with Alan shows that, on my system, the USB 2.0 controller seems 
to generate interrupts on the IRQ line attributed to the USB 1.1 controller, 
which isn't supposed to happen, and puzzles the system, when IO-APIC is 
enabled.

However, this didn't cause problems with 2.4 series kernels.

For the time being, there is no solution (Natalie is still investigating 
this), and it boils down to the following:

- If I boot with USB 2.0 enabled in BIOS, AND IO-APIC enabled in the kernel, 
then it badly breaks.

- If I either disable USB 2.0 in BIOS, or IO-APIC in the kernel, then it's OK.

I found today the thread between Bjorn Helgaas and Mathieu Bérard on LKML, 
where Mathieu reported the same problem, and Bjorn advised him to reverse a 
kernel patch (http://lkml.org/lkml/2005/6/21/243 ).

Mathieu (I don't have his email address, Bjorn, could you be so kind to 
forward this message to him) reports that it apparently solved this problem, 
so I tried to do the same, and reversed the same patch.

At first boot it seems to solve the issue, but when I rebooted again, it broke 
again, so this is not the solution -- the problem is not completely stable, 
sometimes it doesn't happen for some reason unknown to me... But most of the 
times it _does_ happen :-/

So this message is to inform different people who have suffered from this same 
problem, or are working for finding it a fix...

I'll be on travel for the coming week, and may or may not have occasional 
access to my email. (Please copy me on answers, as I'm not subscribed to the 
linux-kernel ML).

Cheers.

-- 
Michel Bouissou <[EMAIL PROTECTED]> OpenPGP ID 0xDDE8AC6E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: UML build broken on 2.6.13-rc3-mm1

[Sam Ravnborg]

On Sun, Jul 17, 2005 at 10:15:44AM +0200, Miklos Szeredi wrote:
> I get the following build failure on 2.6.13-rc3-mm1.  It builds fine
> on 2.6.13-rc3.
> 
> Can anybody help fixing it?
> 
> Thanks,
> Miklos
>   
> /usr/src/quilt/linux$ make ARCH=um V=1
> if test ! /usr/src/quilt/linux -ef /usr/src/quilt/linux; then \
> /bin/sh /usr/src/quilt/linux/scripts/mkmakefile  \
> /usr/src/quilt/linux /usr/src/quilt/linux 2 6 \
> > /usr/src/quilt/linux/Makefile; \
> echo '  GEN/usr/src/quilt/linux/Makefile';   \
> fi
>   CHK include/linux/version.h
> rm -rf .tmp_versions
> mkdir -p .tmp_versions
> make -f scripts/Makefile.build obj=scripts/basic
> make -f scripts/Makefile.build obj= /mk_sc
> scripts/Makefile.build:13: /Makefile: No such file or directory
> scripts/Makefile.build:64: kbuild: Makefile.build is included improperly
> make[1]: *** No rule to make target `/Makefile'.  Stop.
> make: *** [/mk_sc] Error 2

Olaf just posted a patch fixing this problem. SYS_UTIL_DIRS is brought
back to fix it.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] [PATCH 3/4]generic getblocks() support in mpage_writepages

[Mingming Cao]

Updated patch from Suparna for generic support for cluster pages
together in mapge_writepages() to make use of getblocks() 

---

 linux-2.6.12-ming/fs/buffer.c |   49 -
 linux-2.6.12-ming/fs/ext2/inode.c |   15 -
 linux-2.6.12-ming/fs/ext3/inode.c |   15 +
 linux-2.6.12-ming/fs/ext3/super.c |3 
 linux-2.6.12-ming/fs/hfs/inode.c  |2 
 linux-2.6.12-ming/fs/hfsplus/inode.c  |2 
 linux-2.6.12-ming/fs/jfs/inode.c  |   24 ++
 linux-2.6.12-ming/fs/mpage.c  |  214 ++
 linux-2.6.12-ming/include/linux/buffer_head.h |4 
 linux-2.6.12-ming/include/linux/fs.h  |2 
 linux-2.6.12-ming/include/linux/mpage.h   |   11 -
 linux-2.6.12-ming/include/linux/pagemap.h |3 
 linux-2.6.12-ming/include/linux/pagevec.h |3 
 linux-2.6.12-ming/include/linux/radix-tree.h  |   14 +
 linux-2.6.12-ming/lib/radix-tree.c|   25 ++-
 linux-2.6.12-ming/mm/filemap.c|9 -
 linux-2.6.12-ming/mm/swap.c   |   11 +
 17 files changed, 270 insertions(+), 136 deletions(-)

diff -puN fs/buffer.c~mpage_writepages_getblocks fs/buffer.c
--- linux-2.6.12/fs/buffer.c~mpage_writepages_getblocks 2005-07-15 
00:11:01.0 -0700
+++ linux-2.6.12-ming/fs/buffer.c   2005-07-15 00:11:01.0 -0700
@@ -2509,53 +2509,10 @@ EXPORT_SYMBOL(nobh_commit_write);
  * that it tries to operate without attaching bufferheads to
  * the page.
  */
-int nobh_writepage(struct page *page, get_block_t *get_block,
-   struct writeback_control *wbc)
+int nobh_writepage(struct page *page, get_blocks_t *get_blocks,
+   struct writeback_control *wbc, writepage_t bh_writepage_fn)
 {
-   struct inode * const inode = page->mapping->host;
-   loff_t i_size = i_size_read(inode);
-   const pgoff_t end_index = i_size >> PAGE_CACHE_SHIFT;
-   unsigned offset;
-   void *kaddr;
-   int ret;
-
-   /* Is the page fully inside i_size? */
-   if (page->index < end_index)
-   goto out;
-
-   /* Is the page fully outside i_size? (truncate in progress) */
-   offset = i_size & (PAGE_CACHE_SIZE-1);
-   if (page->index >= end_index+1 || !offset) {
-   /*
-* The page may have dirty, unmapped buffers.  For example,
-* they may have been added in ext3_writepage().  Make them
-* freeable here, so the page does not leak.
-*/
-#if 0
-   /* Not really sure about this  - do we need this ? */
-   if (page->mapping->a_ops->invalidatepage)
-   page->mapping->a_ops->invalidatepage(page, offset);
-#endif
-   unlock_page(page);
-   return 0; /* don't care */
-   }
-
-   /*
-* The page straddles i_size.  It must be zeroed out on each and every
-* writepage invocation because it may be mmapped.  "A file is mapped
-* in multiples of the page size.  For a file that is not a multiple of
-* the  page size, the remaining memory is zeroed when mapped, and
-* writes to that region are not written out to the file."
-*/
-   kaddr = kmap_atomic(page, KM_USER0);
-   memset(kaddr + offset, 0, PAGE_CACHE_SIZE - offset);
-   flush_dcache_page(page);
-   kunmap_atomic(kaddr, KM_USER0);
-out:
-   ret = mpage_writepage(page, get_block, wbc);
-   if (ret == -EAGAIN)
-   ret = __block_write_full_page(inode, page, get_block, wbc);
-   return ret;
+   return mpage_writepage(page, get_blocks, wbc, bh_writepage_fn);
 }
 EXPORT_SYMBOL(nobh_writepage);
 
diff -puN fs/ext2/inode.c~mpage_writepages_getblocks fs/ext2/inode.c
--- linux-2.6.12/fs/ext2/inode.c~mpage_writepages_getblocks 2005-07-15 
00:11:01.0 -0700
+++ linux-2.6.12-ming/fs/ext2/inode.c   2005-07-15 00:11:01.0 -0700
@@ -650,12 +650,6 @@ ext2_nobh_prepare_write(struct file *fil
return nobh_prepare_write(page,from,to,ext2_get_block);
 }
 
-static int ext2_nobh_writepage(struct page *page,
-   struct writeback_control *wbc)
-{
-   return nobh_writepage(page, ext2_get_block, wbc);
-}
-
 static sector_t ext2_bmap(struct address_space *mapping, sector_t block)
 {
return generic_block_bmap(mapping,block,ext2_get_block);
@@ -673,6 +667,12 @@ ext2_get_blocks(struct inode *inode, sec
return ret;
 }
 
+static int ext2_nobh_writepage(struct page *page,
+   struct writeback_control *wbc)
+{
+   return nobh_writepage(page, ext2_get_blocks, wbc, ext2_writepage);
+}
+
 static ssize_t
 ext2_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,
loff_t offset, unsigned long nr_segs)
@@ -687,7 +687,8 @@ ext2_direct_IO(int rw, struct kiocb *ioc
 static int
 ext2_writepages(struct address_space *mapping, struct 

Re: [RFC] [PATCH 0/4]Multiple block allocation and delayed allocation for ext3

[Mingming Cao]

On Sun, 2005-07-17 at 10:40 -0700, Mingming Cao wrote:
> Hi All, 
> 
> Here are the updated patches to support multiple block allocation and
> delayed allocation for ext3 done by me, Badari and Suparna.

Patches are against 2.6.13-rc3.


Mingming

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] [PATCH 4/4]add ext3 writeback writpages

[Mingming Cao]

support multiple block allocation for ext3 writeback mode through writepages().


---

 linux-2.6.12-ming/fs/ext3/inode.c   |  131 
 linux-2.6.12-ming/fs/mpage.c|8 +
 linux-2.6.12-ming/include/linux/mpage.h |   17 
 3 files changed, 153 insertions(+), 3 deletions(-)

diff -puN fs/ext3/inode.c~writepages fs/ext3/inode.c
--- linux-2.6.12/fs/ext3/inode.c~writepages 2005-07-17 17:11:43.239274864 
-0700
+++ linux-2.6.12-ming/fs/ext3/inode.c   2005-07-17 17:11:43.259271824 -0700
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "xattr.h"
 #include "acl.h"
 
@@ -1719,6 +1720,135 @@ out_fail:
return ret;
 }
 
+static int
+ext3_writeback_writepages(struct address_space *mapping,
+   struct writeback_control *wbc)
+{
+   struct inode *inode = mapping->host;
+   const unsigned blkbits = inode->i_blkbits;
+   int err = 0;
+   int ret = 0;
+   int done = 0;
+   unsigned int max_pages_to_cluster = 0;
+   struct pagevec pvec;
+   int nr_pages;
+   pgoff_t index;
+   pgoff_t end = -1;   /* Inclusive */
+   int scanned = 0;
+   int is_range = 0;
+   struct page *page;
+   struct mpageio mio = {
+   .bio = NULL
+   };
+
+   pagevec_init(, 0);
+   if (wbc->sync_mode == WB_SYNC_NONE) {
+   index = mapping->writeback_index; /* Start from prev offset */
+   } else {
+   index = 0;/* whole-file sweep */
+   scanned = 1;
+   }
+   if (wbc->start || wbc->end) {
+   index = wbc->start >> PAGE_CACHE_SHIFT;
+   end = wbc->end >> PAGE_CACHE_SHIFT;
+   is_range = 1;
+   scanned = 1;
+   }
+   max_pages_to_cluster = min(EXT3_MAX_TRANS_DATA, (pgoff_t)PAGEVEC_SIZE);
+
+retry:
+   down_read(>i_alloc_sem);
+   while (!done && (index <= end) &&
+   (nr_pages = pagevec_contig_lookup_tag(, mapping,
+   , PAGECACHE_TAG_DIRTY,
+   min(end - index, max_pages_to_cluster-1) + 1))) {
+   unsigned i;
+
+   scanned = 1;
+   for (i = 0; i < nr_pages; i++) {
+   page = pvec.pages[i];
+
+   lock_page(page);
+
+   if (unlikely(page->mapping != mapping)) {
+   unlock_page(page);
+   break;
+   }
+
+   if (unlikely(is_range) && page->index > end) {
+   unlock_page(page);
+   break;
+   }
+
+   if (wbc->sync_mode != WB_SYNC_NONE)
+   wait_on_page_writeback(page);
+
+   if (PageWriteback(page) ||
+   !clear_page_dirty_for_io(page)) {
+   unlock_page(page);
+   break;
+   }
+   }
+
+   if (i) {
+   unsigned j;
+   handle_t *handle;
+
+   page = pvec.pages[i-1];
+   index = page->index + 1;
+   mio.final_block_in_request =
+   min(index, end) << (PAGE_CACHE_SHIFT - blkbits);
+
+   handle = ext3_journal_start(inode,
+   i + ext3_writepage_trans_blocks(inode));
+
+   if (IS_ERR(handle)) {
+   err = PTR_ERR(handle);
+   done = 1;
+   }
+   for (j = 0; j < i; j++) {
+   page = pvec.pages[j];
+   if (!done) {
+   ret = __mpage_writepage(, page,
+   ext3_writepages_get_blocks, wbc,
+   
ext3_writeback_writepage_helper);
+   if (ret || (--(wbc->nr_to_write) <= 0))
+   done = 1;
+   } else {
+   redirty_page_for_writepage(wbc, page);
+   unlock_page(page);
+   }
+   }
+   if (!err && mio.bio)
+   mio.bio = mpage_bio_submit(WRITE, mio.bio);
+   if (!err)
+   err = ext3_journal_stop(handle);
+   if (!ret) {
+   ret = err;
+   if (ret)
+   done = 1;
+   }
+   }
+   

[RFC] [PATCH 1/4]Multiple block allocation for ext3

[Mingming Cao]

Here is the patch support multiple block allocation for ext3. Current
ext3 allocates one block at a time, not efficient for large sequential
write IO.

This patch implements a simply multiple block allocation with current
ext3.  The basic idea is allocating the 1st block in the existing way,
and attempting to allocate the next adjacent blocks on a  best effort
basis. If contiguous allocation is blocked by an already allocated
block, the current number of free blocks are allocated and no futhur
search is tried.

This implementation makes uses of block reservation. With the knowledge
of how many blocks to allocate, the reservation window size is being
enlargedaccordin before block allocation to increase the chance to get
contiguous blocks.

Previous post of this patch with more description could be found here:
http://marc.theaimsgroup.com/?l=ext2-devel=111471578328685=2 




---

 linux-2.6.12-ming/fs/ext3/balloc.c|  121 +++--
 linux-2.6.12-ming/fs/ext3/inode.c |  380 --
 linux-2.6.12-ming/fs/ext3/xattr.c |3 
 linux-2.6.12-ming/include/linux/ext3_fs.h |2 
 4 files changed, 458 insertions(+), 48 deletions(-)

diff -puN fs/ext3/balloc.c~ext3-get-blocks fs/ext3/balloc.c
--- linux-2.6.12/fs/ext3/balloc.c~ext3-get-blocks   2005-07-14 
21:55:55.110385896 -0700
+++ linux-2.6.12-ming/fs/ext3/balloc.c  2005-07-14 22:40:32.265396472 -0700
@@ -20,6 +20,7 @@
 #include 
 #include 
 
+#defineNBS_DEBUG   0
 /*
  * balloc.c contains the blocks allocation and deallocation routines
  */
@@ -652,9 +653,11 @@ claim_block(spinlock_t *lock, int block,
  */
 static int
 ext3_try_to_allocate(struct super_block *sb, handle_t *handle, int group,
-   struct buffer_head *bitmap_bh, int goal, struct ext3_reserve_window 
*my_rsv)
+   struct buffer_head *bitmap_bh, int goal, unsigned long *count,
+   struct ext3_reserve_window *my_rsv)
 {
int group_first_block, start, end;
+   unsigned long num = 0;
 
/* we do allocation within the reservation window if we have a window */
if (my_rsv) {
@@ -712,8 +715,22 @@ repeat:
goto fail_access;
goto repeat;
}
-   return goal;
+   num++;
+   goal++;
+   if (NBS_DEBUG)
+   printk("ext3_new_block: first block allocated:block %d,num 
%d\n", goal, num);
+   while (num < *count && goal < end
+   && ext3_test_allocatable(goal, bitmap_bh)
+   && claim_block(sb_bgl_lock(EXT3_SB(sb), group), goal, 
bitmap_bh)) {
+   num++;
+   goal++;
+   }
+   *count = num;
+   if (NBS_DEBUG)
+   printk("ext3_new_block: additional block allocated:block %d,num 
%d,goal-num %d\n", goal, num, goal-num);
+   return goal - num;
 fail_access:
+   *count = num;
return -1;
 }
 
@@ -998,6 +1015,28 @@ retry:
goto retry;
 }
 
+static void try_to_extend_reservation(struct ext3_reserve_window_node *my_rsv,
+   struct super_block *sb, int size)
+{
+   struct ext3_reserve_window_node *next_rsv;
+   struct rb_node *next;
+   spinlock_t *rsv_lock = _SB(sb)->s_rsv_window_lock;
+
+   spin_lock(rsv_lock);
+   next = rb_next(_rsv->rsv_node);
+
+   if (!next)
+   my_rsv->rsv_end += size;
+   else {
+   next_rsv = list_entry(next, struct ext3_reserve_window_node, 
rsv_node);
+
+   if ((next_rsv->rsv_start - my_rsv->rsv_end) > size)
+   my_rsv->rsv_end += size;
+   else
+   my_rsv->rsv_end = next_rsv->rsv_start -1 ;
+   }
+   spin_unlock(rsv_lock);
+}
 /*
  * This is the main function used to allocate a new block and its reservation
  * window.
@@ -1023,11 +1062,12 @@ static int
 ext3_try_to_allocate_with_rsv(struct super_block *sb, handle_t *handle,
unsigned int group, struct buffer_head *bitmap_bh,
int goal, struct ext3_reserve_window_node * my_rsv,
-   int *errp)
+   unsigned long *count, int *errp)
 {
unsigned long group_first_block;
int ret = 0;
int fatal;
+   unsigned long num = *count;
 
*errp = 0;
 
@@ -1050,7 +1090,8 @@ ext3_try_to_allocate_with_rsv(struct sup
 * or last attempt to allocate a block with reservation turned on failed
 */
if (my_rsv == NULL ) {
-   ret = ext3_try_to_allocate(sb, handle, group, bitmap_bh, goal, 
NULL);
+   ret = ext3_try_to_allocate(sb, handle, group, bitmap_bh, goal,
+   count, NULL);
goto out;
}
/*
@@ -1080,6 +1121,10 @@ ext3_try_to_allocate_with_rsv(struct sup
while (1) {
if (rsv_is_empty(_rsv->rsv_window) || (ret < 0) ||
!goal_in_my_reservation(_rsv->rsv_window, goal, 

[RFC] [PATCH 2/4]delayed allocation for ext3

[Mingming Cao]

Here is the updated patch from Badari for delayed allocation for ext3.
Delayed allocation defers block allocation from prepare-write time to
page writeout time. 


---

 linux-2.6.12-ming/fs/buffer.c |   13 +
 linux-2.6.12-ming/fs/ext3/inode.c |6 ++
 linux-2.6.12-ming/fs/ext3/super.c |   14 +-
 linux-2.6.12-ming/include/linux/ext3_fs.h |1 +
 4 files changed, 29 insertions(+), 5 deletions(-)

diff -puN include/linux/ext3_fs.h~ext3-delalloc include/linux/ext3_fs.h
--- linux-2.6.12/include/linux/ext3_fs.h~ext3-delalloc  2005-07-14 
23:15:34.861753240 -0700
+++ linux-2.6.12-ming/include/linux/ext3_fs.h   2005-07-14 23:15:34.881750200 
-0700
@@ -373,6 +373,7 @@ struct ext3_inode {
 #define EXT3_MOUNT_BARRIER 0x2 /* Use block barriers */
 #define EXT3_MOUNT_NOBH0x4 /* No bufferheads */
 #define EXT3_MOUNT_QUOTA   0x8 /* Some quota option set */
+ #define EXT3_MOUNT_DELAYED_ALLOC  0xC /* Delayed Allocation */
 
 /* Compatibility, for having both ext2_fs.h and ext3_fs.h included at once */
 #ifndef _LINUX_EXT2_FS_H
diff -puN fs/ext3/inode.c~ext3-delalloc fs/ext3/inode.c
--- linux-2.6.12/fs/ext3/inode.c~ext3-delalloc  2005-07-14 23:15:34.866752480 
-0700
+++ linux-2.6.12-ming/fs/ext3/inode.c   2005-07-14 23:15:34.889748984 -0700
@@ -1340,6 +1340,9 @@ static int ext3_prepare_write(struct fil
handle_t *handle;
int retries = 0;
 
+
+   if (test_opt(inode->i_sb, DELAYED_ALLOC))
+   return __nobh_prepare_write(page, from, to, ext3_get_block, 0);
 retry:
handle = ext3_journal_start(inode, needed_blocks);
if (IS_ERR(handle)) {
@@ -1439,6 +1442,9 @@ static int ext3_writeback_commit_write(s
else
ret = generic_commit_write(file, page, from, to);
 
+   if (test_opt(inode->i_sb, DELAYED_ALLOC))
+   return ret;
+
ret2 = ext3_journal_stop(handle);
if (!ret)
ret = ret2;
diff -puN fs/ext3/super.c~ext3-delalloc fs/ext3/super.c
--- linux-2.6.12/fs/ext3/super.c~ext3-delalloc  2005-07-14 23:15:34.870751872 
-0700
+++ linux-2.6.12-ming/fs/ext3/super.c   2005-07-14 23:15:34.896747920 -0700
@@ -585,7 +585,7 @@ enum {
Opt_resgid, Opt_resuid, Opt_sb, Opt_err_cont, Opt_err_panic, Opt_err_ro,
Opt_nouid32, Opt_check, Opt_nocheck, Opt_debug, Opt_oldalloc, Opt_orlov,
Opt_user_xattr, Opt_nouser_xattr, Opt_acl, Opt_noacl,
-   Opt_reservation, Opt_noreservation, Opt_noload, Opt_nobh,
+   Opt_reservation, Opt_noreservation, Opt_noload, Opt_nobh, 
Opt_delayed_alloc,
Opt_commit, Opt_journal_update, Opt_journal_inum,
Opt_abort, Opt_data_journal, Opt_data_ordered, Opt_data_writeback,
Opt_usrjquota, Opt_grpjquota, Opt_offusrjquota, Opt_offgrpjquota,
@@ -621,6 +621,7 @@ static match_table_t tokens = {
{Opt_noreservation, "noreservation"},
{Opt_noload, "noload"},
{Opt_nobh, "nobh"},
+   {Opt_delayed_alloc, "delalloc"},
{Opt_commit, "commit=%u"},
{Opt_journal_update, "journal=update"},
{Opt_journal_inum, "journal=%u"},
@@ -954,6 +955,10 @@ clear_qf_name:
case Opt_nobh:
set_opt(sbi->s_mount_opt, NOBH);
break;
+   case Opt_delayed_alloc:
+   set_opt(sbi->s_mount_opt, NOBH);
+   set_opt(sbi->s_mount_opt, DELAYED_ALLOC);
+   break;
default:
printk (KERN_ERR
"EXT3-fs: Unrecognized mount option \"%s\" "
@@ -1612,6 +1617,13 @@ static int ext3_fill_super (struct super
clear_opt(sbi->s_mount_opt, NOBH);
}
}
+   if (test_opt(sb, DELAYED_ALLOC)) {
+   if (!(test_opt(sb, DATA_FLAGS) == EXT3_MOUNT_WRITEBACK_DATA)) {
+   printk(KERN_WARNING "EXT3-fs: Ignoring delall option - "
+   "its supported only with writeback mode\n");
+   clear_opt(sbi->s_mount_opt, DELAYED_ALLOC);
+   }
+   }
/*
 * The journal_load will have done any necessary log recovery,
 * so we can safely mount the rest of the filesystem now.
diff -puN fs/buffer.c~ext3-delalloc fs/buffer.c
--- linux-2.6.12/fs/buffer.c~ext3-delalloc  2005-07-14 23:15:34.875751112 
-0700
+++ linux-2.6.12-ming/fs/buffer.c   2005-07-14 23:15:34.903746856 -0700
@@ -2337,8 +2337,8 @@ static void end_buffer_read_nobh(struct 
  * On entry, the page is fully not uptodate.
  * On exit the page is fully uptodate in the areas outside (from,to)
  */
-int nobh_prepare_write(struct page *page, unsigned from, unsigned to,
-   get_block_t *get_block)
+int __nobh_prepare_write(struct page *page, unsigned from, unsigned to,
+   get_block_t *get_block, int create)
 {
   

[RFC] [PATCH 0/4]Multiple block allocation and delayed allocation for ext3

[Mingming Cao]

Hi All, 

Here are the updated patches to support multiple block allocation and
delayed allocation for ext3 done by me, Badari and Suparna.

[PATCH 1/4] -- multiple block allocation for current ext3.
(ext3_get_blocks()).

[PATCH 2/4] -- adding delayed allocation for writeback mode

[PATCH 3/4] -- generic support for cluster pages together in
mapge_writepages() to make use of getblocks() 

[PATCH 4/4] -- support multiple block allocation for ext3 writeback mode
through writepages(). 


Have done initial testing on dbench and tiobench on a 2.6.11 version of
this patch set. Dbench 8 thread throughput result is increased by 20%
with this patch set.

dbench comparison: (ext3-dm represents ext3+thispatchset)
http://www.sudhaa.com/~ram/ols2005presentation/dbench.jpg
tiobench comparison:
http://www.sudhaa.com/~ram/ols2005presentation/tio_seq_write.jpg


Todo:
- bmap() support for delayed allocation
- page reserve flag to indicate the delayed allocation
- ordered mode support for delayed allocation
- "bh" support to enable blocksize = 1k/2k filesystems



Cheers,

Mingming


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [1b/5+1] menu -> menuconfig part 1

[Bodo Eggert]

On Sun, 17 Jul 2005, Bodo Eggert wrote:
> On Sun, 17 Jul 2005, Bodo Eggert wrote:

> > These patches change some menus into menuconfig options.
> > 
> > Reworked to apply to linux-2.6.13-rc3-git3
> 
> Mostly robotic works.

Fixup: unbreak i2c menu

-- 
Fun things to slip into your budget
Half a million dollars for consultants to design a web site that was being
done by an intern in his spare time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: rt-preempt and x86_64?

[Michal Schmidt]

Alistair John Strachan wrote:

Hi Ingo,

(I searched the list for rt realtime x86_64 x86-64 before posting this, so I 
hope it's not a duplicate).


I've noticed -31 compiles without notable error or warning on x86-64, so I 
thought maybe it was a valid time to file a bug report about it not working.


The machine currently runs 2.6.12 but when booting with PREEMPT_RT mode on the 
same machine I get:


init[1]: segfault at 8010e9c4 rip 8010e9c4 rsp 
7fe28018

[...]


Do you have latency tracing enabled in the kernel config? Try disabling 
it. It's a known problem that it doesn't work on x86_64.


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 to make mount follow a symlink at /etc/mtab

[Thomas Hood]

I wrote:
> I attach a patch that modifies the mount program in the util-linux
> package so that if /etc/mtab is a symbolic link (to a location outside
> of /proc) then mount accesses mtab at the target of the symbolic link.

I have discovered a problem with the patch I posted here.  With the
patch applied, umount aborts if it is called without "-n" and the mtab
file is not writable.  This is different from the current behavior of
the umount program and, I have discovered, there are scripts out there
that run umount without "-n" when the root filesystem is mounted
read-only.  So I have changed the patch to make umount not abort if
mtab is not writable and "-n" is not specified.

Get the updated patch at:

   http://panopticon.csustan.edu/thood/readonly-root.html

-- 
Thomas Hood
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] readd missing define to arch/um/Makefile-i386

[Blaisorblade]

On Sunday 17 July 2005 16:52, Olaf Hering wrote:
> New in 2.6.13-rc3-git4:

> scripts/Makefile.build:13: /Makefile: No such file or directory
> scripts/Makefile.build:64: kbuild: Makefile.build is included improperly

> the define was removed, but its still required to build some targets.

> Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
Yes, this patch is the correct fix, also for -rc3-mm1 (which has the same 
problem).

Andrew, I hadn't the time to look at how you fixed up rejects in last merge 
([PATCH] uml: allow building as 32-bit binary on 64bit host)*; the rejects 
came from the SKAS0 merge, and while you were fixing the patch up you deleted 
by mistake the line which is readded in this patch.

*
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=20d0021394c1b070bf04b22c5bc8fdb437edd4c5

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] net/bluetooth/: cleanups

[Marcel Holtmann]

Hi Adrian,

> This patch contains the following cleanups:
> - remove BT_DMP/bt_dump
> - remove the following unneeded EXPORT_SYMBOL's:
>   - hci_core.c: hci_dev_get
>   - hci_core.c: hci_send_cmd
>   - hci_event.c: hci_si_event

is this the same patch you sent me last time? I still have one of your
cleanup patches in my queue. I simply was to lazy to get them back into
mainline.

Regards

Marcel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Merging relayfs?

[Tom Zanussi]

Roman Zippel writes:
 > Hi,
 > 
 > On Thu, 14 Jul 2005, Tom Zanussi wrote:
 > 
 > > The netlink control channel seems to work very well, but I can
 > > certainly change the examples to use something different.  Could you
 > > suggest something?
 > 
 > It just looks like a complicated way to do an ioctl, a control file that 
 > you can read/write would be a lot simpler and faster.

You're right - in previous versions, we did use ioctl - we ended up
using netlink as it seemed like least offensive option to most people.
I'll try modifying the example code to use a control file or something
like that instead though.

 > 
 > >  > Looking through the patch there are still a few areas I'm concerned 
 > > about:
 > >  > - the usage of atomic_t look a little silly, there is only a single 
 > >  > writer and probably needs some cache line optimisations
 > > 
 > > The only things that are atomic are the counts of produced and
 > > consumed buffers and these are only ever updated or read in the slow
 > > buffer-switch path.  They're atomic because if they weren't, wouldn't
 > > it be possible for the client to read an unfinished value if the
 > > producer was in the middle of updating it?
 > 
 > No.
 > 
 > >  > - I would prefer "unsigned int" over just "unsigned"
 > >  > - the padding/commit arrays can be easily managed by the client
 > > 
 > > Yes, I can move them out and update the examples to reflect that, but
 > > I thought that if this was something that most clients would need to
 > > do, it made some sense to keep it in relayfs and avoid duplication in
 > > the clients.
 > 
 > If a lot of clients needs this, there a different ways to do this, e.g. by 
 > introducing some helper functions that clients can use. This way you can 
 > keep the core simple and allow the client to modify its behaviour.

OK, I'll think about the best way to change this.

 > 
 > >  > - overwrite mode can be implemented via the buffer switch callback
 > > 
 > > The buffer switch callback is already where this is handled, unless
 > > you're thinking of something else - one of the first checks in the
 > > buffer switch is relay_buf_full(), which always returns 0 if the
 > > buffer is in overwrite mode.
 > 
 > I mean, relayfs doesn't has to know about this, the client itself can do 
 > it (e.g. via helper functions).

In a previous version, we did something like having the client pass
back a return value from the callback indicating whether or not to
continue or stop.  I can try doing something like that instead again.

Tom


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: relayfs documentation sucks?

[Tom Zanussi]

bert hubert writes:
 > On Sat, Jul 16, 2005 at 06:13:55PM -0500, Tom Zanussi wrote:
 > 
 > > relayfs itself only provides the buffering and file operations along
 > > with the kernel API for clients as documented in
 > > Documentation/filesystems/relayfs.txt.  Applications still need some
 > > kind of communication between the kernel and user space in order to
 > > know when data is ready and how much is ready - the relay-apps stuff
 > > tries to make this easy to do by allowing clients to ignore all those
 > > details.  It happens to use netlink for this, but clients can use
 > > whatever they want to do this communication.
 > 
 > Ok - that is good to know. What is missing from relayfs.txt is a demarcation
 > of which system does what.
 > 
 > As I see it there are three things currently:
 > 
 > 1) Basic relayfs facilities, which only stuff data into N sub-buffers per
 > CPU, but also offer a set of functions that could be called via userspace
 > over some sort of communication channel.
 > 
 > 2) klog which is a thin wrapper over relay_write
 > 
 > 3) relay-app.h which lives in the kernel and communicates with librelay.c in
 > user space, providing that communication.
 > 
 > Is this correct?

Yes.

 > 
 > > Then just run the kleak app, and when it finishes, you should have a
 > > set of files, cpu0l...cpuX in your current directory containing all
 > > the data you've logged.
 > 
 > I've changed the fprintf(stderr, "netlink send error") to perror("netlink
 > send error") and now it prints 'Connection refused', which makes heaps of
 > sense since I did not use relay-app.h, but wrote directly to the
channel.

Right - you need to insmod kleak.ko in order for the netlink socket to
be created in the kernel.

 > 
 > >  > 2) What kind of messages do I need to send/receive?
 > > 
 > > Basically, the daemon needs to know, for a given per-cpu buffer, how
 > > many sub-buffers have been produced and consumed, in order to know
 > > which sections of the mmapped buffer to read.  It also needs to notify
 > 
 > I currently just write away without any userspace component, except that I
 > mmap the entire relayfs file in which I see the four configured sub-buffers.
 > I guess that in override mode that would work? 

Right - this sounds exactly like what overwrite mode is meant for -
flight-recording types of applications, where you don't have an active
reader in userspace and you're interested in the most recent data.  If
you don't have an active reader and use no-overwrite mode, the buffer
will become full when it wraps around the first time, and subsequent
events will be lost (the buffer-full callback will tell you when this
happens).

 > 
 > > The format is whatever the client writes into it - relayfs itself
 > > doesn't impose any format at all.  The client doesn't need librelay.c
 > > to read the data itself - librelay.c is for managing the daemon side
 > > of the application and writing ready data to disk as it becomes
 > > available.  It doesn't know anything about the actual data being written.
 > 
 > Ok - so there is nothing in there except n stretches of data, and some
 > padding? Each write is either IN a sub-buffer or not at all, it doesn't span
 > sub-buffers?

Right, a write will never be split across sub-buffers.

 > 
 > >  > 4) What are the semantics for reading from that file?
 > > 
 > > The file is a buffer broken up into sub-buffers.  The client reads the
 > > sub-buffers it knows are ready directly from the mmapped buffer.
 > > The file can only be mmap()ed - there is no read() available.
 > 
 > Indeed. So the idea is to wait for a ringbuffer to become 'full', read it,
 > and wait for the next one to become full?

Right, as sub-buffers become full, the userspace part of the client
should read them, update the kernel part with how many it just
consumed, and wait around for more.

 > 
 > > BTW, there's also documentation in relay-app.h, don't know if you saw
 > > that.
 > 
 > Yes - but it only makes sense after the 'separation of powers' within
 > relayfs is clear. relayfs.txt talks rather cavalierly of 'clients' and
 > 'calls' but does not make clear this client lives in userspace and can't
 > just call kernel functions.
 > 
 > Please consider the patch below. I'm not 100% sure if everything is correct,
 > but I'd love to know.

Yes, on first reading, it all looks correct, and does a nice job of
clarifying things - thanks for taking the time to do this.  :-)

 > 
 > I'm wondering how relayfs could be operated safely in overwrite mode, btw -
 > who's to say the kernel might not have zoomed past my sub-buffer once I'm
 > notified of the crossing? The padding data I receive might be outdated by
 > then. Sounds racey.

It is racey - in this mode, there's nothing to keep the kernel from
writing as much as it wants before the user side has a chance to read
any of it.  The only way this can be used safely is to make sure the
kernel side isn't writing anything when the client is reading.  This
would be typical 

Re: [PATCH] [0/5+1] menu -> menuconfig part 1

[Bodo Eggert]

On Sun, 17 Jul 2005, Roman Zippel wrote:
> On Sun, 17 Jul 2005, Bodo Eggert wrote:
> 
> > These patches change some menus into menuconfig options.

> I like it, but I would prefer to give it first a bit more exposure in -mm, 
> as it does change the menu structure and the behaviour is little 
> different, so I'd like to see if there's a some feedback first from people 
> using it.

I'll do the -mm patches later.
-- 
"Five second fuses only last three seconds."
-Infantry Journal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [swsusp] encrypt suspend data for easy wiping

[Andreas Steinmetz]

Andrew Morton wrote:
> Pavel Machek <[EMAIL PROTECTED]> wrote:
> 
>>To prevent data gathering from swap after resume you can encrypt the
>>suspend image with a temporary key that is deleted on resume. Note
>>that the temporary key is stored unencrypted on disk while the system
>>is suspended... still it means that saved data are wiped from disk
>>during resume by simply overwritting the key.
> 
[snip]
> err, no.  Please find a way to reduce the ifdeffery.

Andrew,
the attached patches are acked by Pavel and signed off by me. They apply
against 2.6.13-rc3 as well as 2.6.13-rc3-mm1 (with offsets) and are
tested against both kernels. Please consider for inclusion (Pavel
suggested that I could ask).

Note:
For 64 bit systems to work you need the following crypto fix for both
kernels stated above:
http://marc.theaimsgroup.com/?l=linux-kernel=112160294820624=2
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
--- linux-2.6.13-rc3.orig/kernel/power/Kconfig  2005-07-17 16:03:26.0 
+0200
+++ linux-2.6.13-rc3/kernel/power/Kconfig   2005-07-17 10:40:48.0 
+0200
@@ -72,6 +72,18 @@
  suspended image to. It will simply pick the first available swap 
  device.
 
+config SWSUSP_ENCRYPT
+   bool "Encrypt suspend image"
+   depends on SOFTWARE_SUSPEND && CRYPTO=y && (CRYPTO_AES=y || 
CRYPTO_AES_586=y || CRYPTO_AES_X86_64=y)
+   default ""
+   ---help---
+ To prevent data gathering from swap after resume you can encrypt
+ the suspend image with a temporary key that is deleted on
+ resume.
+
+ Note that the temporary key is stored unencrypted on disk while the
+ system is suspended.
+
 config SUSPEND_SMP
bool
depends on HOTPLUG_CPU && X86 && PM
--- linux-2.6.13-rc3.orig/kernel/power/swsusp.c 2005-07-17 16:03:26.0 
+0200
+++ linux-2.6.13-rc3/kernel/power/swsusp.c  2005-07-17 16:09:09.0 
+0200
@@ -31,6 +31,9 @@
  * Alex Badea <[EMAIL PROTECTED]>:
  * Fixed runaway init
  *
+ * Andreas Steinmetz <[EMAIL PROTECTED]>:
+ * Added encrypted suspend option
+ *
  * More state savers are welcome. Especially for the scsi layer...
  *
  * For TODOs,FIXMEs also look in Documentation/power/swsusp.txt
@@ -71,8 +74,16 @@
 #include 
 #include 
 
+#include 
+#include 
+#include 
+
 #include "power.h"
 
+#define CIPHER "aes"
+#define MAXKEY 32
+#define MAXIV  32
+
 /* References to section boundaries */
 extern const void __nosave_begin, __nosave_end;
 
@@ -103,7 +114,8 @@
 #define SWSUSP_SIG "S1SUSPEND"
 
 static struct swsusp_header {
-   char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
+   char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
+   u8 key_iv[MAXKEY+MAXIV];
swp_entry_t swsusp_info;
charorig_sig[10];
charsig[10];
@@ -129,6 +141,131 @@
 static unsigned short swapfile_used[MAX_SWAPFILES];
 static unsigned short root_swap;
 
+static int write_page(unsigned long addr, swp_entry_t * loc);
+static int bio_read_page(pgoff_t page_off, void * page);
+
+static u8 key_iv[MAXKEY+MAXIV];
+
+#ifdef CONFIG_SWSUSP_ENCRYPT
+
+static int crypto_init(int mode, void **mem)
+{
+   int error = 0;
+   int len;
+   char *modemsg;
+   struct crypto_tfm *tfm;
+
+   modemsg = mode ? "suspend not possible" : "resume not possible";
+
+   tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+   if(!tfm) {
+   printk(KERN_ERR "swsusp: no tfm, %s\n", modemsg);
+   error = -EINVAL;
+   goto out;
+   }
+
+   if(MAXKEY < crypto_tfm_alg_min_keysize(tfm)) {
+   printk(KERN_ERR "swsusp: key buffer too small, %s\n", modemsg);
+   error = -ENOKEY;
+   goto fail;
+   }
+
+   if (mode)
+   get_random_bytes(key_iv, MAXKEY+MAXIV);
+
+   len = crypto_tfm_alg_max_keysize(tfm);
+   if (len > MAXKEY)
+   len = MAXKEY;
+
+   if (crypto_cipher_setkey(tfm, key_iv, len)) {
+   printk(KERN_ERR "swsusp: key setup failure, %s\n", modemsg);
+   error = -EKEYREJECTED;
+   goto fail;
+   }
+
+   len = crypto_tfm_alg_ivsize(tfm);
+
+   if (MAXIV < len) {
+   printk(KERN_ERR "swsusp: iv buffer too small, %s\n", modemsg);
+   error = -EOVERFLOW;
+   goto fail;
+   }
+
+   crypto_cipher_set_iv(tfm, key_iv+MAXKEY, len);
+
+   *mem=(void *)tfm;
+
+   goto out;
+
+fail:  crypto_free_tfm(tfm);
+out:   return error;
+}
+
+static __inline__ void crypto_exit(void *mem)
+{
+   crypto_free_tfm((struct crypto_tfm *)mem);
+}
+
+static __inline__ int crypto_write(struct pbe *p, void *mem)
+{
+   int error = 0;
+   struct scatterlist src, dst;
+
+   src.page   = virt_to_page(p->address);
+   src.offset = 0;
+   src.length = PAGE_SIZE;
+   dst.page   = virt_to_page((void *)_header);
+   dst.offset = 0;
+ 

Re: 2.6.13-rc3-mm1 (ckrm)

[Paul Jackson]

Andrew, replying to Christoph, about CKRM:
> What, in your opinion, makes it "obviously unmergeable"?

Thanks to some earlier discussions on the relation of CKRM with
cpusets, I've spent some time looking at CKRM.  I'm not Christoph,
but perhaps my notes will be of some use in this matter.

CKRM is big, it's difficult for us mere mortals to understand, and it
has attracted only limited review - inadequate review in proportion
to its size and impact.  I tried, and failed, sometime last year to
explain some of what I found difficult to grasp of CKRM to the folks
doing it.  See further an email thread entitled:

Classes: 1) what are they, 2) what is their name?

http://sourceforge.net/mailarchive/forum.php?thread_id=5328162_id=35191

on the ckrm-tech@lists.sourceforge.net email list between Aug 14 and
Aug 27, 2004

As to its size, CKRM is in a 2.6.5 variant of SuSE that I happen to be
building just now for other reasons.  The source files that have 'ckrm'
in the pathname, _not_ counting Doc files, total 13044 lines of text.
The CONFIG_CKRM* config options add 144 Kbytes to the kernel text.

The CKRM patches in 2.6.13-rc3-mm1 are similar in size.  These patch
files total 14367 lines of text.

It is somewhat intrusive in the areas it controls, such as some large
ifdef's in kernel/sched.c.

The sched hooks may well impact the cost of maintaining the sched code,
which is always a hotbed of Linux kernel development.  However others
who work in that area will have to speak to that concern.

I tried just now to read through the ckrm hooks in fork, to see
what sort of impact they might have on scalability on large systems.
But I gave up after a couple layers of indirection.  I saw several
atomic counters and a couple of spinlocks that I suspect (not at all
sure) lay on the fork main code path.  I'd be surprised if this didn't
impact scalability.  Earlier, according to my notes, I saw mention of
lmbench results in the OLS 2004 slides, indicating a several percent
cost of available cpu cycles.

A feature of this size and impact needs to attract a fair bit of
discussion, because it is essential to a variety of people, or because
it is intriguing in some other way.

I suspect that the main problem is that this patch is not a mainstream
kernel feature that will gain multiple uses, but rather provides
support for a specific vendor middleware product used by that
vendor and a few closely allied vendors.  If it were smaller or
less intrusive, such as a driver, this would not be a big problem.
That's not the case.

The threshold of what is sufficient review needs to be set rather high
for such a patch, quite a bit higher than I believe it has obtained
so far.  It will not be easy for them to obtain that level of review,
until they get better at arousing the substained interest of other
kernel developers.

There may well be multiple end users and applications depending on
CKRM, but I have not been able to identify how many separate vendors
provide middleware that depends on CKRM.  I am guessing that only one
vendor has a serious middleware software product that provides full
CKRM support.  Acceptance of CKRM would be easier if multiple competing
middleware vendors were using it.  It is also a concern that CKRM
is not really usable for its primary intended purpose except if it
is accompanied by this corresponding middleware, which I presume is
proprietary code.  I'd like to see a persuasive case that CKRM is
useful and used on production systems not running substantial sole
sourced proprietary middleware.

The development and maintenance costs so far of CKRM appear (to
this outsider) to have been substantial, which suggests that the
maintenance costs of CKRM once in the kernel would be non-trivial.
Given the size of the project, its impact on kernel code, and the
rather limited degree to which developers outside of the CKRM project
have participated in CKRM's development or review, this could either
leave the Linux kernel overly dependent on one vendor for maintaining
CKRM, or place an undo maintenance burden on other kernel developers.

CKRM is in part a generalization and descendent of what I call fair
share schedulers.  For example, the fork hooks for CKRM include a
forkrates controller, to slow down the rate of forking of tasks using
too much resources.

No doubt the CKRM experts are already familiar with these, but for
the possible benefit of other readers:

  UNICOS Resource Administration - Chapter 4. Fair-share Scheduler
  
http://oscinfo.osc.edu:8080/dynaweb/all/004-2302-001/@Generic__BookTextView/22883

  SHARE II -- A User Administration and Resource Control System for UNIX
  http://www.c-side.com/c/papers/lisa-91.html

  Solaris Resource Manager White Paper
  http://wwws.sun.com/software/resourcemgr/wp-mixed/

  ON THE PERFORMANCE IMPACT OF FAIR SHARE SCHEDULING
  http://www.cs.umb.edu/~eb/goalmode/cmg2000final.htm

  A Fair Share Scheduler, J. Kay and P. Lauder
  Communications of the ACM, January 1988, 

[PATCH] use select in sound/isa/Kconfig

[Bodo Eggert]

In sound/isa/Kconfig, select ISAPNP and depend on ISAPNP are intermixed, 
resulting in funny behaviour. (Soundcarts get selectable if other 
soundcards are selected).

This patch changes the "depend on ISAPNP"s to select.

 sound/isa/Kconfig |   15 ++-
 1 files changed, 10 insertions(+), 5 deletions(-)

Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>

--- a/sound/isa/Kconfig 2005-07-17 08:10:20.0 +0200
+++ b/sound/isa/Kconfig 2005-07-17 16:57:53.0 +0200
@@ -15,7 +15,8 @@ config SND_CS4231_LIB
 
 config SND_AD1816A
tristate "Analog Devices SoundPort AD1816A"
-   depends on SND && ISAPNP
+   depends on SND
+   select ISAPNP
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_PCM
@@ -80,7 +81,8 @@ config SND_CS4236
 
 config SND_ES968
tristate "Generic ESS ES968 driver"
-   depends on SND && ISAPNP
+   depends on SND
+   select ISAPNP
select SND_MPU401_UART
select SND_PCM
help
@@ -291,7 +293,8 @@ config SND_WAVEFRONT
 
 config SND_ALS100
tristate "Avance Logic ALS100/ALS120"
-   depends on SND && ISAPNP
+   depends on SND
+   select ISAPNP
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_PCM
@@ -304,7 +307,8 @@ config SND_ALS100
 
 config SND_AZT2320
tristate "Aztech Systems AZT2320"
-   depends on SND && ISAPNP
+   depends on SND
+   select ISAPNP
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_CS4231_LIB
@@ -328,7 +332,8 @@ config SND_CMI8330
 
 config SND_DT019X
tristate "Diamond Technologies DT-019X, Avance Logic ALS-007"
-   depends on SND && ISAPNP
+   depends on SND
+   select ISAPNP
select SND_OPL3_LIB
select SND_MPU401_UART
select SND_PCM

-- 
Funny quotes:
3. On the other hand, you have different fingers.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] VIDEO_BT848: remove not required part of the help text

[Adrian Bunk]

Things that are already expressed through the dependencies don't have to 
be mentioned in the help text.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

--- linux-2.6.13-rc3-mm1-full/drivers/media/video/Kconfig.old   2005-07-17 
16:15:00.0 +0200
+++ linux-2.6.13-rc3-mm1-full/drivers/media/video/Kconfig   2005-07-17 
16:15:34.0 +0200
@@ -10,33 +10,30 @@
 config VIDEO_BT848
tristate "BT848 Video For Linux"
depends on VIDEO_DEV && PCI && I2C
select I2C_ALGOBIT
select FW_LOADER
select VIDEO_BTCX
select VIDEO_BUF
select VIDEO_IR
select VIDEO_TUNER
select VIDEO_TVEEPROM
---help---
  Support for BT848 based frame grabber/overlay boards. This includes
  the Miro, Hauppauge and STB boards. Please read the material in
   for more information.
 
- If you say Y or M here, you need to say Y or M to "I2C support" and
- "I2C bit-banging interfaces" in the device drivers section.
-
  To compile this driver as a module, choose M here: the
  module will be called bttv.
 
 config VIDEO_PMS
tristate "Mediavision Pro Movie Studio Video For Linux"
depends on VIDEO_DEV && ISA
help
  Say Y if you have such a thing.
 
  To compile this driver as a module, choose M here: the
  module will be called pms.
 
 config VIDEO_PLANB
tristate "PlanB Video-In on PowerMac"
depends on PPC_PMAC && VIDEO_DEV && BROKEN
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] fix unusual placement of inline keyword in hpet

[Adrian Bunk]

Trivial path to get rid of 
drivers/char/hpet.c:102: warning: `inline' is not at beginning of declaration
drivers/char/hpet.c:109: warning: `inline' is not at beginning of declaration
when building with gcc -W

Patch makes no actual code changes, just reduces the number of warnings 
peole have to sift through when using -W to look for trouble spots.
Please apply.


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was sent by Jesper Juhl on:
- 25 Nov 2004

--- linux-2.6.10-rc2-bk9-orig/drivers/char/hpet.c   2004-11-17 
01:19:33.0 +0100
+++ linux-2.6.10-rc2-bk9/drivers/char/hpet.c2004-11-25 00:51:20.0 
+0100
@@ -99,14 +99,14 @@ static struct hpets *hpets;
 #endif
 
 #ifndef readq
-static unsigned long long __inline readq(void __iomem *addr)
+static inline unsigned long long readq(void __iomem *addr)
 {
return readl(addr) | (((unsigned long long)readl(addr + 4)) << 32LL);
 }
 #endif
 
 #ifndef writeq
-static void __inline writeq(unsigned long long v, void __iomem *addr)
+static inline void writeq(unsigned long long v, void __iomem *addr)
 {
writel(v & 0x, addr);
writel(v >> 32, addr + 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/

[2.6 patch] i386: add missing Kconfig help text

[Adrian Bunk]

There's no help text for CONFIG_DEBUG_STACKOVERFLOW - add one.

Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was sent by Jesper Juhl on:
- 22 Dec 2004

--- linux-2.6.10-rc3-bk15-orig/arch/i386/Kconfig.debug  2004-12-06 
22:24:16.0 +0100
+++ linux-2.6.10-rc3-bk15/arch/i386/Kconfig.debug   2004-12-22 
23:25:38.0 +0100
@@ -18,6 +18,9 @@
 config DEBUG_STACKOVERFLOW
bool "Check for stack overflows"
depends on DEBUG_KERNEL
+   help
+ This option will cause messages to be printed if free stack space
+ drops below a certain limit.
 
 config KPROBES
bool "Kprobes"


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] fs/fscache/: cleanups

[Adrian Bunk]

This patch contains the following cleanups:
- make needlessly global code static
- main.c: remove the unused global variable fscache_debug

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 20 Jun 2005
- 23 Apr 2005

 fs/fscache/cookie.c  |   19 +++
 fs/fscache/fscache-int.h |   11 ---
 fs/fscache/main.c|2 --
 3 files changed, 15 insertions(+), 17 deletions(-)

--- linux-2.6.12-rc2-mm3-full/fs/fscache/fscache-int.h.old  2005-04-23 
02:53:14.0 +0200
+++ linux-2.6.12-rc2-mm3-full/fs/fscache/fscache-int.h  2005-04-23 
02:55:11.0 +0200
@@ -22,17 +22,6 @@
 
 extern void fscache_cookie_init_once(void *_cookie, kmem_cache_t *cachep, 
unsigned long flags);
 
-extern void __fscache_cookie_put(struct fscache_cookie *cookie);
-
-static inline void fscache_cookie_put(struct fscache_cookie *cookie)
-{
-   BUG_ON(atomic_read(>usage) <= 0);
-
-   if (atomic_dec_and_test(>usage))
-   __fscache_cookie_put(cookie);
-
-}
-
 /*/
 /*
  * debug tracing
--- linux-2.6.12-rc2-mm3-full/fs/fscache/cookie.c.old   2005-04-23 
02:53:26.0 +0200
+++ linux-2.6.12-rc2-mm3-full/fs/fscache/cookie.c   2005-04-23 
02:55:39.0 +0200
@@ -12,14 +12,25 @@
 #include 
 #include "fscache-int.h"
 
-LIST_HEAD(fscache_netfs_list);
-LIST_HEAD(fscache_cache_list);
-DECLARE_RWSEM(fscache_addremove_sem);
+static LIST_HEAD(fscache_netfs_list);
+static LIST_HEAD(fscache_cache_list);
+static DECLARE_RWSEM(fscache_addremove_sem);
 
 kmem_cache_t *fscache_cookie_jar;
 
 static void fscache_withdraw_node(struct fscache_cache *cache,
  struct fscache_node *node);
+static void __fscache_cookie_put(struct fscache_cookie *cookie);
+
+
+static inline void fscache_cookie_put(struct fscache_cookie *cookie)
+{
+   BUG_ON(atomic_read(>usage) <= 0);
+
+   if (atomic_dec_and_test(>usage))
+   __fscache_cookie_put(cookie);
+
+}
 
 /*/
 /*
@@ -925,7 +936,7 @@
 /*
  * destroy a cookie
  */
-void __fscache_cookie_put(struct fscache_cookie *cookie)
+static void __fscache_cookie_put(struct fscache_cookie *cookie)
 {
struct fscache_search_result *srch;
 
--- linux-2.6.12-rc2-mm3-full/fs/fscache/main.c.old 2005-04-23 
02:55:48.0 +0200
+++ linux-2.6.12-rc2-mm3-full/fs/fscache/main.c 2005-04-23 02:56:22.0 
+0200
@@ -16,8 +16,6 @@
 #include 
 #include "fscache-int.h"
 
-int fscache_debug = 0;
-
 static int fscache_init(void);
 static void fscache_exit(void);
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] net/bluetooth/: cleanups

[Adrian Bunk]

This patch contains the following cleanups:
- remove BT_DMP/bt_dump
- remove the following unneeded EXPORT_SYMBOL's:
  - hci_core.c: hci_dev_get
  - hci_core.c: hci_send_cmd
  - hci_event.c: hci_si_event

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 5 May 2005

 drivers/bluetooth/hci_bcsp.c  |2 --
 drivers/bluetooth/hci_h4.c|5 -
 drivers/bluetooth/hci_ldisc.c |2 --
 drivers/bluetooth/hci_usb.c   |2 --
 include/net/bluetooth/bluetooth.h |8 
 net/bluetooth/hci_core.c  |2 --
 net/bluetooth/hci_event.c |1 -
 net/bluetooth/lib.c   |   25 -
 8 files changed, 47 deletions(-)

--- linux-2.6.12-rc3-mm2-full/net/bluetooth/hci_core.c.old  2005-05-03 
10:38:58.0 +0200
+++ linux-2.6.12-rc3-mm2-full/net/bluetooth/hci_core.c  2005-05-03 
10:47:49.0 +0200
@@ -299,7 +299,6 @@
read_unlock(_dev_list_lock);
return hdev;
 }
-EXPORT_SYMBOL(hci_dev_get);
 
 /*  Inquiry support  */
 static void inquiry_cache_flush(struct hci_dev *hdev)
@@ -1042,7 +1045,6 @@
 
return 0;
 }
-EXPORT_SYMBOL(hci_send_cmd);
 
 /* Get data from the previously sent command */
 void *hci_sent_cmd_data(struct hci_dev *hdev, __u16 ogf, __u16 ocf)
--- linux-2.6.12-rc3-mm2-full/net/bluetooth/hci_event.c.old 2005-05-03 
10:48:13.0 +0200
+++ linux-2.6.12-rc3-mm2-full/net/bluetooth/hci_event.c 2005-05-03 
10:48:21.0 +0200
@@ -1040,4 +1040,3 @@
hci_send_to_sock(hdev, skb);
kfree_skb(skb);
 }
-EXPORT_SYMBOL(hci_si_event);

--- linux-2.6.12-rc3-mm3-full/include/net/bluetooth/bluetooth.h.old 
2005-05-05 17:36:52.0 +0200
+++ linux-2.6.12-rc3-mm3-full/include/net/bluetooth/bluetooth.h 2005-05-05 
17:40:41.0 +0200
@@ -57,12 +57,6 @@
 #define BT_DBG(fmt, arg...)  printk(KERN_INFO "%s: " fmt "\n" , __FUNCTION__ , 
## arg)
 #define BT_ERR(fmt, arg...)  printk(KERN_ERR  "%s: " fmt "\n" , __FUNCTION__ , 
## arg)
 
-#ifdef HCI_DATA_DUMP
-#define BT_DMP(buf, len) bt_dump(__FUNCTION__, buf, len)
-#else
-#define BT_DMP(D...)
-#endif
-
 extern struct proc_dir_entry *proc_bt;
 
 /* Connection and socket states */
@@ -174,8 +168,6 @@
return n;
 }
 
-void bt_dump(char *pref, __u8 *buf, int count);
-
 int bt_err(__u16 code);
 
 #endif /* __BLUETOOTH_H */
--- linux-2.6.12-rc3-mm3-full/net/bluetooth/lib.c.old   2005-05-05 
17:37:20.0 +0200
+++ linux-2.6.12-rc3-mm3-full/net/bluetooth/lib.c   2005-05-05 
17:37:30.0 +0200
@@ -34,31 +34,6 @@
 
 #include 
 
-void bt_dump(char *pref, __u8 *buf, int count)
-{
-   char *ptr;
-   char line[100];
-   unsigned int i;
-
-   printk(KERN_INFO "%s: dump, len %d\n", pref, count);
-
-   ptr = line;
-   *ptr = 0;
-   for (i = 0; i < count; i++) {
-   ptr += sprintf(ptr, " %2.2X", buf[i]);
-
-   if (i && !((i + 1) % 20)) {
-   printk(KERN_INFO "%s:%s\n", pref, line);
-   ptr = line;
-   *ptr = 0;
-   }
-   }
-
-   if (line[0])
-   printk(KERN_INFO "%s:%s\n", pref, line);
-}
-EXPORT_SYMBOL(bt_dump);
-
 void baswap(bdaddr_t *dst, bdaddr_t *src)
 {
unsigned char *d = (unsigned char *) dst;
--- linux-2.6.12-rc3-mm3-full/drivers/bluetooth/hci_h4.c.old2005-05-05 
17:38:19.0 +0200
+++ linux-2.6.12-rc3-mm3-full/drivers/bluetooth/hci_h4.c2005-05-05 
17:39:42.0 +0200
@@ -57,8 +57,6 @@
 #ifndef CONFIG_BT_HCIUART_DEBUG
 #undef  BT_DBG
 #define BT_DBG( A... )
-#undef  BT_DMP
-#define BT_DMP( A... )
 #endif
 
 /* Initialize protocol */
@@ -125,7 +123,6 @@
 
BT_DBG("len %d room %d", len, room);
if (!len) {
-   BT_DMP(h4->rx_skb->data, h4->rx_skb->len);
hci_recv_frame(h4->rx_skb);
} else if (len > room) {
BT_ERR("Data length is too large");
@@ -169,8 +166,6 @@
case H4_W4_DATA:
BT_DBG("Complete data");
 
-   BT_DMP(h4->rx_skb->data, h4->rx_skb->len);
-
hci_recv_frame(h4->rx_skb);
 
h4->rx_state = H4_W4_PACKET_TYPE;
--- linux-2.6.12-rc3-mm3-full/drivers/bluetooth/hci_ldisc.c.old 2005-05-05 
17:38:51.0 +0200
+++ linux-2.6.12-rc3-mm3-full/drivers/bluetooth/hci_ldisc.c 2005-05-05 
17:39:54.0 +0200
@@ -57,8 +57,6 @@
 #ifndef CONFIG_BT_HCIUART_DEBUG
 #undef  BT_DBG
 #define BT_DBG( A... )
-#undef  BT_DMP
-#define BT_DMP( A... )
 #endif
 
 static int reset = 0;
--- linux-2.6.12-rc3-mm3-full/drivers/bluetooth/hci_bcsp.c.old  2005-05-05 
17:40:04.0 +0200
+++ linux-2.6.12-rc3-mm3-full/drivers/bluetooth/hci_bcsp.c  2005-05-05 
17:40:08.0 +0200
@@ -58,8 +58,6 @@
 #ifndef CONFIG_BT_HCIUART_DEBUG
 #undef  BT_DBG
 #define BT_DBG( A... )
-#undef  BT_DMP
-#define BT_DMP( 

[PATCH] add dependency to arch/um/Makefile for parallel builds

[Olaf Hering]

the headerfile must be build before mk_user_constants. Adding it as 
a direct dep doesnt work for some reason.

arch/um/os-Linux/util/mk_user_constants.c:2:26: error: user-offsets.h: No such 
file or directory
arch/um/os-Linux/util/mk_user_constants.c: In function 'main':
arch/um/os-Linux/util/mk_user_constants.c:17: error: '__UM_FRAME_SIZE' 
undeclared (first use in this function)
arch/um/os-Linux/util/mk_user_constants.c:17: error: (Each undeclared 
identifier is reported only once
arch/um/os-Linux/util/mk_user_constants.c:17: error: for each function it 
appears in.)
make[1]: *** [arch/um/os-Linux/util/mk_user_constants] Error 1

Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>

 arch/um/Makefile |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.13-rc3-git4/arch/um/Makefile
===
--- linux-2.6.13-rc3-git4.orig/arch/um/Makefile
+++ linux-2.6.13-rc3-git4/arch/um/Makefile
@@ -245,7 +245,7 @@ $(ARCH_DIR)/util: scripts_basic $(SYS_DI
 $(ARCH_DIR)/kernel/skas/util: scripts_basic $(ARCH_DIR)/user-offsets.h FORCE
$(Q)$(MAKE) $(build)=$@
 
-$(ARCH_DIR)/os-$(OS)/util: scripts_basic FORCE
+$(ARCH_DIR)/os-$(OS)/util: scripts_basic $(ARCH_DIR)/user-offsets.h FORCE
$(Q)$(MAKE) $(build)=$@
 
 export SUBARCH USER_CFLAGS OS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] readd missing define to arch/um/Makefile-i386

[Olaf Hering]

New in 2.6.13-rc3-git4:

scripts/Makefile.build:13: /Makefile: No such file or directory
scripts/Makefile.build:64: kbuild: Makefile.build is included improperly

the define was removed, but its still required to build some targets.

Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>

 arch/um/Makefile-i386 |1 +
 1 files changed, 1 insertion(+)

Index: linux-2.6.13-rc3-git4/arch/um/Makefile-i386
===
--- linux-2.6.13-rc3-git4.orig/arch/um/Makefile-i386
+++ linux-2.6.13-rc3-git4/arch/um/Makefile-i386
@@ -33,6 +33,7 @@ ifneq ($(CONFIG_GPROF),y)
 ARCH_CFLAGS += -DUM_FASTCALL
 endif
 
+SYS_UTIL_DIR   := $(ARCH_DIR)/sys-i386/util
 SYS_HEADERS:= $(SYS_DIR)/sc.h $(SYS_DIR)/thread.h
 
 prepare: $(SYS_HEADERS)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] m32r: add missing Kconfig help text

[Adrian Bunk]

There's no help text for CONFIG_DEBUG_STACKOVERFLOW - add one.

Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was sent by Jesper Juhl on:
- 22 Dec 2004

--- linux-2.6.10-rc3-bk15-orig/arch/m32r/Kconfig.debug  2004-12-06 
22:24:16.0 +0100
+++ linux-2.6.10-rc3-bk15/arch/m32r/Kconfig.debug   2004-12-22 
23:28:32.0 +0100
@@ -5,6 +5,9 @@
 config DEBUG_STACKOVERFLOW
bool "Check for stack overflows"
depends on DEBUG_KERNEL
+   help
+ This option will cause messages to be printed if free stack space
+ drops below a certain limit.
 
 config DEBUG_STACK_USAGE
bool "Stack utilization instrumentation"


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Merging relayfs?

[Roman Zippel]

Hi,

On Thu, 14 Jul 2005, Tom Zanussi wrote:

> The netlink control channel seems to work very well, but I can
> certainly change the examples to use something different.  Could you
> suggest something?

It just looks like a complicated way to do an ioctl, a control file that 
you can read/write would be a lot simpler and faster.

>  > Looking through the patch there are still a few areas I'm concerned about:
>  > - the usage of atomic_t look a little silly, there is only a single 
>  > writer and probably needs some cache line optimisations
> 
> The only things that are atomic are the counts of produced and
> consumed buffers and these are only ever updated or read in the slow
> buffer-switch path.  They're atomic because if they weren't, wouldn't
> it be possible for the client to read an unfinished value if the
> producer was in the middle of updating it?

No.

>  > - I would prefer "unsigned int" over just "unsigned"
>  > - the padding/commit arrays can be easily managed by the client
> 
> Yes, I can move them out and update the examples to reflect that, but
> I thought that if this was something that most clients would need to
> do, it made some sense to keep it in relayfs and avoid duplication in
> the clients.

If a lot of clients needs this, there a different ways to do this, e.g. by 
introducing some helper functions that clients can use. This way you can 
keep the core simple and allow the client to modify its behaviour.

>  > - overwrite mode can be implemented via the buffer switch callback
> 
> The buffer switch callback is already where this is handled, unless
> you're thinking of something else - one of the first checks in the
> buffer switch is relay_buf_full(), which always returns 0 if the
> buffer is in overwrite mode.

I mean, relayfs doesn't has to know about this, the client itself can do 
it (e.g. via helper functions).

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [0/5+1] menu -> menuconfig part 1

[Roman Zippel]

Hi,

On Sun, 17 Jul 2005, Bodo Eggert wrote:

> These patches change some menus into menuconfig options.
> 
> Reworked to apply to linux-2.6.13-rc3-git3

I like it, but I would prefer to give it first a bit more exposure in -mm, 
as it does change the menu structure and the behaviour is little 
different, so I'd like to see if there's a some feedback first from people 
using it.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] sparc: remove the useless APM_RTC_IS_GMT option

[Adrian Bunk]

On Fri, Jul 15, 2005 at 03:43:31PM -0500, Tom 'spot' Callaway wrote:
> On Fri, 2005-07-15 at 22:36 +0200, Adrian Bunk wrote:
> > I can't see any effect of this option outside the i386-specific APM 
> > code.
> 
> Doesn't the Javastation potentially use this?

I don't know whether the Javastation supports APM, but the whole APM 
code in the kernel is currently only available on i386.

> ~spot

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Volatile vs Non-Volatile Spin Locks on SMP.

[Joe Seigh]

[EMAIL PROTECTED] wrote:

Hello,

By using volatile keyword for spin lock defined by in spinlock_t, it 
seems Linux choose to always
reload the value of spin locks from cache instead of using the content 
from registers. This may be

helpful for synchronization between multithreads in a single CPU.

I use two Xeon cpus with HyperThreading being disabled on both cpus. I 
think the MESI
protocol will enforce the cache coherency and update the spin lock value 
automatically between

these two cpus. So maybe we don't need to use the volatile any more, right?

Based on this, I rebuilt the Intel e1000 Gigabit network card driver 
with volatile being removed,

but I didn't notice any performance improvement.

Any idea about this,



Volatile is meaningless as far as threading is concerned.  Technically, its
meaning is implementation defined and since for Linux we're talking about
gcc, I suppose someone could claim it has some meaning although most of us
will have no way of verifying those claims.  You might see some usage
of volatile in the Linux kernel which makes it appear as though it
has some meaning but you might want to be careful in depending on that
since there's no way of knowing if your interpretation of the meaning
is the same as what the authors of that code have in mind.

For synchronization you need memory barriers in most cases and the only
way to get these is using assembler since there are no C or gcc intrinsics
for these yet.  For inline assembler, the convention seems to be to use
the volatile attribute, which I take as meaning no code movement across
the inline assembler code.  It if doesn't mean that then a lot of stuff
is broken AFAICT.

Assuming you're doing this in assembler, using volatile on the C declaration
will have no effect on performance in this case.  You're seeing the most
"recent" value due to the cache implementation.

--
Joe Seigh

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

rt-preempt and x86_64?

[Alistair John Strachan]

Hi Ingo,

(I searched the list for rt realtime x86_64 x86-64 before posting this, so I 
hope it's not a duplicate).

I've noticed -31 compiles without notable error or warning on x86-64, so I 
thought maybe it was a valid time to file a bug report about it not working.

The machine currently runs 2.6.12 but when booting with PREEMPT_RT mode on the 
same machine I get:

init[1]: segfault at 8010e9c4 rip 8010e9c4 rsp 
7fe28018
[...]

Which repeats indefinitely (presumably the kernel tries repeatedly to spawn 
it). I've booted without quiet and a broken root= and the kernel doesn't seem 
to complain about ANYTHING, so this must be a bug.

Any ideas?

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mips: remove obsolete GIU driver for vr41xx

[Yoichi Yuasa]

Hi,

This patch has removed obsolete GIU driver for vr41xx.
This patch already has been applied to mips tree.

Yoichi

-- 
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>

diff -urN -X dontdiff mm1-orig/arch/mips/vr41xx/common/Makefile 
mm1/arch/mips/vr41xx/common/Makefile
--- mm1-orig/arch/mips/vr41xx/common/Makefile   2005-07-13 13:46:46.0 
+0900
+++ mm1/arch/mips/vr41xx/common/Makefile2005-07-16 23:23:48.0 
+0900
@@ -2,7 +2,7 @@
 # Makefile for common code of the NEC VR4100 series.
 #
 
-obj-y  += bcu.o cmu.o giu.o icu.o init.o int-handler.o 
pmu.o
+obj-y  += bcu.o cmu.o icu.o init.o int-handler.o pmu.o
 obj-$(CONFIG_VRC4173)  += vrc4173.o
 
 EXTRA_AFLAGS := $(CFLAGS)
diff -urN -X dontdiff mm1-orig/arch/mips/vr41xx/common/giu.c 
mm1/arch/mips/vr41xx/common/giu.c
--- mm1-orig/arch/mips/vr41xx/common/giu.c  2005-07-13 13:46:46.0 
+0900
+++ mm1/arch/mips/vr41xx/common/giu.c   1970-01-01 09:00:00.0 +0900
@@ -1,455 +0,0 @@
-/*
- *  giu.c, General-purpose I/O Unit Interrupt routines for NEC VR4100 series.
- *
- *  Copyright (C) 2002 MontaVista Software Inc.
- *Author: Yoichi Yuasa <[EMAIL PROTECTED] or [EMAIL PROTECTED]>
- *  Copyright (C) 2003-2004  Yoichi Yuasa <[EMAIL PROTECTED]>
- *  Copyright (C) 2005 Ralf Baechle ([EMAIL PROTECTED])
- *
- *  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.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-/*
- * Changes:
- *  MontaVista Software Inc. <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
- *  - New creation, NEC VR4111, VR4121, VR4122 and VR4131 are supported.
- *
- *  Yoichi Yuasa <[EMAIL PROTECTED]>
- *  - Added support for NEC VR4133.
- *  - Removed board_irq_init.
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-
-#define GIUIOSELL_TYPE1KSEG1ADDR(0x0b000100)
-#define GIUIOSELL_TYPE2KSEG1ADDR(0x0f000140)
-
-#define GIUIOSELL  0x00
-#define GIUIOSELH  0x02
-#define GIUINTSTATL0x08
-#define GIUINTSTATH0x0a
-#define GIUINTENL  0x0c
-#define GIUINTENH  0x0e
-#define GIUINTTYPL 0x10
-#define GIUINTTYPH 0x12
-#define GIUINTALSELL   0x14
-#define GIUINTALSELH   0x16
-#define GIUINTHTSELL   0x18
-#define GIUINTHTSELH   0x1a
-#define GIUFEDGEINHL   0x20
-#define GIUFEDGEINHH   0x22
-#define GIUREDGEINHL   0x24
-#define GIUREDGEINHH   0x26
-
-static uint32_t giu_base;
-
-static struct irqaction giu_cascade = {
-   .handler= no_action,
-   .mask   = CPU_MASK_NONE,
-   .name   = "cascade",
-};
-
-#define read_giuint(offset)readw(giu_base + (offset))
-#define write_giuint(val, offset)  writew((val), giu_base + (offset))
-
-#define GIUINT_HIGH_OFFSET 16
-
-static inline uint16_t set_giuint(uint8_t offset, uint16_t set)
-{
-   uint16_t res;
-
-   res = read_giuint(offset);
-   res |= set;
-   write_giuint(res, offset);
-
-   return res;
-}
-
-static inline uint16_t clear_giuint(uint8_t offset, uint16_t clear)
-{
-   uint16_t res;
-
-   res = read_giuint(offset);
-   res &= ~clear;
-   write_giuint(res, offset);
-
-   return res;
-}
-
-static unsigned int startup_giuint_low_irq(unsigned int irq)
-{
-   unsigned int pin;
-
-   pin = GIU_IRQ_TO_PIN(irq);
-   write_giuint((uint16_t)1 << pin, GIUINTSTATL);
-   set_giuint(GIUINTENL, (uint16_t)1 << pin);
-
-   return 0;
-}
-
-static void shutdown_giuint_low_irq(unsigned int irq)
-{
-   clear_giuint(GIUINTENL, (uint16_t)1 << GIU_IRQ_TO_PIN(irq));
-}
-
-static void enable_giuint_low_irq(unsigned int irq)
-{
-   set_giuint(GIUINTENL, (uint16_t)1 << GIU_IRQ_TO_PIN(irq));
-}
-
-#define disable_giuint_low_irq shutdown_giuint_low_irq
-
-static void ack_giuint_low_irq(unsigned int irq)
-{
-   unsigned int pin;
-
-   pin = GIU_IRQ_TO_PIN(irq);
-   clear_giuint(GIUINTENL, (uint16_t)1 << pin);
-   write_giuint((uint16_t)1 << pin, GIUINTSTATL);
-}
-
-static void end_giuint_low_irq(unsigned int irq)
-{
-   if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)))
-   set_giuint(GIUINTENL, (uint16_t)1 << GIU_IRQ_TO_PIN(irq));
-}
-
-static struct hw_interrupt_type giuint_low_irq_type = {
-   .typename   = "GIUINTL",
-   .startup   

Re: Linux v2.6.13-rc3

[Alexey Dobriyan]

On Sun, Jul 17, 2005 at 01:18:54PM +0200, Borislav Petkov wrote:
> net/ipv4/netfilter/ip_conntrack_core.c: In function 'ip_conntrack_in':
> net/ipv4/netfilter/ip_conntrack_core.c:612: warning: 'set_reply' may be used
> uninitialized in this function

> --- net/ipv4/netfilter/ip_conntrack_core.c.orig
> +++ net/ipv4/netfilter/ip_conntrack_core.c
> @@ -609,7 +609,7 @@ unsigned int ip_conntrack_in(unsigned in

> - int set_reply;
> + int set_reply = 0;

> However, being so trivial, is it at all worth it fixing them

99% of "may be used uninitialized" warnings are bogus.

> or should I just ignore them?

You should ingnore them.

ip_conntrack_in(...)
{
int set_reply;

...
ct = resolve_normal_ct(*pskb, proto, _reply, hooknum, );
if (!ct) {
...
return NF_ACCEPT;
}
if (IS_ERR(ct)) {
...
return NF_DROP;
}
...
/* Will be reached if resolve_normal_ct() returns successfully */
if (set_reply)
set_bit(IPS_SEEN_REPLY_BIT, >status);
}

Is it possible for resolve_normal_ct() to return successfully and not
touch set_reply?

struct ip_conntrack *resolve_normal_ct(..., int set_reply, ...)
{
...
if (!ip_ct_get_tuple(skb->nh.iph, skb, skb->nh.iph->ihl*4,
, proto))
return NULL;
h = ip_conntrack_find_get(, NULL);
if (!h) {
h = init_conntrack(, proto, skb);
if (!h)
return NULL;
if (IS_ERR(h))
return (void *)h;
}
/* h is valid from now */
ct = tuplehash_to_ctrack(h);
/* ct is valid from now */
if (DIRECTION(h) == IP_CT_DIR_REPLY) {
...
*set_reply = 1;
} else {
...
*set_reply = 0;
}
/* set_reply is initialized */
...
return ct;
}


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fbdev: Update info->cmap when setting cmap from user-/kernelspace.

[Michal Januszewski]

Hi.

The fb_info struct, as defined in include/linux/fb.h, contains an element
that is supposed to hold the current color map:
  struct fb_cmap cmap;/* Current cmap */

This cmap is currently never updated when either fb_set_cmap() or
fb_set_user_cmap() are called. As a result, info->cmap contains the
default cmap that was set by a device driver/fbcon and a userspace
application using the FBIOGETCMAP ioctl will not always get the
*currently* used color map.

The patch fixes this by making sure the cmap is copied to info->cmap
after it is set correctly. It moves most of the code that is responsible
for setting the cmap to fb_set_cmap() and out of fb_set_user_cmap() to
avoid code-duplication.

Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---

diff -Nupr linux-2.6.12-orig/drivers/video/fbcmap.c 
linux-2.6.12/drivers/video/fbcmap.c
--- linux-2.6.12-orig/drivers/video/fbcmap.c2005-06-17 21:48:29.0 
+0200
+++ linux-2.6.12/drivers/video/fbcmap.c 2005-07-17 13:32:49.0 +0200
@@ -212,7 +212,7 @@ int fb_cmap_to_user(struct fb_cmap *from
 
 int fb_set_cmap(struct fb_cmap *cmap, struct fb_info *info)
 {
-   int i, start;
+   int i, start, rc = 0;
u16 *red, *green, *blue, *transp;
u_int hred, hgreen, hblue, htransp = 0x;
 
@@ -225,75 +225,51 @@ int fb_set_cmap(struct fb_cmap *cmap, st
if (start < 0 || (!info->fbops->fb_setcolreg &&
  !info->fbops->fb_setcmap))
return -EINVAL;
-   if (info->fbops->fb_setcmap)
-   return info->fbops->fb_setcmap(cmap, info);
-   for (i = 0; i < cmap->len; i++) {
-   hred = *red++;
-   hgreen = *green++;
-   hblue = *blue++;
-   if (transp)
-   htransp = *transp++;
-   if (info->fbops->fb_setcolreg(start++,
- hred, hgreen, hblue, htransp,
- info))
-   break;
+   if (info->fbops->fb_setcmap) {
+   rc = info->fbops->fb_setcmap(cmap, info);
+   } else {
+   for (i = 0; i < cmap->len; i++) {
+   hred = *red++;
+   hgreen = *green++;
+   hblue = *blue++;
+   if (transp)
+   htransp = *transp++;
+   if (info->fbops->fb_setcolreg(start++,
+ hred, hgreen, hblue, 
+ htransp, info))
+   break;
+   }
}
-   return 0;
+   if (rc == 0)
+   fb_copy_cmap(cmap, >cmap);
+
+   return rc;
 }
 
 int fb_set_user_cmap(struct fb_cmap_user *cmap, struct fb_info *info)
 {
-   int i, start;
-   u16 __user *red, *green, *blue, *transp;
-   u_int hred, hgreen, hblue, htransp = 0x;
-
-   red = cmap->red;
-   green = cmap->green;
-   blue = cmap->blue;
-   transp = cmap->transp;
-   start = cmap->start;
-
-   if (start < 0 || (!info->fbops->fb_setcolreg &&
- !info->fbops->fb_setcmap))
+   int rc, size = cmap->len * sizeof(u16);
+   struct fb_cmap umap;
+   
+   if (cmap->start < 0 || (!info->fbops->fb_setcolreg &&
+   !info->fbops->fb_setcmap))
return -EINVAL;
 
-   /* If we can batch, do it */
-   if (info->fbops->fb_setcmap && cmap->len > 1) {
-   struct fb_cmap umap;
-   int size = cmap->len * sizeof(u16);
-   int rc;
-
-   memset(, 0, sizeof(struct fb_cmap));
-   rc = fb_alloc_cmap(, cmap->len, transp != NULL);
-   if (rc)
-   return rc;
-   if (copy_from_user(umap.red, red, size) ||
-   copy_from_user(umap.green, green, size) ||
-   copy_from_user(umap.blue, blue, size) ||
-   (transp && copy_from_user(umap.transp, transp, size))) {
-   rc = -EFAULT;
-   }
-   umap.start = start;
-   if (rc == 0)
-   rc = info->fbops->fb_setcmap(, info);
-   fb_dealloc_cmap();
+   memset(, 0, sizeof(struct fb_cmap));
+   rc = fb_alloc_cmap(, cmap->len, cmap->transp != NULL);
+   if (rc)
return rc;
+   if (copy_from_user(umap.red, cmap->red, size) ||
+   copy_from_user(umap.green, cmap->green, size) ||
+   copy_from_user(umap.blue, cmap->blue, size) ||
+   (cmap->transp && copy_from_user(umap.transp, cmap->transp, size))) {
+   fb_dealloc_cmap();
+   return -EFAULT;
}
-
-   for (i = 0; i < cmap->len; i++, red++, blue++, green++) {
-   if (get_user(hred, red) ||
-   get_user(hgreen, green) ||
-  

2.6.13rc3: crypto horribly broken on all 64bit archs

[Andreas Steinmetz]

from include/linux/kernel.h:

#define ALIGN(x,a) (((x)+(a)-1)&~((a)-1))

from crypto/cipher.c:

unsigned int alignmask = ...
u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
...
unsigned int alignmask = ...
u8 *tmp = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
...
unsigned int align;
addr = ALIGN(addr, align);
addr += ALIGN(tfm->__crt_alg->cra_ctxsize, align);

The compiler first does ~((a)-1)) and then expands the unsigned int to
unsigned long for the & operation. So we end up with only the lower 32
bits of the address. Who did smoke what to do this? Patch attached.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]

--- linux.orig/crypto/cipher.c  2005-07-17 13:35:15.0 +0200
+++ linux/crypto/cipher.c   2005-07-17 14:04:00.0 +0200
@@ -41,7 +41,7 @@
   struct scatter_walk *in,
   struct scatter_walk *out, unsigned int bsize)
 {
-   unsigned int alignmask = crypto_tfm_alg_alignmask(desc->tfm);
+   unsigned long alignmask = crypto_tfm_alg_alignmask(desc->tfm);
u8 buffer[bsize * 2 + alignmask];
u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
u8 *dst = src + bsize;
@@ -160,7 +160,7 @@
  unsigned int nbytes)
 {
struct crypto_tfm *tfm = desc->tfm;
-   unsigned int alignmask = crypto_tfm_alg_alignmask(tfm);
+   unsigned long alignmask = crypto_tfm_alg_alignmask(tfm);
u8 *iv = desc->info;
 
if (unlikely(((unsigned long)iv & alignmask))) {
@@ -424,7 +424,7 @@
}

if (ops->cit_mode == CRYPTO_TFM_MODE_CBC) {
-   unsigned int align;
+   unsigned long align;
unsigned long addr;

switch (crypto_tfm_alg_blocksize(tfm)) {

Re: Realtime Preemption, 2.6.12, Beginners Guide?

[Karsten Wiese]

Am Samstag, 16. Juli 2005 19:15 schrieb Ingo Molnar:
> 
> * Karsten Wiese <[EMAIL PROTECTED]> wrote:
> 
> > Have I corrected the other path of ioapic early initialization, which 
> > had lacked virtual-address setup before ioapic_data[ioapic] was to be 
> > filled in -51-28? Please test attached patch on top of -51-29 or 
> > later. Also on Systems that liked -51-28.
> 
> thanks - i've applied it to my tree and have released the -51-31 patch.  
> It looks good on my testboxes.
> 
Found another error:
the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init().
Please apply attached patch on top of -51-31.

Karsten
--- linux-2.6.12-RT-51-31/arch/i386/kernel/io_apic.c	2005-07-17 12:40:35.0 +0200
+++ linux-2.6.12-RT/arch/i386/kernel/io_apic.c	2005-07-17 13:33:06.0 +0200
@@ -158,7 +158,7 @@
 static void __init ioapic_cache_init(struct ioapic_data_struct *ioapic)
 {
 	int reg;
-	for (reg = 0; reg < (ioapic->nr_registers + 10); reg++)
+	for (reg = 0; reg < (0x10 + 2 * ioapic->nr_registers); reg++)
 		ioapic->cached_val[reg] = __raw_io_apic_read(ioapic, reg);
 }
 # endif

[PATCH][fbcon] Don't repaint the cursor when it is disabled.

[Michal Januszewski]

Hi,

Currently even when the cursor is disabled (`setterm -cursor off`), it
is still repainted as a black rectangle the size of a single char. This
can be seen, for example, by chvt'ing to a free tty, disabling the
cursor and doing `dd if=/dev/urandom of=/dev/fb0`.

The patch changes this behaviour by avoiding painting anything when the
cursor is disabled.

Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
---

diff -Nupr linux-2.6.12-orig/drivers/video/console/fbcon.c 
linux-2.6.12/drivers/video/console/fbcon.c
--- linux-2.6.12-orig/drivers/video/console/fbcon.c 2005-06-17 
21:48:29.0 +0200
+++ linux-2.6.12/drivers/video/console/fbcon.c  2005-07-17 13:32:00.0 
+0200
@@ -276,7 +276,8 @@ static void fb_flashcursor(void *private
 
if (!vc || !CON_IS_VISIBLE(vc) ||
fbcon_is_inactive(vc, info) ||
-   registered_fb[con2fb_map[vc->vc_num]] != info)
+   registered_fb[con2fb_map[vc->vc_num]] != info ||
+   vc_cons[ops->currcon].d->vc_deccm != 1)
return;
acquire_console_sem();
p = _display[vc->vc_num];



pgp8G2oTwa4GD.pgp
Description: PGP signature

[PATCH] [6/5+1] menu -> menuconfig part 1

[Bodo Eggert]

On Sun, 17 Jul 2005, Bodo Eggert wrote:

> These patches change some menus into menuconfig options.
> 
> Reworked to apply to linux-2.6.13-rc3-git3

The Fusion driver is basically a scsi driver (isn't it?). Move it
to the other drivers and above the SCSI debugging driver.

 arch/arm/Kconfig |2 --
 arch/sparc64/Kconfig |4 
 arch/v850/Kconfig|2 --
 drivers/Kconfig  |2 --
 drivers/scsi/Kconfig |   30 --
 5 files changed, 16 insertions(+), 24 deletions(-)

Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>

diff -rNup a/arch/arm/Kconfig b/arch/arm/Kconfig
--- a/arch/arm/Kconfig  2005-07-17 12:03:15.0 +0200
+++ b/arch/arm/Kconfig  2005-07-17 12:05:38.0 +0200
@@ -724,8 +724,6 @@ source "drivers/scsi/Kconfig"
 
 source "drivers/md/Kconfig"
 
-source "drivers/message/fusion/Kconfig"
-
 source "drivers/ieee1394/Kconfig"
 
 source "drivers/message/i2o/Kconfig"
diff -rNup a/arch/sparc64/Kconfig b/arch/sparc64/Kconfig
--- a/arch/sparc64/Kconfig  2005-07-17 08:09:35.0 +0200
+++ b/arch/sparc64/Kconfig  2005-07-17 12:05:38.0 +0200
@@ -547,10 +547,6 @@ source "drivers/fc4/Kconfig"
 
 source "drivers/md/Kconfig"
 
-if PCI
-source "drivers/message/fusion/Kconfig"
-endif
-
 source "drivers/ieee1394/Kconfig"
 
 source "drivers/net/Kconfig"
diff -rNup a/arch/v850/Kconfig b/arch/v850/Kconfig
--- a/arch/v850/Kconfig 2005-07-17 08:09:36.0 +0200
+++ b/arch/v850/Kconfig 2005-07-17 12:05:38.0 +0200
@@ -279,8 +279,6 @@ endmenu
 
 source "drivers/md/Kconfig"
 
-source "drivers/message/fusion/Kconfig"
-
 source "drivers/ieee1394/Kconfig"
 
 source "drivers/message/i2o/Kconfig"
diff -rNup a/drivers/Kconfig b/drivers/Kconfig
--- a/drivers/Kconfig   2005-07-17 08:09:37.0 +0200
+++ b/drivers/Kconfig   2005-07-17 12:05:38.0 +0200
@@ -20,8 +20,6 @@ source "drivers/cdrom/Kconfig"
 
 source "drivers/md/Kconfig"
 
-source "drivers/message/fusion/Kconfig"
-
 source "drivers/ieee1394/Kconfig"
 
 source "drivers/message/i2o/Kconfig"
diff -rNup a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
--- a/drivers/scsi/Kconfig  2005-07-17 11:53:22.0 +0200
+++ b/drivers/scsi/Kconfig  2005-07-17 12:05:38.0 +0200
@@ -1485,19 +1485,6 @@ config SCSI_NSP32
  To compile this driver as a module, choose M here: the
  module will be called nsp32.
 
-config SCSI_DEBUG
-   tristate "SCSI debugging host simulator"
-   depends on SCSI
-   help
- This is a host adapter simulator that can simulate multiple hosts
- each with multiple dummy SCSI devices (disks). It defaults to one
- host adapter with one dummy SCSI disk. Each dummy disk uses kernel
- RAM as storage (i.e. it is a ramdisk). To save space when multiple
- dummy disks are simulated, they share the same kernel RAM for 
- their storage. See  for more
- information. This driver is primarily of use to those testing the
- SCSI and block subsystems. If unsure, say N.
-
 config SCSI_MESH
tristate "MESH (Power Mac internal SCSI) support"
depends on PPC32 && PPC_PMAC && SCSI
@@ -1787,6 +1774,21 @@ config ZFCP
   called zfcp. If you want to compile it as a module, say M here
   and read .
 
-endmenu
+source "drivers/message/fusion/Kconfig"
 
 source "drivers/scsi/pcmcia/Kconfig"
+
+config SCSI_DEBUG
+   tristate "SCSI debugging host simulator"
+   depends on SCSI
+   help
+ This is a host adapter simulator that can simulate multiple hosts
+ each with multiple dummy SCSI devices (disks). It defaults to one
+ host adapter with one dummy SCSI disk. Each dummy disk uses kernel
+ RAM as storage (i.e. it is a ramdisk). To save space when multiple
+ dummy disks are simulated, they share the same kernel RAM for 
+ their storage. See  for more
+ information. This driver is primarily of use to those testing the
+ SCSI and block subsystems. If unsure, say N.
+
+endmenu

-- 
Top 100 things you don't want the sysadmin to say:
83. Damn, and I just bought that pop...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [5/5+1] menu -> menuconfig part 1

[Bodo Eggert]

On Sun, 17 Jul 2005, Bodo Eggert wrote:

> These patches change some menus into menuconfig options.
> 
> Reworked to apply to linux-2.6.13-rc3-git3

The oprofile menu

 ./arch/alpha/oprofile/Kconfig   |   10 ++
 ./arch/arm/oprofile/Kconfig |   10 ++
 ./arch/i386/oprofile/Kconfig|   10 ++
 ./arch/ia64/oprofile/Kconfig|   10 ++
 ./arch/m32r/oprofile/Kconfig|   10 ++
 ./arch/mips/oprofile/Kconfig|   10 ++
 ./arch/parisc/oprofile/Kconfig  |   10 ++
 ./arch/ppc/oprofile/Kconfig |   10 ++
 ./arch/ppc64/oprofile/Kconfig   |   10 ++
 ./arch/s390/oprofile/Kconfig|8 +---
 ./arch/sh/oprofile/Kconfig  |9 ++---
 ./arch/sh64/oprofile/Kconfig|   10 ++
 ./arch/sparc64/oprofile/Kconfig |   10 ++
 ./arch/x86_64/oprofile/Kconfig  |   10 ++
 14 files changed, 27 insertions(+), 110 deletions(-)

Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>

--- a/./arch/sh/oprofile/Kconfig2004-08-14 07:36:14.0 +0200
+++ b/./arch/sh/oprofile/Kconfig2005-07-04 12:45:58.0 +0200
@@ -1,9 +1,6 @@
-
-menu "Profiling support"
-   depends on EXPERIMENTAL
-
-config PROFILING
+menuconfig PROFILING
bool "Profiling support (EXPERIMENTAL)"
+   depends on EXPERIMENTAL
help
  Say Y here to enable the extended profiling support mechanisms used
  by profilers such as OProfile.
@@ -19,5 +16,3 @@ config OPROFILE
 
  If unsure, say N.
 
-endmenu
-
--- a/./arch/arm/oprofile/Kconfig   2004-08-14 07:36:57.0 +0200
+++ b/./arch/arm/oprofile/Kconfig   2005-07-04 12:46:17.0 +0200
@@ -1,9 +1,6 @@
-
-menu "Profiling support"
-   depends on EXPERIMENTAL
-
-config PROFILING
+menuconfig PROFILING
bool "Profiling support (EXPERIMENTAL)"
+   depends on EXPERIMENTAL
help
  Say Y here to enable the extended profiling support mechanisms used
  by profilers such as OProfile.
@@ -18,6 +15,3 @@ config OPROFILE
  and applications.
 
  If unsure, say N.
-
-endmenu
-
--- a/./arch/ppc/oprofile/Kconfig   2004-08-14 07:36:32.0 +0200
+++ b/./arch/ppc/oprofile/Kconfig   2005-07-04 12:46:35.0 +0200
@@ -1,9 +1,6 @@
-
-menu "Profiling support"
-   depends on EXPERIMENTAL
-
-config PROFILING
+menuconfig PROFILING
bool "Profiling support (EXPERIMENTAL)"
+   depends on EXPERIMENTAL
help
  Say Y here to enable the extended profiling support mechanisms used
  by profilers such as OProfile.
@@ -18,6 +15,3 @@ config OPROFILE
  and applications.
 
  If unsure, say N.
-
-endmenu
-
--- a/./arch/i386/oprofile/Kconfig  2004-08-14 07:36:59.0 +0200
+++ b/./arch/i386/oprofile/Kconfig  2005-07-04 12:46:56.0 +0200
@@ -1,9 +1,6 @@
-
-menu "Profiling support"
-   depends on EXPERIMENTAL
-
-config PROFILING
+menuconfig PROFILING
bool "Profiling support (EXPERIMENTAL)"
+   depends on EXPERIMENTAL
help
  Say Y here to enable the extended profiling support mechanisms used
  by profilers such as OProfile.
@@ -18,6 +15,3 @@ config OPROFILE
  and applications.
 
  If unsure, say N.
-
-endmenu
-
--- a/./arch/m32r/oprofile/Kconfig  2005-05-02 02:23:53.0 +0200
+++ b/./arch/m32r/oprofile/Kconfig  2005-07-04 12:47:10.0 +0200
@@ -1,9 +1,6 @@
-
-menu "Profiling support"
-   depends on EXPERIMENTAL
-
-config PROFILING
+menuconfig PROFILING
bool "Profiling support (EXPERIMENTAL)"
+   depends on EXPERIMENTAL
help
  Say Y here to enable the extended profiling support mechanisms used
  by profilers such as OProfile.
@@ -18,6 +15,3 @@ config OPROFILE
  and applications.
 
  If unsure, say N.
-
-endmenu
-
--- a/./arch/ia64/oprofile/Kconfig  2005-05-02 02:23:53.0 +0200
+++ b/./arch/ia64/oprofile/Kconfig  2005-07-04 12:47:27.0 +0200
@@ -1,9 +1,6 @@
-
-menu "Profiling support"
-   depends on EXPERIMENTAL
-
-config PROFILING
+menuconfig PROFILING
bool "Profiling support (EXPERIMENTAL)"
+   depends on EXPERIMENTAL
help
  Say Y here to enable the extended profiling support mechanisms used
  by profilers such as OProfile.
@@ -21,6 +18,3 @@ config OPROFILE
  counters.
 
  If unsure, say N.
-
-endmenu
-
--- a/./arch/mips/oprofile/Kconfig  2005-05-02 02:25:32.0 +0200
+++ b/./arch/mips/oprofile/Kconfig  2005-07-04 12:47:42.0 +0200
@@ -1,9 +1,6 @@
-
-menu "Profiling support"
-   depends on EXPERIMENTAL
-
-config PROFILING
+menuconfig PROFILING
bool "Profiling support (EXPERIMENTAL)"
+   depends on EXPERIMENTAL
help
  Say Y here to enable the extended profiling support mechanisms used
  by profilers such as OProfile.
@@ -18,6 +15,3 @@ config OPROFILE
  and 

[PATCH] [4/5+1] menu -> menuconfig part 1

[Bodo Eggert]

On Sun, 17 Jul 2005, Bodo Eggert wrote:

> These patches change some menus into menuconfig options.
> 
> Reworked to apply to linux-2.6.13-rc3-git3

CPU frequency scaling menu

 arch/arm/Kconfig |4 
 arch/i386/kernel/cpu/cpufreq/Kconfig |4 
 arch/sh/Kconfig  |4 
 arch/x86_64/kernel/cpufreq/Kconfig   |4 
 drivers/cpufreq/Kconfig  |2 +-
 5 files changed, 1 insertion(+), 17 deletions(-)

Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>

diff -rNup a/arch/arm/Kconfig b/arch/arm/Kconfig
--- a/arch/arm/Kconfig  2005-07-17 08:09:33.0 +0200
+++ b/arch/arm/Kconfig  2005-07-17 11:25:40.0 +0200
@@ -518,8 +518,6 @@ endmenu
 
 if (ARCH_SA1100 || ARCH_INTEGRATOR || ARCH_OMAP1)
 
-menu "CPU Frequency scaling"
-
 source "drivers/cpufreq/Kconfig"
 
 config CPU_FREQ_SA1100
@@ -543,8 +541,6 @@ config CPU_FREQ_INTEGRATOR
 
  If in doubt, say Y.
 
-endmenu
-
 endif
 
 menu "Floating point emulation"
diff -rNup a/arch/i386/kernel/cpu/cpufreq/Kconfig 
b/arch/i386/kernel/cpu/cpufreq/Kconfig
--- a/arch/i386/kernel/cpu/cpufreq/Kconfig  2005-07-17 08:08:24.0 
+0200
+++ b/arch/i386/kernel/cpu/cpufreq/Kconfig  2005-07-17 11:25:40.0 
+0200
@@ -2,8 +2,6 @@
 # CPU Frequency scaling
 #
 
-menu "CPU Frequency scaling"
-
 source "drivers/cpufreq/Kconfig"
 
 if CPU_FREQ
@@ -239,5 +237,3 @@ config X86_SPEEDSTEP_RELAXED_CAP_CHECK
  parameter "relaxed_check=1" is passed to the module.
 
 endif  # CPU_FREQ
-
-endmenu
diff -rNup a/arch/sh/Kconfig b/arch/sh/Kconfig
--- a/arch/sh/Kconfig   2005-07-17 08:09:35.0 +0200
+++ b/arch/sh/Kconfig   2005-07-17 11:25:40.0 +0200
@@ -657,8 +657,6 @@ config SH_PCLK_FREQ
  with an auto-probed frequency which should be considered the proper
  value for your hardware.
 
-menu "CPU Frequency scaling"
-
 source "drivers/cpufreq/Kconfig"
 
 config SH_CPU_FREQ
@@ -673,8 +671,6 @@ config SH_CPU_FREQ
 
  If unsure, say N.
 
-endmenu
-
 source "arch/sh/drivers/dma/Kconfig"
 
 source "arch/sh/cchips/Kconfig"
diff -rNup a/arch/x86_64/kernel/cpufreq/Kconfig 
b/arch/x86_64/kernel/cpufreq/Kconfig
--- a/arch/x86_64/kernel/cpufreq/Kconfig2005-07-17 08:08:37.0 
+0200
+++ b/arch/x86_64/kernel/cpufreq/Kconfig2005-07-17 11:25:40.0 
+0200
@@ -2,8 +2,6 @@
 # CPU Frequency scaling
 #
 
-menu "CPU Frequency scaling"
-
 source "drivers/cpufreq/Kconfig"
 
 if CPU_FREQ
@@ -92,5 +90,3 @@ config X86_SPEEDSTEP_LIB
 
 endif
 
-endmenu
-
diff -rNup a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
--- a/drivers/cpufreq/Kconfig   2005-07-17 08:08:43.0 +0200
+++ b/drivers/cpufreq/Kconfig   2005-07-17 11:31:18.0 +0200
@@ -1,4 +1,4 @@
-config CPU_FREQ
+menuconfig CPU_FREQ
bool "CPU Frequency scaling"
help
  CPU Frequency scaling allows you to change the clock speed of 

-- 
The most dangerous thing in the world is a second lieutenant with a map and
a compass.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [3/5+1] menu -> menuconfig part 1

[Bodo Eggert]

On Sun, 17 Jul 2005, Bodo Eggert wrote:

> These patches change some menus into menuconfig options.
> 
> Reworked to apply to linux-2.6.13-rc3-git3

The APM menu.

 arch/i386/Kconfig |   18 +-
 1 files changed, 5 insertions(+), 13 deletions(-)

Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>

diff -rNup a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig 2005-07-17 08:09:33.0 +0200
+++ b/arch/i386/Kconfig 2005-07-17 11:18:20.0 +0200
@@ -987,12 +987,9 @@ source kernel/power/Kconfig
 
 source "drivers/acpi/Kconfig"
 
-menu "APM (Advanced Power Management) BIOS Support"
-depends on PM && !X86_VISWS
-
-config APM
+menuconfig APM
tristate "APM (Advanced Power Management) BIOS support"
-   depends on PM
+   depends on PM && !X86_VISWS
---help---
  APM is a BIOS specification for saving power using several different
  techniques. This is mostly useful for battery powered laptops with
@@ -1049,9 +1046,10 @@ config APM
  To compile this driver as a module, choose M here: the
  module will be called apm.
 
+if APM
+
 config APM_IGNORE_USER_SUSPEND
bool "Ignore USER SUSPEND"
-   depends on APM
help
  This option will ignore USER SUSPEND requests. On machines with a
  compliant APM BIOS, you want to say N. However, on the NEC Versa M
@@ -1059,7 +1057,6 @@ config APM_IGNORE_USER_SUSPEND
 
 config APM_DO_ENABLE
bool "Enable PM at boot time"
-   depends on APM
---help---
  Enable APM features at boot time. From page 36 of the APM BIOS
  specification: "When disabled, the APM BIOS does not automatically
@@ -1077,7 +1074,6 @@ config APM_DO_ENABLE
 
 config APM_CPU_IDLE
bool "Make CPU Idle calls when idle"
-   depends on APM
help
  Enable calls to APM CPU Idle/CPU Busy inside the kernel's idle loop.
  On some machines, this can activate improved power savings, such as
@@ -1089,7 +1085,6 @@ config APM_CPU_IDLE
 
 config APM_DISPLAY_BLANK
bool "Enable console blanking using APM"
-   depends on APM
help
  Enable console blanking using the APM. Some laptops can use this to
  turn off the LCD backlight when the screen blanker of the Linux
@@ -1103,7 +1098,6 @@ config APM_DISPLAY_BLANK
 
 config APM_RTC_IS_GMT
bool "RTC stores time in GMT"
-   depends on APM
help
  Say Y here if your RTC (Real Time Clock a.k.a. hardware clock)
  stores the time in GMT (Greenwich Mean Time). Say N if your RTC
@@ -1116,7 +1110,6 @@ config APM_RTC_IS_GMT
 
 config APM_ALLOW_INTS
bool "Allow interrupts during APM BIOS calls"
-   depends on APM
help
  Normally we disable external interrupts while we are making calls to
  the APM BIOS as a measure to lessen the effects of a badly behaving
@@ -1127,13 +1120,12 @@ config APM_ALLOW_INTS
 
 config APM_REAL_MODE_POWER_OFF
bool "Use real mode APM BIOS call to power off"
-   depends on APM
help
  Use real mode APM BIOS calls to switch off the computer. This is
  a work-around for a number of buggy BIOSes. Switch this option on if
  your computer crashes instead of powering off properly.
 
-endmenu
+endif
 
 source "arch/i386/kernel/cpu/cpufreq/Kconfig"
 
-- 
I don't care about people reading in OE. It just gets bad if they
send postings, viruses, and complaints about non-existing attachements.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [2/5+1] menu -> menuconfig part 1

[Bodo Eggert]

On Sun, 17 Jul 2005, Bodo Eggert wrote:

> These patches change some menus into menuconfig options.
> 
> Reworked to apply to linux-2.6.13-rc3-git3

The USB menu.

 drivers/usb/Kconfig |   18 ++
 drivers/usb/atm/Kconfig |7 +--
 drivers/usb/class/Kconfig   |   11 ---
 drivers/usb/core/Kconfig|   11 ---
 drivers/usb/gadget/Kconfig  |8 ++--
 drivers/usb/host/Kconfig|8 +++-
 drivers/usb/image/Kconfig   |5 ++---
 drivers/usb/input/Kconfig   |2 --
 drivers/usb/media/Kconfig   |   24 +++-
 drivers/usb/misc/Kconfig|   17 -
 drivers/usb/net/Kconfig |   11 +++
 drivers/usb/serial/Kconfig  |1 -
 drivers/usb/storage/Kconfig |2 --
 13 files changed, 48 insertions(+), 77 deletions(-)

Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>

diff -rNup a/drivers/usb/Kconfig b/drivers/usb/Kconfig
--- a/drivers/usb/Kconfig   2005-07-17 08:09:02.0 +0200
+++ b/drivers/usb/Kconfig   2005-07-17 10:47:59.0 +0200
@@ -2,8 +2,6 @@
 # USB device configuration
 #
 
-menu "USB support"
-
 # Host-side USB depends on having a host controller
 # NOTE:  dummy_hcd is always an option, but it's ignored here ...
 # NOTE:  SL-811 option should be board-specific ...
@@ -29,9 +27,12 @@ config USB_ARCH_HAS_OHCI
# more:
default PCI
 
+comment "USB (host side) may require PCI"
+   depends on !USB_ARCH_HAS_HCD && !PCI
+
 # ARM SA chips have a non-PCI based "OHCI-compatible" USB host interface.
-config USB
-   tristate "Support for Host-side USB"
+menuconfig USB
+   tristate "USB (host side)"
depends on USB_ARCH_HAS_HCD
---help---
  Universal Serial Bus (USB) is a specification for a serial bus
@@ -65,6 +66,8 @@ config USB
  To compile this driver as a module, choose M here: the
  module will be called usbcore.
 
+if USB
+
 source "drivers/usb/core/Kconfig"
 
 source "drivers/usb/host/Kconfig"
@@ -84,11 +87,10 @@ source "drivers/usb/net/Kconfig"
 source "drivers/usb/mon/Kconfig"
 
 comment "USB port drivers"
-   depends on USB
 
 config USB_USS720
tristate "USS720 parport driver"
-   depends on USB && PARPORT
+   depends on PARPORT
select PARPORT_NOT_PC
---help---
  This driver is for USB parallel port adapters that use the Lucent
@@ -121,7 +123,7 @@ source "drivers/usb/misc/Kconfig"
 
 source "drivers/usb/atm/Kconfig"
 
-source "drivers/usb/gadget/Kconfig"
+endif
 
-endmenu
+source "drivers/usb/gadget/Kconfig"
 
diff -rNup a/drivers/usb/atm/Kconfig b/drivers/usb/atm/Kconfig
--- a/drivers/usb/atm/Kconfig   2005-07-17 08:10:01.0 +0200
+++ b/drivers/usb/atm/Kconfig   2005-07-17 11:11:22.0 +0200
@@ -2,10 +2,7 @@
 # USB/ATM DSL configuration
 #
 
-menu "USB DSL modem support"
-   depends on USB
-
-config USB_ATM
+menuconfig USB_ATM
tristate "USB DSL modem support"
depends on USB && ATM
select CRC32
@@ -56,5 +53,3 @@ config USB_XUSBATM
 
  To compile this driver as a module, choose M here: the
  module will be called xusbatm.
-
-endmenu
diff -rNup a/drivers/usb/class/Kconfig b/drivers/usb/class/Kconfig
--- a/drivers/usb/class/Kconfig 2005-07-17 08:06:24.0 +0200
+++ b/drivers/usb/class/Kconfig 2005-07-17 10:48:06.0 +0200
@@ -2,11 +2,10 @@
 # USB Class driver configuration
 #
 comment "USB Device Class drivers"
-   depends on USB
 
 config USB_AUDIO
tristate "USB Audio support"
-   depends on USB && SOUND
+   depends on SOUND
help
  Say Y here if you want to connect USB audio equipment such as
  speakers to your computer's USB port. You only need this if you use
@@ -16,11 +15,11 @@ config USB_AUDIO
  module will be called audio.
 
 comment "USB Bluetooth TTY can only be used with disabled Bluetooth subsystem"
-   depends on USB && BT
+   depends on BT
 
 config USB_BLUETOOTH_TTY
tristate "USB Bluetooth TTY support"
-   depends on USB && BT=n
+   depends on BT=n
---help---
  This driver implements a nonstandard tty interface to a Bluetooth
  device that can be used only by specialized Bluetooth HCI software.
@@ -40,7 +39,7 @@ config USB_BLUETOOTH_TTY
 
 config USB_MIDI
tristate "USB MIDI support"
-   depends on USB && SOUND
+   depends on SOUND
---help---
  Say Y here if you want to connect a USB MIDI device to your
  computer's USB port. This driver is for devices that comply with
@@ -61,7 +60,6 @@ config USB_MIDI
 
 config USB_ACM
tristate "USB Modem (CDC ACM) support"
-   depends on USB
---help---
  This driver supports USB modems and ISDN adapters which support the
  Communication Device Class Abstract Control Model interface.
@@ -76,7 +74,6 @@ config USB_ACM
 
 config USB_PRINTER
tristate "USB Printer support"
-   depends 

Re: [PATCH] [1/5+1] menu -> menuconfig part 1

[Bodo Eggert]

On Sun, 17 Jul 2005, Bodo Eggert wrote:

> These patches change some menus into menuconfig options.
> 
> Reworked to apply to linux-2.6.13-rc3-git3

Mostly robotic works.

 drivers/acpi/Kconfig|   10 ++
 drivers/cdrom/Kconfig   |8 ++--
 drivers/char/ipmi/Kconfig   |5 +
 drivers/char/tpm/Kconfig|7 +--
 drivers/char/watchdog/Kconfig   |6 +-
 drivers/fc4/Kconfig |7 +--
 drivers/i2c/Kconfig |7 +--
 drivers/ide/Kconfig |6 +-
 drivers/ieee1394/Kconfig|6 +-
 drivers/infiniband/Kconfig  |6 +-
 drivers/isdn/Kconfig|9 ++---
 drivers/isdn/hardware/avm/Kconfig   |9 ++---
 drivers/isdn/hardware/eicon/Kconfig |9 ++---
 drivers/isdn/hisax/Kconfig  |9 ++---
 drivers/md/Kconfig  |7 +--
 drivers/media/dvb/Kconfig   |8 ++--
 drivers/message/fusion/Kconfig  |   16 ++--
 drivers/message/i2o/Kconfig |8 +---
 drivers/mmc/Kconfig |8 ++--
 drivers/mtd/Kconfig |7 +--
 drivers/mtd/nand/Kconfig|   14 +-
 drivers/net/Kconfig |   22 ++
 drivers/net/arcnet/Kconfig  |9 ++---
 drivers/net/irda/Kconfig|8 +---
 drivers/net/pcmcia/Kconfig  |9 ++---
 drivers/net/tokenring/Kconfig   |9 ++---
 drivers/net/tulip/Kconfig   |9 ++---
 drivers/net/wan/Kconfig |9 ++---
 drivers/net/wireless/Kconfig|9 ++---
 drivers/parport/Kconfig |8 ++--
 drivers/pci/hotplug/Kconfig |7 +--
 drivers/pcmcia/Kconfig  |6 +-
 drivers/pnp/Kconfig |7 +--
 drivers/scsi/Kconfig|6 +-
 drivers/scsi/pcmcia/Kconfig |7 +--
 drivers/telephony/Kconfig   |9 ++---
 drivers/usb/serial/Kconfig  |7 +--
 drivers/video/logo/Kconfig  |9 ++---
 drivers/w1/Kconfig  |8 ++--
 fs/Kconfig  |4 
 fs/nls/Kconfig  |8 ++--
 fs/partitions/Kconfig   |2 +-
 fs/xfs/Kconfig  |   17 +++--
 init/Kconfig|   17 +++--
 sound/Kconfig   |   25 +++--
 sound/oss/Kconfig   |2 +-
 46 files changed, 112 insertions(+), 293 deletions(-)

Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]>

diff -rNup a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
--- a/drivers/acpi/Kconfig  2005-07-17 09:51:47.0 +0200
+++ b/drivers/acpi/Kconfig  2005-07-17 08:26:09.0 +0200
@@ -2,16 +2,12 @@
 # ACPI Configuration
 #
 
-menu "ACPI (Advanced Configuration and Power Interface) Support"
+menuconfig ACPI
+   bool "ACPI (Advanced Configuration and Power Interface) Support"
depends on PM
depends on !X86_VISWS
depends on !IA64_HP_SIM
depends on IA64 || X86
-
-config ACPI
-   bool "ACPI Support"
-   depends on IA64 || X86
-
default y
---help---
  Advanced Configuration and Power Interface (ACPI) support for 
@@ -363,5 +359,3 @@ config ACPI_HOTPLUG_MEMORY
  command: 
$>modprobe acpi_memhotplug 
 endif  # ACPI
-
-endmenu
diff -rNup a/drivers/cdrom/Kconfig b/drivers/cdrom/Kconfig
--- a/drivers/cdrom/Kconfig 2005-07-17 09:51:47.0 +0200
+++ b/drivers/cdrom/Kconfig 2005-07-17 08:23:15.0 +0200
@@ -2,11 +2,9 @@
 # CDROM driver configuration
 #
 
-menu "Old CD-ROM drivers (not SCSI, not IDE)"
+menuconfig CD_NO_IDESCSI
+   bool "Old CD-ROM drivers (not SCSI, IDE or ATAPI)"
depends on ISA
-
-config CD_NO_IDESCSI
-   bool "Support non-SCSI/IDE/ATAPI CDROM drives"
---help---
  If you have a CD-ROM drive that is neither SCSI nor IDE/ATAPI, say Y
  here, otherwise N. Read the CD-ROM-HOWTO, available from
@@ -209,5 +207,3 @@ config CDU535
 
  To compile this driver as a module, choose M here: the
  module will be called sonycd535.
-
-endmenu
diff -rNup a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
--- a/drivers/char/ipmi/Kconfig 2005-07-17 09:51:47.0 +0200
+++ b/drivers/char/ipmi/Kconfig 2005-07-17 08:23:15.0 +0200
@@ -2,8 +2,7 @@
 # IPMI device configuration
 #
 
-menu "IPMI"
-config IPMI_HANDLER
+menuconfig IPMI_HANDLER
tristate 'IPMI top-level message handler'
help
  This enables the central IPMI message handler, required for IPMI
@@ -63,5 +62,3 @@ config IPMI_POWEROFF
help
  This enables a function to power off the system with IPMI if
 the IPMI management controller 

Re: Linux v2.6.13-rc3

[Borislav Petkov]

On Wednesday 13 July 2005 07:05, Linus Torvalds wrote:
> Yes,
>  it's _really_ -rc3 this time, never mind the confusion with the commit
> message last time (when the Makefile clearly said -rc2, but my over-eager
> fingers had typed in a commit message saying -rc3).
>
> There's a bit more changes here than I would like, but I'm putting my foot
> down now. Not only are a lot of people going to be gone next week for LKS
> and OLS, but we've gotten enough stuff for 2.6.13, and we need to calm
> down.
>
> Admittedly the diff looks a bit bigger than it really conceptually is,
> partly due to the hwmon drivers moving around, partly due to re-indenting
> reiserfs. No real changes, but huge diffs in both cases.

Hi Linus,

I get several warnings like the one below when building with gcc4.0. 

net/ipv4/netfilter/ip_conntrack_core.c: In function 'ip_conntrack_in':
net/ipv4/netfilter/ip_conntrack_core.c:612: warning: 'set_reply' may be used 
uninitialized in this function

The trivial patch below fixes it:

Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>

--- net/ipv4/netfilter/ip_conntrack_core.c.orig 2005-07-17 13:14:21.0 
+0200
+++ net/ipv4/netfilter/ip_conntrack_core.c  2005-07-17 13:14:57.0 
+0200
@@ -609,7 +609,7 @@ unsigned int ip_conntrack_in(unsigned in
struct ip_conntrack *ct;
enum ip_conntrack_info ctinfo;
struct ip_conntrack_protocol *proto;
-   int set_reply;
+   int set_reply = 0;
int ret;
 
/* Previously seen (loopback or untracked)?  Ignore. */


However, being so trivial, is it at all worth it fixing them or should I just 
ignore them?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [0/5+1] menu -> menuconfig part 1

[Bodo Eggert]

These patches change some menus into menuconfig options.

Reworked to apply to linux-2.6.13-rc3-git3
-- 
Top 100 things you don't want the sysadmin to say:
17. dd if=/dev/null of=/vmunix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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

[Bodo Eggert]

Jan Blunck <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:

>  > Does it really matter?
>  >
> 
> Yes! At least for me and my union mounts implementation.

Is there a reason for not using size == link-count (or even static)?
-- 
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/

MSNBC_Auto_Response: MSNBC Job Inquiry

[Jobs]

Thank you for inquiring about employment opportunities with MSNBC on the 
Internet. You may view current postings for positions located in Redmond, WA 
and on the East Coast by clicking on JOBS at http://www.msnbc.com 
 .

Résumé screening will be completed within the next few weeks. If your 
qualifications meet the needs of the positions open, we will contact you for 
further discussion. If you do not hear from us, be assured that your résumé 
will remain in our files for one year and that you will be considered for 
suitable future openings. 

Again, thank you for your interest in MSNBC on the Internet and we wish you 
success in your current job search.

:: MSNBC_Auto_Response :: Jobs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 copy_to_user result check

[Coywolf Qi Hunt]

hello,

GCC warns me this problem. This patch adds copy_to_user result check
in sys_select() and sys_pselect7().


Signed-off-by: Coywolf Qi Hunt <[EMAIL PROTECTED]>
---
diff -pruN 2.6.13-rc3-mm1/fs/select.c 2.6.13-rc3-mm1-cy1/fs/select.c
--- 2.6.13-rc3-mm1/fs/select.c  2005-07-15 23:51:35.0 +0800
+++ 2.6.13-rc3-mm1-cy1/fs/select.c  2005-07-17 16:26:58.0 +0800
@@ -401,7 +401,8 @@ asmlinkage long sys_select(int n, fd_set
tv.tv_sec++;
tv.tv_usec -= 100;
}
-   copy_to_user(tvp, , sizeof(tv));
+   if (copy_to_user(tvp, , sizeof(tv)))
+   return -EFAULT;
}
 
return ret;
@@ -459,7 +460,8 @@ asmlinkage long sys_pselect7(int n, fd_s
ts.tv_sec++;
ts.tv_nsec -= 10;
}
-   copy_to_user(tsp, , sizeof(ts));
+   if (copy_to_user(tsp, , sizeof(ts)))
+   return -EFAULT;
}
 
if (sigmask)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Re: relayfs documentation sucks?

[bert hubert]

On Sat, Jul 16, 2005 at 06:13:55PM -0500, Tom Zanussi wrote:

> relayfs itself only provides the buffering and file operations along
> with the kernel API for clients as documented in
> Documentation/filesystems/relayfs.txt.  Applications still need some
> kind of communication between the kernel and user space in order to
> know when data is ready and how much is ready - the relay-apps stuff
> tries to make this easy to do by allowing clients to ignore all those
> details.  It happens to use netlink for this, but clients can use
> whatever they want to do this communication.

Ok - that is good to know. What is missing from relayfs.txt is a demarcation
of which system does what.

As I see it there are three things currently:

1) Basic relayfs facilities, which only stuff data into N sub-buffers per
CPU, but also offer a set of functions that could be called via userspace
over some sort of communication channel.

2) klog which is a thin wrapper over relay_write

3) relay-app.h which lives in the kernel and communicates with librelay.c in
user space, providing that communication.

Is this correct?

> Then just run the kleak app, and when it finishes, you should have a
> set of files, cpu0l...cpuX in your current directory containing all
> the data you've logged.

I've changed the fprintf(stderr, "netlink send error") to perror("netlink
send error") and now it prints 'Connection refused', which makes heaps of
sense since I did not use relay-app.h, but wrote directly to the channel.

>  > 2) What kind of messages do I need to send/receive?
> 
> Basically, the daemon needs to know, for a given per-cpu buffer, how
> many sub-buffers have been produced and consumed, in order to know
> which sections of the mmapped buffer to read.  It also needs to notify

I currently just write away without any userspace component, except that I
mmap the entire relayfs file in which I see the four configured sub-buffers.
I guess that in override mode that would work? 

> The format is whatever the client writes into it - relayfs itself
> doesn't impose any format at all.  The client doesn't need librelay.c
> to read the data itself - librelay.c is for managing the daemon side
> of the application and writing ready data to disk as it becomes
> available.  It doesn't know anything about the actual data being written.

Ok - so there is nothing in there except n stretches of data, and some
padding? Each write is either IN a sub-buffer or not at all, it doesn't span
sub-buffers?

>  > 4) What are the semantics for reading from that file?
> 
> The file is a buffer broken up into sub-buffers.  The client reads the
> sub-buffers it knows are ready directly from the mmapped buffer.
> The file can only be mmap()ed - there is no read() available.

Indeed. So the idea is to wait for a ringbuffer to become 'full', read it,
and wait for the next one to become full?

> BTW, there's also documentation in relay-app.h, don't know if you saw
> that.

Yes - but it only makes sense after the 'separation of powers' within
relayfs is clear. relayfs.txt talks rather cavalierly of 'clients' and
'calls' but does not make clear this client lives in userspace and can't
just call kernel functions.

Please consider the patch below. I'm not 100% sure if everything is correct,
but I'd love to know.

I'm wondering how relayfs could be operated safely in overwrite mode, btw -
who's to say the kernel might not have zoomed past my sub-buffer once I'm
notified of the crossing? The padding data I receive might be outdated by
then. Sounds racey.

In fact, it appears this might even happen in non-overwrite mode.

diff -urBb -X linux-2.6.13-rc3-mm1/Documentation/dontdiff 
linux-2.6.13-rc3-mm1/Documentation/filesystems/relayfs.txt 
linux-2.6.13-rc3-mm1-ahu/Documentation/filesystems/relayfs.txt
--- linux-2.6.13-rc3-mm1/Documentation/filesystems/relayfs.txt  2005-07-17 
11:00:48.000638680 +0200
+++ linux-2.6.13-rc3-mm1-ahu/Documentation/filesystems/relayfs.txt  
2005-07-17 10:58:21.634889656 +0200
@@ -23,6 +23,46 @@
 the function parameters are documented along with the functions in the
 filesystem code - please see that for details.
 
+Semantics
+=
+
+Each relayfs channel has one buffer per CPU, each buffer has one or
+more sub-buffers. Messages are written to the first sub-buffer until it
+is too full to contain a new message, in which case it it is written to
+the next (if available). At this point, userspace can be notified so it
+empties the first ringbuffer, while the kernel continues writing to the
+next.
+
+If notified that a sub-buffer is full, the kernel knows how many bytes
+of it are padding, ie, unused. Userspace can use this knowledge to copy
+only valid data.
+
+After copying, userspace can notify the kernel that a sub-channel has
+been consumed.
+
+relayfs can operate in a mode where it will overwrite data not yet
+collected by userspace, and not wait for it to consume it.
+
+relayfs itself does not provide for communication of such data 

Re: [PATCH 0/82] changing CONFIG_LOCALVERSION rebuilds too much, for no good reason.

[Rogier Wolff]

On Sun, Jul 10, 2005 at 09:18:15PM -0700, Nish Aravamudan wrote:
> one for the SCSI subsystem. If those individual driver maintainers'
> files are being modified, should they be CC'ed, or is the big patch
> just sent to the SCSI maintainer (in this example)? I just want to
> make sure the correct patch-chain is respected.

As a patch maintainer, CCed on ONE of the 82 patches, I wouldn't have
minded getting CCed on a patch that included the change to my driver. 
(as chunk xx/82 in the diff).

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

UML build broken on 2.6.13-rc3-mm1

[Miklos Szeredi]

I get the following build failure on 2.6.13-rc3-mm1.  It builds fine
on 2.6.13-rc3.

Can anybody help fixing it?

Thanks,
Miklos
  
/usr/src/quilt/linux$ make ARCH=um V=1
if test ! /usr/src/quilt/linux -ef /usr/src/quilt/linux; then \
/bin/sh /usr/src/quilt/linux/scripts/mkmakefile  \
/usr/src/quilt/linux /usr/src/quilt/linux 2 6 \
> /usr/src/quilt/linux/Makefile; \
echo '  GEN/usr/src/quilt/linux/Makefile';   \
fi
  CHK include/linux/version.h
rm -rf .tmp_versions
mkdir -p .tmp_versions
make -f scripts/Makefile.build obj=scripts/basic
make -f scripts/Makefile.build obj= /mk_sc
scripts/Makefile.build:13: /Makefile: No such file or directory
scripts/Makefile.build:64: kbuild: Makefile.build is included improperly
make[1]: *** No rule to make target `/Makefile'.  Stop.
make: *** [/mk_sc] Error 2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFD] FAT robustness

[Hiroyuki Machida]

Folks,

I'd like to have a discussion about FAT robustness.
Please give your thought, comments and related issues.

About few years ago, we added some features to FAT, called xvfat,
so that System and FAT have robustness against unexpected media hot
unplug and ability to let applications correctly be aware the event.

Just for your reference, I put a patch to 2.4.20 kernel at
http://www.celinuxforum.org/CelfPubWiki/XvFatDiscussion?action=AttachFile=get=20050715-xvfat-2.4.20.patch
This includes following features;

Handle media removed during “mount”
Notification of media removal to application
Cancellation of I/O Elevator for Block device
Block system calls until a completion of writing
Control order of meta-data updates, using transaction   
control implemented in fs/xvfat/fwrq.c
File syscall return “error”, except umount
Japanese file name support
possible 1-N mapping issues SJIS <-> UNICODE
Dirty Flag support
TIME ZONE support

On moving to 2.6, we consider and categorize issues, again.
And we are planing to have open source project for these features
to add 2.6 kernel.  I'd like to open discussion about these features
and how to implement on 2.6 kernel.

1. Issues to be addressed

- Issues around FAT with CE devices
 - Hot unplug issues
- File System corruption on unplug  media/storage device
Almost same as power down without umount

- Notification of the event
Application need to know the event precisely
Need to more investigation

- System stability after unplug
Almost same as I/O error recovery issues discussed
at LKLM
http://developer.osdl.jp/projects/doubt/fs-consistency-and-coherency/index.html

http://groups.google.co.jp/group/linux.kernel/browse_thread/thread/b9c11bccd59e0513/4a4dd84b411c6d32?q=[RFD]+FS+behavior+(I%2FO+failure)+in+kernel+summit++lkml=1=ja#4a4dd84b411c6d32


 - Other issues
- Time stamp issues
using always local time
time resolution is 2sec unit

- Issues around mapping with UNICODE and local char code
1-N mapping SJIS<-> UNICODE
Potential directory cache problem due to 1 –N mapping
Possible inconsistency problems with application side

- Support file size over 2GB

- Support dirty flag

 Q1 : First issue for discussion is "Do you have any other issues
about this?" and "Do you have any other idea to categorize
the issues?"


2.  FAT corruption on unplug  media/storage device

On starting the open source project, we focus to the following issue,
first.
- File System corruption on unplug  media/storage device
Almost same as power down without umount

And, we are planing to focus on HDD device and treat system power down
instead of unplug media, because
 A. Damages and it's counter methods may depend on property of lower
layer
E.g.
  - Memory Card
Some controller can guaranty atomicity of certain
operations
  - Flush Memory (NAND, NOR)
I/O operations may be constrained by Block Size
(e,g, 128KB) or Page Size (e.g. 2KB)
 - HDD
- Cache memory my resident inside in
		- Sector which is under writing 
		on power down may be corrupted(can't read anymore)


 B.  It may make the problem easier
- Sector size is 512 Byte
- Many developers may check with PC

 Q2 : Do you know any other storage devices and it's property, to 
	be address later?


3. Features to be developed for FAT corruption.

We currently plan to add following features to address FAT corruption.

   - Utilize standard 2.6 features as much as possible
- Implement as options of fat, vfat and uvfat
- Utilize existent journal block device (JBD) for transaction control
- Utilize noop elevator to cancel unexpected operation
 reordering
   - Coordinate order of operations so that update data first, meta
 data later with transaction control
   - With O_SYNC, close() make flush all related data and
 meta-data, then wait completion of I/O


 Q3 : I'm not sure JBD can be used for FAT improvements. 
  Do you have any comments ?



Thanks,
Hiroyuki Machida



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Preserve hibenate-system-image on startup

[Hiroyuki Machida]

We are now investigating fast startup/shutdown using
2.6 kernel PM functions.

An attached patch enables kernel to preserve system image
on startup, to implement "Snapshot boot"[EMAIL PROTECTED] wrote:
Conventionally system image will be broken after startup.

Snapshot boot uses un-hibernate from a permanent system image for
startup. During shutdown, does a conventional shutdown without
saving a system image.

We'll explain concept and initial work at OLS. So if you have
interest, we can talk with you at Ottawa.

Thanks,
Hiroyuki Machida

---

This patch enables preserving swsuspend system image over boot cycle, 
against 2.6.12

Signed-off-by: Hiroyui Machida <[EMAIL PROTECTED]> for CELF

-
Index: alp-linux--dev-2-6-12--1.7/kernel/power/Kconfig
===
--- alp-linux--dev-2-6-12--1.7.orig/kernel/power/Kconfig2005-07-15 
14:59:20.0 -0400
+++ alp-linux--dev-2-6-12--1.7/kernel/power/Kconfig 2005-07-16 
00:43:31.42000 -0400
@@ -84,6 +84,20 @@
  suspended image to. It will simply pick the first available swap 
  device.
 
+config PRESERVE_SWSUSP_IMAGE
+   bool "Preserve swsuspend image"
+   depends on SOFTWARE_SUSPEND
+   default n
+   ---help---
+ Useally boot with swsup destories the swsusp image.
+ This function enables to preserve swsup image over boot cycle. 
+ Default behavior is not chaged even this configuration turned on.
+
+ To preseve swsusp image, specify following option to command line;
+
+   prsv-img
+
+
 config DEFERRED_RESUME
bool "Deferred resume"
depends on PM
Index: alp-linux--dev-2-6-12--1.7/kernel/power/disk.c
===
--- alp-linux--dev-2-6-12--1.7.orig/kernel/power/disk.c 2005-07-16 
00:43:02.99000 -0400
+++ alp-linux--dev-2-6-12--1.7/kernel/power/disk.c  2005-07-16 
01:01:42.22000 -0400
@@ -29,10 +29,29 @@
 extern void swsusp_close(void);
 extern int swsusp_resume(void);
 extern int swsusp_free(void);
+extern void dump_pagedir_nosave(void);
 #ifdef CONFIG_SAFE_SUSPEND
 extern int suspend_remount(void);
 extern int resume_remount(void);
 #endif
+#ifdef CONFIG_PRESERVE_SWSUSP_IMAGE
+extern int preserve_swsusp_image;
+extern dev_t swsusp_resume_device_nosave __nosavedata;
+extern int swsusp_swap_rdonly(dev_t);
+extern int swsusp_swap_off(dev_t);
+#else
+#define preserve_swsusp_image 0
+#define swsusp_resume_device_nosave 0
+static inline int swsusp_swap_rdonly(dev_t dev)
+{
+   return 0;
+}
+static inline int swsusp_swap_off(dev_t dev)
+{
+   return 0;
+}
+#endif
+
 
 
 static int noresume = 0;
@@ -135,6 +154,26 @@
pm_restore_console();
 }
 
+#ifdef CONFIG_PRESERVE_SWSUSP_IMAGE
+void finish_in_resume(void)
+{
+   device_resume();
+   platform_finish();
+   enable_nonboot_cpus();
+   thaw_processes();
+   if (preserve_swsusp_image) {
+   swsusp_swap_off(swsusp_resume_device_nosave);
+   }
+   pm_restore_console();
+}
+#else
+void finish_in_resume(void)
+{
+   finish();
+}
+#endif
+
+
 extern atomic_t on_suspend;   /* See refrigerator() */
 
 static int prepare_processes(void)
@@ -234,8 +273,15 @@
error = swsusp_write();
if (!error)
power_down(pm_disk_mode);
-   } else
+   } else  {
pr_debug("PM: Image restored successfully.\n");
+   if (preserve_swsusp_image) {
+   swsusp_swap_rdonly(swsusp_resume_device_nosave);
+   }
+   swsusp_free();
+   finish_in_resume();
+   return 0;
+   }
swsusp_free();
  Done:
finish();
Index: alp-linux--dev-2-6-12--1.7/kernel/power/swsusp.c
===
--- alp-linux--dev-2-6-12--1.7.orig/kernel/power/swsusp.c   2005-07-16 
00:43:03.0 -0400
+++ alp-linux--dev-2-6-12--1.7/kernel/power/swsusp.c2005-07-16 
00:56:22.17000 -0400
@@ -128,6 +128,11 @@
 
 static struct swsusp_info swsusp_info;
 
+#ifdef CONFIG_PRESERVE_SWSUSP_IMAGE
+dev_t swsusp_resume_device_nosave __nosavedata;
+struct swsusp_header swsusp_header_nosave __nosavedata ;
+#endif
+
 /*
  * XXX: We try to keep some more pages free so that I/O operations succeed
  * without paging. Might this be more?
@@ -139,6 +144,24 @@
 #define PAGES_FOR_IO   512
 #endif
 
+#ifdef CONFIG_PRESERVE_SWSUSP_IMAGE
+int preserve_swsusp_image=0;
+static  int __init preserve_swsusp_image_setup(char *str)
+{
+   if (*str)
+   return 0;
+   preserve_swsusp_image = 1;
+   return 1;
+}
+#else
+static  int __init preserve_swsusp_image_setup(char *str)
+{
+   return 0;
+}
+#endif
+
+__setup("prsv-img", preserve_swsusp_image_setup);
+
 /*
  * Saving part...
  */
@@ -1250,6 +1273,53 @@
return error;
 }
 
+#ifdef 

2.6.12-rc2 and as-iosched

[Kenneth Parrish]

 System: FamilyNet HQ
   Area: Internet-Email, Internet E-mail
   Date: Jul 16 2005  22:45
   From: Kenneth Parrish
 To: linux-kernel@vger.kernel.org
   Subj: 2.6.12-rc2 and as-iosched

v2.6.13-rc2 as-iosched.c and /sys/block/hda/queue/iosched/* values differ:
[..]
Oops, HZ=250, so correct.

... The later PDP-11s supported 4MB.
--- MultiMail/Linux v0.46
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.12-rc2 and as-iosched

[Kenneth Parrish]

 System: FamilyNet HQ
   Area: Internet-Email, Internet E-mail
   Date: Jul 16 2005  22:45
   From: Kenneth Parrish
 To: linux-kernel@vger.kernel.org
   Subj: 2.6.12-rc2 and as-iosched

v2.6.13-rc2 as-iosched.c and /sys/block/hda/queue/iosched/* values differ:
[..]
Oops, HZ=250, so correct.

... The later PDP-11s supported 4MB.
--- MultiMail/Linux v0.46
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Preserve hibenate-system-image on startup

[Hiroyuki Machida]

We are now investigating fast startup/shutdown using
2.6 kernel PM functions.

An attached patch enables kernel to preserve system image
on startup, to implement Snapshot boot[EMAIL PROTECTED] wrote:
Conventionally system image will be broken after startup.

Snapshot boot uses un-hibernate from a permanent system image for
startup. During shutdown, does a conventional shutdown without
saving a system image.

We'll explain concept and initial work at OLS. So if you have
interest, we can talk with you at Ottawa.

Thanks,
Hiroyuki Machida

---

This patch enables preserving swsuspend system image over boot cycle, 
against 2.6.12

Signed-off-by: Hiroyui Machida [EMAIL PROTECTED] for CELF

-
Index: alp-linux--dev-2-6-12--1.7/kernel/power/Kconfig
===
--- alp-linux--dev-2-6-12--1.7.orig/kernel/power/Kconfig2005-07-15 
14:59:20.0 -0400
+++ alp-linux--dev-2-6-12--1.7/kernel/power/Kconfig 2005-07-16 
00:43:31.42000 -0400
@@ -84,6 +84,20 @@
  suspended image to. It will simply pick the first available swap 
  device.
 
+config PRESERVE_SWSUSP_IMAGE
+   bool Preserve swsuspend image
+   depends on SOFTWARE_SUSPEND
+   default n
+   ---help---
+ Useally boot with swsup destories the swsusp image.
+ This function enables to preserve swsup image over boot cycle. 
+ Default behavior is not chaged even this configuration turned on.
+
+ To preseve swsusp image, specify following option to command line;
+
+   prsv-img
+
+
 config DEFERRED_RESUME
bool Deferred resume
depends on PM
Index: alp-linux--dev-2-6-12--1.7/kernel/power/disk.c
===
--- alp-linux--dev-2-6-12--1.7.orig/kernel/power/disk.c 2005-07-16 
00:43:02.99000 -0400
+++ alp-linux--dev-2-6-12--1.7/kernel/power/disk.c  2005-07-16 
01:01:42.22000 -0400
@@ -29,10 +29,29 @@
 extern void swsusp_close(void);
 extern int swsusp_resume(void);
 extern int swsusp_free(void);
+extern void dump_pagedir_nosave(void);
 #ifdef CONFIG_SAFE_SUSPEND
 extern int suspend_remount(void);
 extern int resume_remount(void);
 #endif
+#ifdef CONFIG_PRESERVE_SWSUSP_IMAGE
+extern int preserve_swsusp_image;
+extern dev_t swsusp_resume_device_nosave __nosavedata;
+extern int swsusp_swap_rdonly(dev_t);
+extern int swsusp_swap_off(dev_t);
+#else
+#define preserve_swsusp_image 0
+#define swsusp_resume_device_nosave 0
+static inline int swsusp_swap_rdonly(dev_t dev)
+{
+   return 0;
+}
+static inline int swsusp_swap_off(dev_t dev)
+{
+   return 0;
+}
+#endif
+
 
 
 static int noresume = 0;
@@ -135,6 +154,26 @@
pm_restore_console();
 }
 
+#ifdef CONFIG_PRESERVE_SWSUSP_IMAGE
+void finish_in_resume(void)
+{
+   device_resume();
+   platform_finish();
+   enable_nonboot_cpus();
+   thaw_processes();
+   if (preserve_swsusp_image) {
+   swsusp_swap_off(swsusp_resume_device_nosave);
+   }
+   pm_restore_console();
+}
+#else
+void finish_in_resume(void)
+{
+   finish();
+}
+#endif
+
+
 extern atomic_t on_suspend;   /* See refrigerator() */
 
 static int prepare_processes(void)
@@ -234,8 +273,15 @@
error = swsusp_write();
if (!error)
power_down(pm_disk_mode);
-   } else
+   } else  {
pr_debug(PM: Image restored successfully.\n);
+   if (preserve_swsusp_image) {
+   swsusp_swap_rdonly(swsusp_resume_device_nosave);
+   }
+   swsusp_free();
+   finish_in_resume();
+   return 0;
+   }
swsusp_free();
  Done:
finish();
Index: alp-linux--dev-2-6-12--1.7/kernel/power/swsusp.c
===
--- alp-linux--dev-2-6-12--1.7.orig/kernel/power/swsusp.c   2005-07-16 
00:43:03.0 -0400
+++ alp-linux--dev-2-6-12--1.7/kernel/power/swsusp.c2005-07-16 
00:56:22.17000 -0400
@@ -128,6 +128,11 @@
 
 static struct swsusp_info swsusp_info;
 
+#ifdef CONFIG_PRESERVE_SWSUSP_IMAGE
+dev_t swsusp_resume_device_nosave __nosavedata;
+struct swsusp_header swsusp_header_nosave __nosavedata ;
+#endif
+
 /*
  * XXX: We try to keep some more pages free so that I/O operations succeed
  * without paging. Might this be more?
@@ -139,6 +144,24 @@
 #define PAGES_FOR_IO   512
 #endif
 
+#ifdef CONFIG_PRESERVE_SWSUSP_IMAGE
+int preserve_swsusp_image=0;
+static  int __init preserve_swsusp_image_setup(char *str)
+{
+   if (*str)
+   return 0;
+   preserve_swsusp_image = 1;
+   return 1;
+}
+#else
+static  int __init preserve_swsusp_image_setup(char *str)
+{
+   return 0;
+}
+#endif
+
+__setup(prsv-img, preserve_swsusp_image_setup);
+
 /*
  * Saving part...
  */
@@ -1250,6 +1273,53 @@
return error;
 }
 
+#ifdef CONFIG_PRESERVE_SWSUSP_IMAGE
+/**

[RFD] FAT robustness

[Hiroyuki Machida]

Folks,

I'd like to have a discussion about FAT robustness.
Please give your thought, comments and related issues.

About few years ago, we added some features to FAT, called xvfat,
so that System and FAT have robustness against unexpected media hot
unplug and ability to let applications correctly be aware the event.

Just for your reference, I put a patch to 2.4.20 kernel at
http://www.celinuxforum.org/CelfPubWiki/XvFatDiscussion?action=AttachFiledo=gettarget=20050715-xvfat-2.4.20.patch
This includes following features;

Handle media removed during “mount”
Notification of media removal to application
Cancellation of I/O Elevator for Block device
Block system calls until a completion of writing
Control order of meta-data updates, using transaction   
control implemented in fs/xvfat/fwrq.c
File syscall return “error”, except umount
Japanese file name support
possible 1-N mapping issues SJIS - UNICODE
Dirty Flag support
TIME ZONE support

On moving to 2.6, we consider and categorize issues, again.
And we are planing to have open source project for these features
to add 2.6 kernel.  I'd like to open discussion about these features
and how to implement on 2.6 kernel.

1. Issues to be addressed

- Issues around FAT with CE devices
 - Hot unplug issues
- File System corruption on unplug  media/storage device
Almost same as power down without umount

- Notification of the event
Application need to know the event precisely
Need to more investigation

- System stability after unplug
Almost same as I/O error recovery issues discussed
at LKLM
http://developer.osdl.jp/projects/doubt/fs-consistency-and-coherency/index.html

http://groups.google.co.jp/group/linux.kernel/browse_thread/thread/b9c11bccd59e0513/4a4dd84b411c6d32?q=[RFD]+FS+behavior+(I%2FO+failure)+in+kernel+summit++lkmlrnum=1hl=ja#4a4dd84b411c6d32


 - Other issues
- Time stamp issues
using always local time
time resolution is 2sec unit

- Issues around mapping with UNICODE and local char code
1-N mapping SJIS- UNICODE
Potential directory cache problem due to 1 –N mapping
Possible inconsistency problems with application side

- Support file size over 2GB

- Support dirty flag

 Q1 : First issue for discussion is Do you have any other issues
about this? and Do you have any other idea to categorize
the issues?


2.  FAT corruption on unplug  media/storage device

On starting the open source project, we focus to the following issue,
first.
- File System corruption on unplug  media/storage device
Almost same as power down without umount

And, we are planing to focus on HDD device and treat system power down
instead of unplug media, because
 A. Damages and it's counter methods may depend on property of lower
layer
E.g.
  - Memory Card
Some controller can guaranty atomicity of certain
operations
  - Flush Memory (NAND, NOR)
I/O operations may be constrained by Block Size
(e,g, 128KB) or Page Size (e.g. 2KB)
 - HDD
- Cache memory my resident inside in
		- Sector which is under writing 
		on power down may be corrupted(can't read anymore)


 B.  It may make the problem easier
- Sector size is 512 Byte
- Many developers may check with PC

 Q2 : Do you know any other storage devices and it's property, to 
	be address later?


3. Features to be developed for FAT corruption.

We currently plan to add following features to address FAT corruption.

   - Utilize standard 2.6 features as much as possible
- Implement as options of fat, vfat and uvfat
- Utilize existent journal block device (JBD) for transaction control
- Utilize noop elevator to cancel unexpected operation
 reordering
   - Coordinate order of operations so that update data first, meta
 data later with transaction control
   - With O_SYNC, close() make flush all related data and
 meta-data, then wait completion of I/O


 Q3 : I'm not sure JBD can be used for FAT improvements. 
  Do you have any comments ?



Thanks,
Hiroyuki Machida



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

UML build broken on 2.6.13-rc3-mm1

[Miklos Szeredi]

I get the following build failure on 2.6.13-rc3-mm1.  It builds fine
on 2.6.13-rc3.

Can anybody help fixing it?

Thanks,
Miklos
  
/usr/src/quilt/linux$ make ARCH=um V=1
if test ! /usr/src/quilt/linux -ef /usr/src/quilt/linux; then \
/bin/sh /usr/src/quilt/linux/scripts/mkmakefile  \
/usr/src/quilt/linux /usr/src/quilt/linux 2 6 \
 /usr/src/quilt/linux/Makefile; \
echo '  GEN/usr/src/quilt/linux/Makefile';   \
fi
  CHK include/linux/version.h
rm -rf .tmp_versions
mkdir -p .tmp_versions
make -f scripts/Makefile.build obj=scripts/basic
make -f scripts/Makefile.build obj= /mk_sc
scripts/Makefile.build:13: /Makefile: No such file or directory
scripts/Makefile.build:64: kbuild: Makefile.build is included improperly
make[1]: *** No rule to make target `/Makefile'.  Stop.
make: *** [/mk_sc] Error 2
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/82] changing CONFIG_LOCALVERSION rebuilds too much, for no good reason.

[Rogier Wolff]

On Sun, Jul 10, 2005 at 09:18:15PM -0700, Nish Aravamudan wrote:
 one for the SCSI subsystem. If those individual driver maintainers'
 files are being modified, should they be CC'ed, or is the big patch
 just sent to the SCSI maintainer (in this example)? I just want to
 make sure the correct patch-chain is respected.

As a patch maintainer, CCed on ONE of the 82 patches, I wouldn't have
minded getting CCed on a patch that included the change to my driver. 
(as chunk xx/82 in the diff).

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/