Re: [2.6 patch] drivers/isdn/hardware/eicon/: misc possible cleanups

[Armin Schindler]

On Wed, 9 Feb 2005, Adrian Bunk wrote:
> On Sun, Feb 06, 2005 at 11:18:18AM +0100, Armin Schindler wrote:
> 
> > Hi Adrian,
> 
> Hi Armin,
> 
> > thanks for the proposed patch.
> > Making the functions static is a good idea, I will check and test this.
> > Removing some functions, especially from io.* and di.* is not good. These 
> > functions are mainly used with other sub-drivers which are not part of the
> > kernel. I will check if they are some really outdated and the removals in 
> > message.c.
> 
> silly question:
> Why are these sub-drivers not included in the kernel?

These drivers are for older cards and are not fully ported to kernel 2.6. 
I never really intended to put this old stuff into kernel 2.6.
The code of io.* and di.* is common code for all supported platforms, so I
always try to reduce changes here.
Like my last patch, I will try to remove unused code in linux with a
preparser in my code-controller. So eventually the mentioned code is really
unsused and can be removed. 
I will check all this in the next days and prepare a new patch.

Armin

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

Re: [PATCH] Fix ALPS sync loss

[Vojtech Pavlik]

On Tue, Feb 08, 2005 at 06:40:12PM -0500, Dmitry Torokhov wrote:
> Hi,
> 
> Here is the promised patch. It turns out protocol validation code was
> a bit (or rather a byte ;) ) off.
> 
> Please let me know if it fixes your touchpad and I believe it would be
> nice to have it in 2.6.11.

Yes, I can't reproduce sync losses that were possible to create with
simultaneous use of the pad anf the touchpoint. Patch applied.

> 
> ===
> 
> 
> [EMAIL PROTECTED], 2005-02-08 18:12:06-05:00, [EMAIL PROTECTED]
>   Input: alps - fix protocol validation rules causing touchpad
>  to lose sync if an absolute packet is received after
>  a relative packet with negative Y displacement.
>   
>   Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
>   
> 
> 
>  alps.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> 
> ===
> 
> 
> 
> diff -Nru a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> --- a/drivers/input/mouse/alps.c  2005-02-08 18:16:27 -05:00
> +++ b/drivers/input/mouse/alps.c  2005-02-08 18:16:27 -05:00
> @@ -198,8 +198,8 @@
>   return PSMOUSE_BAD_DATA;
>  
>   /* Bytes 2 - 6 should have 0 in the highest bit */
> - if (psmouse->pktcnt > 1 && psmouse->pktcnt <= 6 &&
> - (psmouse->packet[psmouse->pktcnt] & 0x80))
> + if (psmouse->pktcnt >= 2 && psmouse->pktcnt <= 6 &&
> + (psmouse->packet[psmouse->pktcnt - 1] & 0x80))
>   return PSMOUSE_BAD_DATA;
>  
>   if (psmouse->pktcnt == 6) {
> 

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

Re: Question regarding e1000 driver and dropped packets (2.6.5 / 2.6.10)?

[Bukie Mabayoje]

Bukie Mabayoje wrote:

> Can you do a simple test?
> Connect the two box to the same switch. ( No other box should be on the 
> physical bus)
> 1. Send packets from BoxA  --->   BoxB  ( Record the stats)
>
> 2. Send packets from BoxB ---> BoxA(Record the stats)
>
> 3. Send packets simultaneously  from  BoxB->BoxA and BoxA  -> BoxB  
> (Record the stats)
>
> if you can find a third box
>
> 4. Send packets [BoxA and BoxC] ->   BoxB and BoxB -> BoxA 
> (Record the stats)
>
> 5. Send packets [BoxB and BoxC] -> BoxA and BoxA --> BoxB (Record 
> the stats)
>
> I don't understand why you received more packet on BoxB. A controlled test 
> will help clarify any ambiguity.
>   [BoxA]   RX packets:196787934 errors:4 dropped:0 overruns:0 frame:2
> TX packets:101356779 errors:0 dropped:0 overruns:0 
> carrier:0
>
>  [BoxB]RX packets:446380046 errors:1276833 dropped:1276833 
> overruns:1276833 frame:0
> TX packets:572550636 errors:0 dropped:0 overruns:0 
> carrier:0
>
> Justin Piszcz wrote:
>
> > I have two identical machines [mobo/hardware wise]:
> >
> > Each machine is a Dell GX1p (500MHZ).
> >
> > I have two Intel Gigabit NICs, one in each box, hooked up to a GigE
> > switch.
> >
> > Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller
> > Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller
> >
> > I doubt its the kernel version; does anyone have any suggestions/ideas why
> > one machine has virtually NO overruns/errors/drops and the other has tons?
> >
> > Also, (I doubt this to be the case but I'll ask anyway) - Is the way the
> > NIC's are setup in the box next to other cards / alter their PCI/IRQ
> > routing which would effect error/drop rates?
> >
> > IE:
> >
> > PCI1 - promise card / pata
> > PCI2 - promise card / pata
> > PCI3 - promise card / sata
> > PCI4 - e1000 nic
> > PCI5 - 4 port nic
>
> What matters is which INT# [A,B,C,D] line and/or combination  the PCI slot 1, 
> 2, 3, 4 is using.
> You can find out by running lspci -vv
> If they are routed to the same system interrupt and  lastly, the interrupt 
> priority issues.
>
> >
> >
> > Would it make sense to order them in a different direction?
>
> May not help in identifying the problem.
>
> >
> >
> > Also, is there a correlation between errors on the NIC and ERR
> > in /proc/interrupts?
>
> Maybe..
>
> >
> >
> > Secondly, could loading lm-sensors/temperature modules be causing these
> > problems?
>
> You don't have any overrun on this box.

My Error. It may be related. Try without loading ln-sensor/temp modules.
I don't think your mother board supports the i2c stuff you are loading.
You have the Intel 440BX AGP chipset and there is not i2c interface on it.

>
>
> >
> >
> > dmesg from box2 below:
> >
> > e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
> > eth1: Setting full-duplex based on MII#1 link partner capability of 45e1.
> > eth2: Setting full-duplex based on MII#1 link partner capability of 45e1.
> > nfs warning: mount version older than kernel
> > nfs warning: mount version older than kernel
> > nfs warning: mount version older than kernel
> > nfs warning: mount version older than kernel
> > i2c /dev entries driver
> > piix4_smbus :00:07.3: Found :00:07.3 device
> > piix4_smbus :00:07.3: WARNING: SMBus interface has been FORCEFULLY
> > ENABLED!
> > mtrr: no MTRR for fd00,80 found
> > spurious 8259A interrupt: IRQ7.
> > spurious 8259A interrupt: IRQ15.
> >
> > I am currently out of ideas, if anyone can suggest anything, I'd be most
> > greatful, thanks!
> >
> > On the first box, there are hardly any problems receiving packets:
> >
> > Note the errors & dropped on the receiving end:
> >
> > BOX1: (2.6.5)
> >
> > eth0  Link encap:Ethernet  HWaddr 00:0E:0C:00:CD:B1
> >inet addr:10.0.2.254  Bcast:10.0.2.255  Mask:255.255.255.0
> >inet6 addr: fe80::20e:cff:fe00:cdb1/64 Scope:Link
> >UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >RX packets:196787934 errors:4 dropped:0 overruns:0 frame:2
> >TX packets:101356779 errors:0 dropped:0 overruns:0 carrier:0
> >collisions:0 txqueuelen:1000
> >RX bytes:2602045376 (2481.5 Mb)  TX bytes:4051930608 (3864.2 Mb)
> >Base address:0xcc80 Memory:ff02-ff04
> >
> > BOX1 MODULES:
> >
> > $ lsmod
> > Module  Size  Used by
> > ip_nat_ftp  4016  0
> > ip_conntrack_ftp   71088  1 ip_nat_ftp
> >
> > BOX2: (2.6.10)
> >
> > On another box (same physical HW) I get this:
> >
> > eth0  Link encap:Ethernet  HWaddr 00:0E:0C:00:D2:06
> >inet addr:10.0.2.253  Bcast:10.0.2.255  Mask:255.255.255.0
> >UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> > -->   RX packets:446380046 errors:1276833 dropped:1276833 
> > overruns:1276833 frame:0
> >TX packets:572550636 errors:0 

Re: [RFC] Linux Kernel Subversion Howto

[Alexandre Oliva]

On Feb  8, 2005, [EMAIL PROTECTED] (Larry McVoy) wrote:

> I think you are dreaming.  You've gone from wanting enough information
> to supposedly debug your source tree to being explicit about wanting to
> recreate the entire BK history in a different system.

> The answer is no, that's a clear violation of the license.

So you've somehow managed to trick most kernel developers into
granting you power over not only the BK history, in such a way that
anyone willing to extract all the information available from the BK
repository and share it with others is forbidden from doing so by the
license?

> I'm quite unhappy you keep asking for this, it forces me into the
> position of being the bad guy.  You need to understand that we can
> only take on so much risk and giving you BK for free was a huge amount
> of risk.

I'd much rather you didn't ``giveÂÂ it at all, then people wouldn't be
locked into it, and the community might have come up with something as
efficient earlier with the extra push.  Now we're faced with choices
such as keeping on with a presumably technically-good but non-Free
software, or switching to a Free and hopefully as-good software and
losing history.  Clever trick, indeed!

> Giving you BK, and the right to use it to create a different
> system, and/or the right to use the BK metadata to create a different
> system is way too much risk.

Is it even legal to attempt to stop someone from sharing information
that is not owned by you?  Or did you get to own all of the metadata
in the repository?

> I don't come here every month and ask for the GPL to be removed from
> some driver, that's essentially what you are doing

I don't think so.  What he's doing is more along the lines of `hey,
this allegedly-GPLed driver contains a piece of binary firmware whose
source code is not there, could we either replace it with actual GPLed
code or remove the driver?

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kernel/fork.c: VM accounting bugfix (2.6.11-rc3-bk5)

[Chris Wright]

Hi Mark,

* Mark F. Haigh ([EMAIL PROTECTED]) wrote:
> [Aargh!  Missing Signed-off-by.]
> 
> Unless I'm missing something, in kernel/fork.c, dup_mmap():
> 
>   if (security_vm_enough_memory(len))
>   goto fail_nomem;
> /* ... */
> fail_nomem:
>   retval = -ENOMEM;
>   vm_unacct_memory(charge);
> /* ... */
> 
> If security_vm_enough_memory() fails there, then we vm_unacct_memory()
> that we never accounted (if security_vm_enough_memory() fails, no memory
> is accounted).

You missed one subtle point.  That failure case actually unaccts 0 pages
(note the use of charge).  Not the nicest, but I believe correct.

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] OProfile: exit.text referenced in init.text

[Zwane Mwaikambo]

The linker doesn't complain, but i got this error on ARM which has 
similar code.

oprofile_arch_exit: discarded in section `.exit.text' from 
arch/arm/oprofile/built-in.o
arch/arm/oprofile/built-in.o(.init.text+0x4c): In function `oprofile_init':
: relocation truncated to fit: R_ARM_PC24 oprofile_arch_exit

oprofile_arch_init()

oprofile_arch_exit()
__exit nmi_exit()
__exit exit_driverfs()

Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>

= arch/i386/oprofile/nmi_int.c 1.27 vs edited =
--- 1.27/arch/i386/oprofile/nmi_int.c   2005-01-30 23:33:47 -07:00
+++ edited/arch/i386/oprofile/nmi_int.c 2005-02-08 23:08:33 -07:00
@@ -70,7 +70,7 @@ static int __init init_driverfs(void)
 }
 
 
-static void __exit exit_driverfs(void)
+static void exit_driverfs(void)
 {
sysdev_unregister(_oprofile);
sysdev_class_unregister(_sysclass);
@@ -420,7 +420,7 @@ int __init nmi_init(struct oprofile_oper
 }
 
 
-void __exit nmi_exit(void)
+void nmi_exit(void)
 {
if (using_nmi)
exit_driverfs();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm1: two oops on startup

[Clemens Schwaighofer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/09/2005 03:09 PM, Andrew Morton wrote:
> Clemens Schwaighofer <[EMAIL PROTECTED]> wrote:
> 
>>during startup I get too oops on my Box
> 
> 
> Yes, it is being worked on.  You'll need to CONFIG_INOTIFY=n, thanks.

okay, thanks.

- --
[ Clemens Schwaighofer  -=:~ ]
[ TBWA\ && TEQUILA\ Japan IT Group   ]
[6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCCapCjBz/yQjBxz8RAmcKAJ4oYmg9aLy07R7bXfOVjRza+9N9FACgty/B
LiRsNye+unxwpJXzc/PYyTw=
=HP/o
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm1: two oops on startup

[Andrew Morton]

Clemens Schwaighofer <[EMAIL PROTECTED]> wrote:
>
> during startup I get too oops on my Box

Yes, it is being worked on.  You'll need to CONFIG_INOTIFY=n, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm1: two oops on startup

[Clemens Schwaighofer]

Hi,

during startup I get too oops on my Box. It's a debian/unstable. dmesg
from right after the start and the kernel config are attached.

-- 
[ Clemens Schwaighofer  -=:~ ]
[ TBWA\ && TEQUILA\ Japan IT Group   ]
[6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.11-rc3-mm1
# Wed Feb  9 12:39:10 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=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 is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_BASE_FULL=y
CONFIG_BASE_SMALL=0
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_MATH_EMULATION=y
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y
CONFIG_REGPARM=y

#
# Performance-monitoring counters support
#
CONFIG_PERFCTR=y
CONFIG_PERFCTR_INIT_TESTS=y
CONFIG_PERFCTR_VIRTUAL=y
CONFIG_PERFCTR_INTERRUPT_SUPPORT=y
CONFIG_PHYSICAL_START=0x10
# CONFIG_KEXEC is not set

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION="/dev/hda2"

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_X86_PM_TIMER is not set
# CONFIG_ACPI_CONTAINER is not set

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
CONFIG_APM_RTC_IS_GMT=y
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y

Re: [RFC] Linux Kernel Subversion Howto

[Gene Heskett]

On Tuesday 08 February 2005 21:57, Roman Zippel wrote:
>Hi,
>
>On Tue, 8 Feb 2005, Jon Smirl wrote:
>> Write up a proposal of what you need. Send it to Larry and ask for
>> a quote. Larry will probably even help you fill in things you
>> missed in the proposal. Come to an agreement on terms for the
>> proposal. Raise the cash, send it to Larry, wait for the work to
>> be finished. Now you have your solution.
>
>I appreciate your optimism, but think about it: why would he insist
> on doing it himself and prefers to call me thief instead, if we
> were talking about the same kind of "exporting the complete kernel
> history"?
>
>bye, Roman

Roman, Larry has a perfectly valid reason to call you a jerk, because 
you are being one, and have been one for at least 50% of your posts 
on this list over the last 2 years or more.  Right this instant my 
most fervent wish is for you to go get a job at M$ or something, and 
leave us the hell alone.  Either put up the $$ for Larry to take time 
from other profitable endeavors and do it, or STFU.

Jon, the only way I'd contribute a tenner to match your is if somebody 
held it in escrow till the job is done.

-- 
No Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.32% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Linux Kernel Subversion Howto

[Kevin Puetz]

Olaf Dietsche wrote:

> Stelian Pop <[EMAIL PROTECTED]> writes:
> 
>> I must test this...), plus 600 MB per working copy.
> 
> If you use svk  for the client side, there's
> (almost?) no overhead.
> 
> Regards, Olaf.

erm, svk is cool and all, but it keeps a local repository mirror (not
necessarily full I suppose, but usually it is). So it's *much* heavier on
the client side than normal svn. Pays off in several ways, but just because
it keeps it's weight in the depot folder instead of the wc folder doesn't
make it ligher (unless you use several wc's I suppose).

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

2.4.x kernel BUG at filemap.c:81

[Todd Shetter]

Running slackware 10 and 10.1, with kernels 2.4.26, 2.4.27, 2.4.28, 
2.4.29 with highmem 4GB, and highmem i/o support enabled, I get a system 
lockup. This happens in both X and console. Happens with and without my 
Nvidia drivers loaded. I cannot determine what makes this bug present it 
self besides highmem and high i/o support enabled. Im guessing the 
system is fine until highmem is actually used to some point and then it 
borks, but I really have no idea and so im just making a random guess. I 
ran memtest86 for a few hours a while ago thinking that it may be bad 
memory, but that did not seem to be the problem.

If you need anymore information, or have questions, or wish me to test 
anything, PLEASE feel free to contact me, I would really like to see 
this bug resolved. =)

--
Todd Shetter
Feb  8 19:49:31 quark kernel: kernel BUG at filemap.c:81!
Feb  8 19:49:31 quark kernel: invalid operand: 
Feb  8 19:49:31 quark kernel: CPU:0
Feb  8 19:49:31 quark kernel: EIP:0010:[]Tainted: P
Feb  8 19:49:31 quark kernel: EFLAGS: 00210206
Feb  8 19:49:31 quark kernel: eax: 4000   ebx: c18012f0   ecx: 
   edx: f7f06e60
Feb  8 19:49:31 quark kernel: esi: 0001   edi: f7f06e60   ebp: 
f3461e9c   esp: f3461e98
Feb  8 19:49:31 quark kernel: ds: 0018   es: 0018   ss: 0018
Feb  8 19:49:31 quark kernel: Process hdparm (pid: 2191, stackpage=f3461000)
Feb  8 19:49:31 quark kernel: Stack: c18012f0 f3461eb0 c0128c78 f07d0360 
c18012f0 47a0 f3461edc c0128d20
Feb  8 19:49:31 quark kernel:c18012f0 f07d0360 47a0 f7f06e60 
f7f06e60 eed4ab34 47a0 
Feb  8 19:49:31 quark kernel:eed4ab34 f3461f00 c012941e 001f 
479f 0020 012a1f16 f7f06de4
Feb  8 19:49:31 quark kernel: Call Trace:[] [] 
[] [] []
Feb  8 19:49:31 quark kernel:   [] [] [] 
[] []
Feb  8 19:49:31 quark kernel:
Feb  8 19:49:31 quark kernel: Code: 0f 0b 51 00 a8 05 2e c0 6a 01 53 e8 
ef 7e 00 00 8b 5d fc 89


00:00.0 Host bridge: Intel Corp. 82875P Memory Controller Hub (rev 02)
   Subsystem: ABIT Computer Corp.: Unknown device 1014
   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
   Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
SERR- 
   Latency: 0
   Region 0: Memory at e800 (32-bit, prefetchable) [size=128M]
   Capabilities: [e4] #09 [2106]
   Capabilities: [a0] AGP version 3.0
   Status: RQ=32 Iso- ArqSz=2 Cal=2 SBA+ ITACoh- GART64- HTrans- 
64bit- FW+ AGP3+ Rate=x4,x8
   Command: RQ=1 ArqSz=0 Cal=2 SBA+ AGP+ GART64- 64bit- FW- Rate=x8

00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP Controller (rev 
02) (prog-if 00 [Normal decode])
   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
   Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
SERR- 
   Latency: 64
   Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
   I/O behind bridge: f000-0fff
   Memory behind bridge: f800-faff
   Prefetchable memory behind bridge: f000-f7ff
   BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-

00:03.0 PCI bridge: Intel Corp. 82875P Processor to PCI to CSA Bridge 
(rev 02) (prog-if 00 [Normal decode])
   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
   Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
SERR- 
   Latency: 32
   Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
   I/O behind bridge: a000-afff
   Memory behind bridge: fb00-fb0f
   Prefetchable memory behind bridge: fff0-000f
   BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-

00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB/ER Hub interface to PCI 
Bridge (rev c2) (prog-if 00 [Normal decode])
   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
   Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
SERR- 
   Latency: 0
   Bus: primary=00, secondary=03, subordinate=03, sec-latency=32
   I/O behind bridge: f000-0fff
   Memory behind bridge: fff0-000f
   Prefetchable memory behind bridge: fff0-000f
   BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-

00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02)
   Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
   Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
   Latency: 0

00:1f.2 IDE interface: Intel Corp. 82801EB (ICH5) Serial ATA 150 Storage 
Controller (rev 02) (prog-if 8a [Master SecP PriP])
   Subsystem: ABIT Computer Corp.: Unknown device 1014
   Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
   Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
   Latency: 0
   Interrupt: pin A routed to IRQ 11
   Region 0: I/O ports at 
   Region 1: I/O ports at 

Re: 2.6.10 kprobes/jprobes panic

[Prasanna S Panchamukhi]

Hi Badri,

> Hi,
> 
> I ran into this while playing with jprobes in 2.6.10.
> 
> I tried to install jprobe handler on a invalid address,

User should prevent inserting jprobes on an invalid address.

> I get OOPS. I was hoping for a error check and a graceful
> exit rather than kernel Oops.
> 

Error check and graceful exit can be done in the jprobe handler
module. In the jprobe network packet logging patch, error check
was taken care by using kallsyms_lookup_name() as shown below.

nt->jp.kp.addr = (kprobe_opcode_t *)
kallsyms_lookup_name(nt->funcname);
if (nt->jp.kp.addr) {
printk("plant jprobe at %s (%p), handler addr %p\n",
   nt->funcname, nt->jp.kp.addr, nt->jp.entry);
register_jprobe(>jp);
} else {
printk("couldn't find %s to plant jprobe\n",
   nt->funcname);
}. 

Please see the patch at the URL for more details.
http://lkml.org/lkml/2004/8/16/179

Thanks
Prasanna


> Unable to handle kernel paging request at c01836b0 RIP:
> {__memcpy+114}
> PML4 17d6cf067 PGD 0
> Oops:  [1] SMP
> CPU 1
> Modules linked in: diotest
> Pid: 14225, comm: insmod Not tainted 2.6.10n
> RIP: 0010:[] {__memcpy+114}
> RSP: 0018:01019b841d58  EFLAGS: 00010047
> RAX: ffa7 RBX: 0101bfa44200 RCX: 
> RDX: 000f RSI: c01836b0 RDI: ffa7
> RBP: a8e0 R08: 01018000 R09: 
> R10: 0101bfa44218 R11: 0111 R12: 0216
> R13: 804f1440 R14: 0020 R15: 0002
> FS:  002a9588e6e0() GS:80628800()
> knlGS:55970080
> CS:  0010 DS:  ES:  CR0: 8005003b
> CR2: c01836b0 CR3: 0001a072c000 CR4: 06e0
> Process insmod (pid: 14225, threadinfo 01019b84, task
> 0101bf9394e0)
> Stack: 0101bfa44200 8011edcc 0212
> a8e0
>ffef 80158542 804f1480
> a940
>804f1440 a05c
> Call Trace:{arch_prepare_kprobe+300}
> {register_kprobe+82}
>{:diotest:init_dmods+44}
> {sys_init_module+6387}
>{__pagevec_free+32}
> {release_pages+382}
>{do_munmap+918}
> {__down_read+49}
>{__up_write+48}
> {system_call+126}
>   
>
>   
>
> Code: 4c 8b 06 4c 89 07 48 8d 7f 08 48 8d 76 08 75 ee 89 d1 83 e1
> RIP {__memcpy+114} RSP <01019b841d58>
> CR2: c01836b0
> 
> 
> 

-- 

Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Ph: 91-80-25044636
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Makefiles are not built using a Fortran compiler

[Sam Ravnborg]

Hi Kai - long time..

> > The SCCS rules is the sole reason why -rR has not been enabled.
> 
> An easy way to make sure that the SCCS business is not a factor would be 
> to explicitly put the SCCS rules into the Makefile -- it's just two lines.

Yup, I will do that when 2.6.11 opens up.
If other rules are needed I will add them.

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: VM disk cache behavior.

[Kevin Puetz]

Andy Isaacson wrote:

> Most likely is that your app isn't behaving in a cache-friendly way.ÂÂIf
> your file will fit in memory, just fault it in sequentially (wc -l file)
> and then your app should cook.ÂÂIfÂyou'reÂnotÂgoingÂtoÂfitÂinÂmemory,
> the vm caching will probably only help if you have some reuse; you could
> develop a pre-faulter to get your IO started ahead of time, but that's
> generally nontrivial.

Of course, what's non-trivial is predicting your upcoming I/O pattern
(unless it's not actually random at all, just messy). Calling madvise to
prefault it is pretty easy if you actually do know what you'll want in the
near future.

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

Re: 2.6.11-rc3-mm1

[Zwane Mwaikambo]

On Wed, 9 Feb 2005, Marcos D. Marado Torres wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Fri, 4 Feb 2005, Andrew Morton wrote:
> 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm1/
> 
> Andrew,
> 
> Please add to -mm the patch in attachment, since it solves the old
> acpi_power_off bug...

Where is the original bug report? Is the set_cpus_allowed the problem?

+#if 0  /* This should be made redundant by other patches.. */
/* Some SMP machines only can poweroff in boot CPU */
set_cpus_allowed(current, cpumask_of_cpu(0));
-   acpi_wakeup_gpe_poweroff_prepare();
-   acpi_enter_sleep_state_prep(ACPI_STATE_S5);
+#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm1

[Andrew Morton]

"Marcos D. Marado Torres" <[EMAIL PROTECTED]> wrote:
>
> Please add to -mm the patch in attachment, since it solves the old
>  acpi_power_off bug...

What acpi_power_off bug?  And how does it solve it?

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

Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement

[Paul Jackson]

Nick wrote:
> The biggest issues may be the userspace
> interface and a decent userspace management tool.

One possibility, perhaps, would be to have a boolean flag "sched_domain"
on each cpuset, indicating whether it was a sched domain or not.  If a
cpuset had its sched_domain flag set, then that cpusets cpus_allowed
mask would define a sched domain.

Later Nick wrote:
> In the (hopefully) common case where there are disjoint partitions
> _somewhere_, sched domains can do the job in a much better
> way than task cpu affinities (better isolation, multiprocessor
> balancing shouldn't break down).
> 
> Those users with overlapping CPU sets can then use task affinities
> on top of sched domains partitions to get the desired result.

Ok - seems it should work with the above cpuset flag marking sched
domains, and a rule that _those_ cpusets so marked can't overlap.  Other
cpusets that are not so marked, and any sched_setaffinity calls, can do
whatever they want.  Trying to turn on the sched_domain flag on a cpuset
that overlapped with existing such cpuset sched_domains, or trying to
mess with the CPUs (cpus_allowed) in an existing cpuset sched_domain so
as to force it to overlap, would return an error to user space on that
write(2).

If the sysadmin didn't mark any cpusets as sched_domains, then fall back
to something automatic and useful.

Inside the kernel, we'll need someway for the cpuset code to tell the
sched code about sched_domain changes.  This might mean something like
the following.  Have the sched code provide the cpuset code a couple of
routines, one to setup and and the other to tear down sched_domains.

Both calls would take a cpumask_t argument, and return void.  The setup
call must pass a cpumask that does not overlap any existing sched
domains defined via cpusets.  The tear down call must pass a cpumask
value exactly matching a previous, still active, setup call.

So if someone made a single CPU change to an existing sched_domain
defining cpuset, the kernel cpuset code would have to call the kernel
sched code twice, first to tear down the old sched_domain, and then to
setup the new, slightly different, one.  The cpuset code would likely be
holding the single global cpuset_sem semaphore across this pair of
calls.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm1

[Marcos D. Marado Torres]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 4 Feb 2005, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm1/
Andrew,
Please add to -mm the patch in attachment, since it solves the old
acpi_power_off bug...
Best Regards,
Marcos Marado
- -- 
/* *** */
   Marcos Daniel Marado Torres	 AKA	Mind Booster Noori
   http://student.dei.uc.pt/~marado   -	  [EMAIL PROTECTED]
   () Join the ASCII ribbon campaign against html email, Microsoft
   /\ attachments and Software patents.   They endanger the World.
   Sign a petition against patents:  http://petition.eurolinux.org
/* *** */
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFCCYpxmNlq8m+oD34RAsJQAKDmBDtuPseiQkpSfZfiiCG05xDoOwCfZvKc
sQje5ivpItBbcTYqTP1gKvU=
=90/h
-END PGP SIGNATURE-
diff -Nru -p1 linux-2.6.11-rc2-mm1/drivers/acpi/sleep/poweroff.c 
linux-2.6.11-rc2-mm1-mbn1/drivers/acpi/sleep/poweroff.c
--- linux-2.6.11-rc2-mm1/drivers/acpi/sleep/poweroff.c  2004-12-24 
22:35:39.0 +0100
+++ linux-2.6.11-rc2-mm1-mbn1/drivers/acpi/sleep/poweroff.c 2005-01-26 
00:25:04.0 +0100
@@ -9,2 +9,3 @@
 #include 
+#include 
 #include 
@@ -13,2 +14,20 @@
 
+static void 
+acpi_power_off_prepare(void)
+{
+   if (system_state == SYSTEM_POWER_OFF) {
+   acpi_wakeup_gpe_poweroff_prepare();
+   acpi_enter_sleep_state_prep(ACPI_STATE_S5);
+   }
+}
+
+void 
+do_acpi_power_off_prepare(void)
+{
+   if (!acpi_disabled) {
+   acpi_power_off_prepare();
+   }
+}
+   
+
 static void
@@ -17,6 +36,6 @@ acpi_power_off (void)
printk("%s called\n",__FUNCTION__);
+#if 0  /* This should be made redundant by other patches.. */
/* Some SMP machines only can poweroff in boot CPU */
set_cpus_allowed(current, cpumask_of_cpu(0));
-   acpi_wakeup_gpe_poweroff_prepare();
-   acpi_enter_sleep_state_prep(ACPI_STATE_S5);
+#endif
ACPI_DISABLE_IRQS();
diff -Nru -p1 linux-2.6.11-rc2-mm1/drivers/base/power/shutdown.c 
linux-2.6.11-rc2-mm1-mbn1/drivers/base/power/shutdown.c
--- linux-2.6.11-rc2-mm1/drivers/base/power/shutdown.c  2004-12-24 
22:35:01.0 +0100
+++ linux-2.6.11-rc2-mm1-mbn1/drivers/base/power/shutdown.c 2005-01-26 
00:26:54.0 +0100
@@ -64,2 +64,9 @@ void device_shutdown(void)
 
+#if 1
+   {
+   extern void do_acpi_power_off_prepare(void);
+   do_acpi_power_off_prepare();
+   }
+#endif
+   
sysdev_shutdown();

[PATCH] kernel/fork.c: VM accounting bugfix (2.6.11-rc3-bk5)

[Mark F. Haigh]

[Aargh!  Missing Signed-off-by.]
Unless I'm missing something, in kernel/fork.c, dup_mmap():
if (security_vm_enough_memory(len))
goto fail_nomem;
/* ... */
fail_nomem:
retval = -ENOMEM;
vm_unacct_memory(charge);
/* ... */
If security_vm_enough_memory() fails there, then we vm_unacct_memory()
that we never accounted (if security_vm_enough_memory() fails, no memory
is accounted).
If it is in fact a bug, a simple but largely untested patch (against
2.6.11-rc3-bk5) is included.
Mark F. Haigh
[EMAIL PROTECTED]
Signed-off-by: Mark F. Haigh  <[EMAIL PROTECTED]>
--- linux-2.6.11-rc3-bk5/kernel/fork.c.orig 2005-02-08 19:12:26.254589504 
-0800
+++ linux-2.6.11-rc3-bk5/kernel/fork.c  2005-02-08 19:16:30.756419576 -0800
@@ -193,8 +193,10 @@
charge = 0;
if (mpnt->vm_flags & VM_ACCOUNT) {
unsigned int len = (mpnt->vm_end - mpnt->vm_start) >> 
PAGE_SHIFT;
-   if (security_vm_enough_memory(len))
-   goto fail_nomem;
+   if (security_vm_enough_memory(len)) {
+   retval = -ENOMEM;
+   goto out;
+   }
charge = len;
}
tmp = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);

[PATCH] kernel/fork.c: VM accounting bugfix (2.6.11-rc3-bk5)

[Mark F. Haigh]

Unless I'm missing something, in kernel/fork.c, dup_mmap():
if (security_vm_enough_memory(len))
goto fail_nomem;
/* ... */
fail_nomem:
retval = -ENOMEM;
vm_unacct_memory(charge);
/* ... */
If security_vm_enough_memory() fails there, then we vm_unacct_memory() 
that we never accounted (if security_vm_enough_memory() fails, no memory 
is accounted).

If it is in fact a bug, a simple but largely untested patch (against 
2.6.11-rc3-bk5) is included.

Mark F. Haigh
[EMAIL PROTECTED]
--- linux-2.6.11-rc3-bk5/kernel/fork.c.orig 2005-02-08 19:12:26.254589504 
-0800
+++ linux-2.6.11-rc3-bk5/kernel/fork.c  2005-02-08 19:16:30.756419576 -0800
@@ -193,8 +193,10 @@
charge = 0;
if (mpnt->vm_flags & VM_ACCOUNT) {
unsigned int len = (mpnt->vm_end - mpnt->vm_start) >> 
PAGE_SHIFT;
-   if (security_vm_enough_memory(len))
-   goto fail_nomem;
+   if (security_vm_enough_memory(len)) {
+   retval = -ENOMEM;
+   goto out;
+   }
charge = len;
}
tmp = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);

Re: [RFC] Linux Kernel Subversion Howto

[Larry McVoy]

On Wed, Feb 09, 2005 at 03:47:49AM +0100, Roman Zippel wrote:
> Hi,
> 
> On Tue, 8 Feb 2005, Larry McVoy wrote:
> 
> > Nice, Roman.  All I need is a cooperating third party who is willing to
> > give me your code under a different (albeit invalid) license.
> 
> Short version: Bullshit.
> Long version: See previous mails.

Let's try that again:

Short version: let's violate a license.
Long version: let's violate a license and see if we get in trouble.

Roman, we can do this forever.  Every time you cause a fuss more people
become aware of how unreasonable you are being.  That's fine with me,
come on back and flame some more.  

Our position is clear: we are trying to do the right thing for Linux,
we've developed a business model which works, we're committed to helping
Linux.  Yup, you're right, we aren't helping *you* in a way you like.
On the other hand, we are helping you, we've been doing it for years,
and we've been doing it in spite of you being a complete jerk about it.
And we'll keep doing it no matter how much of a jerk you want to
be because, surprise!, it isn't really about you.  It's about Linux.
And in so far as Linux is concerned, you are even less relevant than we
are and we aren't that big of a deal.  So Linux wins, you get to complain,
life goes on.

You know, you could change all this.  Instead of complaining that we
are somehow hurting you, which virtually 100% of the readers know is
nonsense, you could be producing an alternative answer which is better.
Instead of doing that you keep whining that we aren't helping you do that
and that isn't fair.  Hey, come on, get a grip.  I'm not out hear whining
that the GPL isn't fair to my agenda even though it frequently isn't.
I work around it if it is important.  If not using BK is important to you
then don't use it.  If having a free software SCM system is important to
you then create one.  But whining that we aren't helping you is beyond
pathetic and I am 100% positive I'm not alone in that opinion.
-- 
---
Larry McVoylm at bitmover.com   http://www.bitkeeper.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

again cifs oops in 2.6.8.1

[Clemens Schwaighofer]

-BEGIN PGP SIGNED MESSAGE-
(BHash: SHA1
(B
(BHi,
(B
(BI got again too cifs oops:
(B
(BFeb  7 18:17:07 ramen kernel: c02180d4
(BFeb  7 18:17:07 ramen kernel: SMP
(BFeb  7 18:17:07 ramen kernel: Modules linked in: loop ntfs appletalk ipx
(Bp8022 psnap llc usbcore
(BFeb  7 18:17:07 ramen kernel: CPU:1
(BFeb  7 18:17:07 ramen kernel: EIP:0060:[cifs_readdir+2401/3445]
(BNot tainted
(BFeb  7 18:17:07 ramen kernel: EFLAGS: 00010246   (2.6.8.1)
(BFeb  7 18:17:07 ramen kernel: EIP is at cifs_readdir+0x961/0xd75
(BFeb  7 18:17:07 ramen kernel: eax: c050c480   ebx: d3b79f4c   ecx:
(Bf7db1340   edx: 91982a8e
(BFeb  7 18:17:07 ramen kernel: esi:    edi: e9048bce   ebp:
(Bd3b79f68   esp: d3b79ee0
(BFeb  7 18:17:07 ramen kernel: ds: 007b   es: 007b   ss: 0068
(BFeb  7 18:17:07 ramen kernel: Process smbd (pid: 30224,
(Bthreadinfo=d3b78000 task=cbc4b290)
(BFeb  7 18:17:07 ramen kernel: Stack: d3b79f4c e70d41e0 cc0e8480 c050c480
(Bd3b79fa0 c050c480 d3b79f34 d3b79f38
(BFeb  7 18:17:07 ramen kernel:0001 03e9 e70d4000 91982a8e
(Bc229ab00 dec6bb80 f7db1340 0009
(BFeb  7 18:17:07 ramen kernel:4000 000c0451  4204f254
(B33390598 0001  000a1800
(BFeb  7 18:17:07 ramen kernel: Call Trace:
(BFeb  7 18:17:07 ramen kernel:  [show_stack+128/150] show_stack+0x80/0x96
(BFeb  7 18:17:07 ramen kernel:  [show_registers+351/430]
(Bshow_registers+0x15f/0x1ae
(BFeb  7 18:17:07 ramen kernel:  [die+141/251] die+0x8d/0xfb
(BFeb  7 18:17:07 ramen kernel:  [do_page_fault+708/1390]
(Bdo_page_fault+0x2c4/0x56e
(BFeb  7 18:17:07 ramen kernel:  [error_code+45/56] error_code+0x2d/0x38
(BFeb  7 18:17:07 ramen kernel:  [vfs_readdir+150/177] vfs_readdir+0x96/0xb1
(BFeb  7 18:17:07 ramen kernel:  [sys_getdents64+109/166]
(Bsys_getdents64+0x6d/0xa6
(BFeb  7 18:17:07 ramen kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
(BFeb  7 18:17:07 ramen kernel: Code: 8b 42 3c d1 e8 89 44 24 08 89 d0 83
(Bc0 40 89 44 24 04 89 04
(BFeb  7 18:17:27 ramen kernel:  <3> CIFS VFS: Error 0xffec or on
(Bcifs_get_inode_info in lookup
(B
(BFeb  9 07:59:17 ramen -- MARK --
(BFeb  9 08:05:22 ramen kernel: c02180d4
(BFeb  9 08:05:22 ramen kernel: SMP
(BFeb  9 08:05:22 ramen kernel: Modules linked in: loop ntfs appletalk ipx
(Bp8022 psnap llc usbcore
(BFeb  9 08:05:22 ramen kernel: CPU:1
(BFeb  9 08:05:22 ramen kernel: EIP:0060:[cifs_readdir+2401/3445]
(BNot tainted
(BFeb  9 08:05:22 ramen kernel: EFLAGS: 00010246   (2.6.8.1)
(BFeb  9 08:05:22 ramen kernel: EIP is at cifs_readdir+0x961/0xd75
(BFeb  9 08:05:22 ramen kernel: eax: c050c480   ebx: d1371f4c   ecx:
(Bf7db1340   edx: 9542b9d7
(BFeb  9 08:05:22 ramen kernel: esi:    edi: d0fcf1c6   ebp:
(Bd1371f68   esp: d1371ee0
(BFeb  9 08:05:22 ramen kernel: ds: 007b   es: 007b   ss: 0068
(BFeb  9 08:05:22 ramen kernel: Process find (pid: 32008,
(Bthreadinfo=d137 task=daf5c330)
(BFeb  9 08:05:22 ramen kernel: Stack: d1371f4c e987cf28 c99ee080 c050c480
(Bd1371fa0 c050c480 d1371f34 d1371f38
(BFeb  9 08:05:22 ramen kernel:0001 03e9 e987c000 9542b9d7
(Bd88c5100 d0fcfb80 f7db1340 002a
(BFeb  9 08:05:22 ramen kernel:4000 000ffaf5  4204f243
(B03b9aca0 0001  00291802
(BFeb  9 08:05:22 ramen kernel: Call Trace:
(BFeb  9 08:05:22 ramen kernel:  [show_stack+128/150] show_stack+0x80/0x96
(BFeb  9 08:05:22 ramen kernel:  [show_registers+351/430]
(Bshow_registers+0x15f/0x1ae
(BFeb  9 08:05:22 ramen kernel:  [die+141/251] die+0x8d/0xfb
(BFeb  9 08:05:22 ramen kernel:  [do_page_fault+708/1390]
(Bdo_page_fault+0x2c4/0x56e
(BFeb  9 08:05:22 ramen kernel:  [error_code+45/56] error_code+0x2d/0x38
(BFeb  9 08:05:22 ramen kernel:  [vfs_readdir+150/177] vfs_readdir+0x96/0xb1
(BFeb  9 08:05:22 ramen kernel:  [sys_getdents64+109/166]
(Bsys_getdents64+0x6d/0xa6
(BFeb  9 08:05:22 ramen kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
(BFeb  9 08:05:22 ramen kernel: Code: 8b 42 3c d1 e8 89 44 24 08 89 d0 83
(Bc0 40 89 44 24 04 89 04
(B
(B
(Bspecs:
(B
(BThe box is a Debian/Testing with a self compiled 2.6.8.1
(B
(Bramen:~# lsmod
(BModule  Size  Used by
(Bloop   13704  4
(Bntfs  131188  2
(Bappletalk  34384  20
(Bipx28324  0
(Bp8022   2688  1 ipx
(Bpsnap   3972  2 appletalk,ipx
(Bllc 6676  2 p8022,psnap
(Busbcore   102628  0
(B
(Bramen:~# lspci
(B:00:00.0 Host bridge: ServerWorks CMIC-WS Host Bridge (GC-LE
(Bchipset) (rev 13)
(B:00:00.1 Host bridge: ServerWorks CMIC-WS Host Bridge (GC-LE chipset)
(B:00:00.2 Host bridge: ServerWorks CMIC-LE
(B:00:03.0 VGA compatible controller: ATI Technologies Inc Rage XL
(B(rev 27)
(B:00:04.0 System peripheral: Compaq Computer Corporation Integrated
(BLights Out Controller (rev 01)
(B:00:04.2 System 

Re: [RFC] Linux Kernel Subversion Howto

[Jon Smirl]

On Wed, 9 Feb 2005 03:57:37 +0100 (CET), Roman Zippel
<[EMAIL PROTECTED]> wrote:
> Hi,
> 
> On Tue, 8 Feb 2005, Jon Smirl wrote:
> 
> > Write up a proposal of what you need. Send it to Larry and ask for a
> > quote. Larry will probably even help you fill in things you missed in
> > the proposal. Come to an agreement on terms for the proposal. Raise
> > the cash, send it to Larry, wait for the work to be finished. Now you
> > have your solution.
> 
> I appreciate your optimism, but think about it: why would he insist on
> doing it himself and prefers to call me thief instead, if we were talking
> about the same kind of "exporting the complete kernel history"?

Write up a proposal and send it in for a quote. See if Larry is a man
of his word and quotes you a fair price for doing the work. Post the
proposal and the quote. Then see if there is enough interest to fund
the project. There are probably ten tech news web sites that will make
a lead story out of this. Negotiating a true settlement is much better
than sending thousand of useless emails that achieve nothing.

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

[2.6 patch] drivers/isdn/tpam/: possible cleanups

[Adrian Bunk]

This patch makes the following possible cleanups:
- tpam_hdlc.c: make the needlessly global variable stuffs static
- tpam_nco.c: remove the unused global function build_ADestroyNCOReq

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

---

 drivers/isdn/tpam/tpam.h  |1 -
 drivers/isdn/tpam/tpam_hdlc.c |2 +-
 drivers/isdn/tpam/tpam_nco.c  |   27 ---
 3 files changed, 1 insertion(+), 29 deletions(-)

--- linux-2.6.11-rc3-mm1-full/drivers/isdn/tpam/tpam_hdlc.c.old 2005-02-09 
03:39:54.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/tpam/tpam_hdlc.c 2005-02-09 
03:40:02.0 +0100
@@ -548,7 +548,7 @@
 
 
 static WORD * stuffs[] = { stuff0, stuff1, stuff2, stuff3, stuff4, stuff5 };
-WORD * destuffs[] = { destuff0, destuff1, destuff2, destuff3, destuff4, 
destuff5 };
+static WORD * destuffs[] = { destuff0, destuff1, destuff2, destuff3, destuff4, 
destuff5 };
 
 
 /*- AuverTech Telecom ---+
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/tpam/tpam.h.old  2005-02-09 
03:40:16.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/tpam/tpam.h  2005-02-09 
03:40:21.0 +0100
@@ -181,7 +181,6 @@
 
 /* Function prototypes from tpam_nco.c */
 extern struct sk_buff *build_ACreateNCOReq(const u8 *);
-extern struct sk_buff *build_ADestroyNCOReq(u32);
 extern struct sk_buff *build_CConnectReq(u32, const u8 *, u8);
 extern struct sk_buff *build_CConnectRsp(u32);
 extern struct sk_buff *build_CDisconnectReq(u32);
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/tpam/tpam_nco.c.old  2005-02-09 
03:40:29.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/tpam/tpam_nco.c  2005-02-09 
03:42:52.0 +0100
@@ -131,33 +131,6 @@
 }
 
 /*
- * Build a ADestroyNCOReq message.
- *
- * ncoid: the NCO id.
- *
- * Return: the sk_buff filled with the NCO packet, or NULL if error.
- */
-struct sk_buff *build_ADestroyNCOReq(u32 ncoid) {
-   struct sk_buff *skb;
-   u8 *tlv;
-
-   pr_debug("TurboPAM(build_ADestroyNCOReq): ncoid=%lu\n",
-   (unsigned long)ncoid);
-
-   /* build the NCO packet */
-   if (!(skb = build_NCOpacket(ID_ADestroyNCOReq, 6, 0, 0, 0)))
-   return NULL;
-   
-   /* add the parameters */
-   tlv = (u8 *)skb_put(skb, 6);
-   *tlv = PAR_NCOID;
-   *(tlv+1) = 4;
-   *((u32 *)(tlv+2)) = ncoid;
-
-   return skb;
-}
-
-/*
  * Build a CConnectReq message.
  *
  * ncoid: the NCO id.

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

[2.6 patch] drivers/isdn/sc/: possible cleanups

[Adrian Bunk]

This patch contains the following possible cleanips:
- make some needlessly global code static
- remove the compiled but completely unused debug.c
- remove or #if 0 the following unused global functions:
  - command.c: loopback
  - command.c: loadproc
  - init.c: irq_supported
  - packet.c: print_skb
  - shmem.c: memset_shmem
  - timer.c: trace_timer

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

 drivers/isdn/sc/Makefile|2 
 drivers/isdn/sc/command.c   |   88 ++--
 drivers/isdn/sc/debug.c |   46 --
 drivers/isdn/sc/init.c  |   21 +---
 drivers/isdn/sc/interrupt.c |2 
 drivers/isdn/sc/ioctl.c |5 --
 drivers/isdn/sc/packet.c|   16 --
 drivers/isdn/sc/shmem.c |2 
 drivers/isdn/sc/timer.c |   18 ---
 9 files changed, 27 insertions(+), 173 deletions(-)

--- linux-2.6.11-rc3-mm1-full/drivers/isdn/sc/command.c.old 2005-02-09 
03:30:43.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/sc/command.c 2005-02-09 
03:34:19.0 +0100
@@ -22,14 +22,14 @@
 #include "card.h"
 #include "scioc.h"
 
-int dial(int card, unsigned long channel, setup_parm setup);
-int hangup(int card, unsigned long channel);
-int answer(int card, unsigned long channel);
-int clreaz(int card, unsigned long channel);
-int seteaz(int card, unsigned long channel, char *);
-int setl2(int card, unsigned long arg);
-int setl3(int card, unsigned long arg);
-int acceptb(int card, unsigned long channel);
+static int dial(int card, unsigned long channel, setup_parm setup);
+static int hangup(int card, unsigned long channel);
+static int answer(int card, unsigned long channel);
+static int clreaz(int card, unsigned long channel);
+static int seteaz(int card, unsigned long channel, char *);
+static int setl2(int card, unsigned long arg);
+static int setl3(int card, unsigned long arg);
+static int acceptb(int card, unsigned long channel);
 
 extern int cinst;
 extern board *sc_adapter[];
@@ -148,56 +148,6 @@
 }
 
 /*
- * Confirm our ability to communicate with the board.  This test assumes no
- * other message activity is present
- */
-int loopback(int card) 
-{
-
-   int status;
-   static char testmsg[] = "Test Message";
-   RspMessage rspmsg;
-
-   if(!IS_VALID_CARD(card)) {
-   pr_debug("Invalid param: %d is not a valid card id\n", card);
-   return -ENODEV;
-   }
-
-   pr_debug("%s: Sending loopback message\n",
-   sc_adapter[card]->devicename);
-
-   /*
-* Send the loopback message to confirm that memory transfer is
-* operational
-*/
-   status = send_and_receive(card, CMPID, cmReqType1,
- cmReqClass0,
- cmReqMsgLpbk,
- 0,
- (unsigned char) strlen(testmsg),
- (unsigned char *)testmsg,
- , SAR_TIMEOUT);
-
-
-   if (!status) {
-   pr_debug("%s: Loopback message successfully sent\n",
-   sc_adapter[card]->devicename);
-   if(strcmp(rspmsg.msg_data.byte_array, testmsg)) {
-   pr_debug("%s: Loopback return != sent\n",
-   sc_adapter[card]->devicename);
-   return -EIO;
-   }
-   return 0;
-   }
-   else {
-   pr_debug("%s: Send loopback message failed\n",
-   sc_adapter[card]->devicename);
-   return -EIO;
-   }
-
-}
-
-/*
  * start the onboard firmware
  */
 int startproc(int card) 
@@ -222,16 +172,10 @@
 }
 
 
-int loadproc(int card, char *data) 
-{
-   return -1;
-}
-
-
 /*
  * Dials the number passed in 
  */
-int dial(int card, unsigned long channel, setup_parm setup) 
+static int dial(int card, unsigned long channel, setup_parm setup) 
 {
int status;
char Phone[48];
@@ -261,7 +205,7 @@
 /*
  * Answer an incoming call 
  */
-int answer(int card, unsigned long channel) 
+static int answer(int card, unsigned long channel) 
 {
if(!IS_VALID_CARD(card)) {
pr_debug("Invalid param: %d is not a valid card id\n", card);
@@ -282,7 +226,7 @@
 /*
  * Hangup up the call on specified channel
  */
-int hangup(int card, unsigned long channel) 
+static int hangup(int card, unsigned long channel) 
 {
int status;
 
@@ -305,7 +249,7 @@
 /*
  * Set the layer 2 protocol (X.25, HDLC, Raw)
  */
-int setl2(int card, unsigned long arg) 
+static int setl2(int card, unsigned long arg) 
 {
int status =0;
int protocol,channel;
@@ -340,7 +284,7 @@
 /*
  * Set the layer 3 protocol
  */
-int setl3(int card, unsigned long channel) 
+static int setl3(int card, unsigned long channel) 
 {
int protocol = channel >> 8;
 
@@ -355,7 +299,7 @@
return 0;
 }
 
-int acceptb(int card, unsigned long channel)
+static int 

Re: [RFC] Linux Kernel Subversion Howto

[Roman Zippel]

Hi,

On Tue, 8 Feb 2005, Jon Smirl wrote:

> Write up a proposal of what you need. Send it to Larry and ask for a
> quote. Larry will probably even help you fill in things you missed in
> the proposal. Come to an agreement on terms for the proposal. Raise
> the cash, send it to Larry, wait for the work to be finished. Now you
> have your solution.

I appreciate your optimism, but think about it: why would he insist on 
doing it himself and prefers to call me thief instead, if we were talking 
about the same kind of "exporting the complete kernel history"?

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/

[2.6 patch] drivers/isdn/i4l/: possible cleanups

[Adrian Bunk]

This patch contains the following possible cleanups:
- make needlessly global code static
- remove the following unused global function:
  - isdn_audio.c: isdn_audio_2adpcm_flush
- remove the following unused struct:
  - isdn_net.c: isdn_concap_demand_dial_dops

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

---

 drivers/isdn/i4l/isdn_audio.c|   10 
 drivers/isdn/i4l/isdn_audio.h|1 
 drivers/isdn/i4l/isdn_common.c   |6 ++---
 drivers/isdn/i4l/isdn_common.h   |1 
 drivers/isdn/i4l/isdn_concap.c   |   15 ++--
 drivers/isdn/i4l/isdn_concap.h   |1 
 drivers/isdn/i4l/isdn_net.c  |   10 
 drivers/isdn/i4l/isdn_tty.c  |4 +--
 drivers/isdn/i4l/isdn_tty.h  |1 
 drivers/isdn/i4l/isdn_ttyfax.c   |6 ++---
 drivers/isdn/i4l/isdn_x25iface.c |   36 +++
 11 files changed, 34 insertions(+), 57 deletions(-)

--- linux-2.6.11-rc3-mm1-full/drivers/isdn/i4l/isdn_audio.h.old 2005-02-09 
03:17:36.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/i4l/isdn_audio.h 2005-02-09 
03:17:43.0 +0100
@@ -35,7 +35,6 @@
 extern adpcm_state *isdn_audio_adpcm_init(adpcm_state *, int);
 extern int isdn_audio_adpcm2xlaw(adpcm_state *, int, unsigned char *, unsigned 
char *, int);
 extern int isdn_audio_xlaw2adpcm(adpcm_state *, int, unsigned char *, unsigned 
char *, int);
-extern int isdn_audio_2adpcm_flush(adpcm_state * s, unsigned char *out);
 extern void isdn_audio_calc_dtmf(modem_info *, unsigned char *, int, int);
 extern void isdn_audio_eval_dtmf(modem_info *);
 dtmf_state *isdn_audio_dtmf_init(dtmf_state *);
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/i4l/isdn_audio.c.old 2005-02-09 
03:17:52.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/i4l/isdn_audio.c 2005-02-09 
03:18:02.0 +0100
@@ -392,16 +392,6 @@
 }
 
 int
-isdn_audio_2adpcm_flush(adpcm_state * s, unsigned char *out)
-{
-   int olen = 0;
-
-   if (s->nleft)
-   isdn_audio_put_bits(0, 8 - s->nleft, s, , );
-   return olen;
-}
-
-int
 isdn_audio_xlaw2adpcm(adpcm_state * s, int fmt, unsigned char *in,
  unsigned char *out, int len)
 {
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/i4l/isdn_common.h.old
2005-02-09 03:18:20.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/i4l/isdn_common.h2005-02-09 
03:18:26.0 +0100
@@ -41,7 +41,6 @@
 extern int  isdn_writebuf_skb_stub(int, int, int, struct sk_buff *);
 extern int  register_isdn(isdn_if * i);
 extern int  isdn_msncmp( const char *,  const char *);
-extern int  isdn_add_channels(isdn_driver_t *, int, int, int);
 #if defined(ISDN_DEBUG_NET_DUMP) || defined(ISDN_DEBUG_MODEM_DUMP)
 extern void isdn_dumppkt(char *, u_char *, int, int);
 #endif
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/i4l/isdn_common.c.old
2005-02-09 03:18:39.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/i4l/isdn_common.c2005-02-09 
03:19:12.0 +0100
@@ -67,7 +67,7 @@
 static int isdn_writebuf_stub(int, int, const u_char __user *, int);
 static void set_global_features(void);
 static int isdn_wildmat(char *s, char *p);
-
+static int isdn_add_channels(isdn_driver_t *d, int drvidx, int n, int adding);
 
 static inline void
 isdn_lock_driver(isdn_driver_t *drv)
@@ -388,7 +388,7 @@
  */
 #include 
 
-int
+static int
 isdn_capi_rec_hl_msg(capi_msg *cm) {

int di;
@@ -1923,7 +1923,7 @@
return ret;
 }
 
-int
+static int
 isdn_add_channels(isdn_driver_t *d, int drvidx, int n, int adding)
 {
int j, k, m;
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/i4l/isdn_concap.h.old
2005-02-09 03:19:25.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/i4l/isdn_concap.h2005-02-09 
03:19:47.0 +0100
@@ -8,7 +8,6 @@
  */
 
 extern struct concap_device_ops isdn_concap_reliable_dl_dops;
-extern struct concap_device_ops isdn_concap_demand_dial_dops;
 extern struct concap_proto * isdn_concap_new( int );
 
 
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/i4l/isdn_concap.c.old
2005-02-09 03:19:55.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/i4l/isdn_concap.c2005-02-09 
03:21:08.0 +0100
@@ -39,7 +39,7 @@
*/
 
 
-int isdn_concap_dl_data_req(struct concap_proto *concap, struct sk_buff *skb)
+static int isdn_concap_dl_data_req(struct concap_proto *concap, struct sk_buff 
*skb)
 {
struct net_device *ndev = concap -> net_dev;
isdn_net_dev *nd = ((isdn_net_local *) ndev->priv)->netdev;
@@ -58,7 +58,7 @@
 }
 
 
-int isdn_concap_dl_connect_req(struct concap_proto *concap)
+static int isdn_concap_dl_connect_req(struct concap_proto *concap)
 {
struct net_device *ndev = concap -> net_dev;
isdn_net_local *lp = (isdn_net_local *) ndev->priv;
@@ -71,7 +71,7 @@
return ret;
 }
 
-int isdn_concap_dl_disconn_req(struct concap_proto *concap)
+static int isdn_concap_dl_disconn_req(struct concap_proto *concap)
 {
IX25DEBUG( 

[2.6 patch] drivers/isdn/pcbit/: possible cleanups

[Adrian Bunk]

This patch contains the following possible cleanups:
- make some needlessly global functions static
- remove the following unused global functions:
  - callbacks.c: cb_out_3
  - capi.c: capi_decode_disc_conf

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

---

 drivers/isdn/pcbit/callbacks.c |   17 -
 drivers/isdn/pcbit/callbacks.h |3 ---
 drivers/isdn/pcbit/capi.c  |   10 --
 drivers/isdn/pcbit/capi.h  |1 -
 drivers/isdn/pcbit/drv.c   |   16 
 5 files changed, 8 insertions(+), 39 deletions(-)

--- linux-2.6.11-rc3-mm1-full/drivers/isdn/pcbit/callbacks.h.old
2005-02-09 03:27:18.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/pcbit/callbacks.h2005-02-09 
03:27:24.0 +0100
@@ -19,9 +19,6 @@
 extern void cb_out_2(struct pcbit_dev * dev, struct pcbit_chan* chan, 
 struct callb_data *data);
 
-extern void cb_out_3(struct pcbit_dev * dev, struct pcbit_chan* chan, 
-struct callb_data *data);
-
 extern void cb_in_1(struct pcbit_dev * dev, struct pcbit_chan* chan, 
struct callb_data *data);
 extern void cb_in_2(struct pcbit_dev * dev, struct pcbit_chan* chan, 
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/pcbit/callbacks.c.old
2005-02-09 03:27:32.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/pcbit/callbacks.c2005-02-09 
03:27:49.0 +0100
@@ -125,23 +125,6 @@
 
 
 /*
- * Disconnect received (actually RELEASE COMPLETE) 
- * This means we were not able to establish connection with remote
- * Inform the big boss above
- */
-void cb_out_3(struct pcbit_dev * dev, struct pcbit_chan* chan,
- struct callb_data *data) 
-{
-isdn_ctrl ictl;
-
-ictl.command = ISDN_STAT_DHUP;
-ictl.driver=dev->id;
-ictl.arg=chan->id;
-dev->dev_if->statcallb();
-}
-
-
-/*
  * Incoming call received
  * inform user
  */
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/pcbit/capi.h.old 2005-02-09 
03:28:06.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/pcbit/capi.h 2005-02-09 
03:28:14.0 +0100
@@ -54,7 +54,6 @@
 
 /* Connection Termination */
 extern int capi_disc_req(ushort callref, struct sk_buff **skb, u_char cause);
-extern int capi_decode_disc_conf(struct pcbit_chan *chan, struct sk_buff *skb);
 
 extern int capi_decode_disc_ind(struct pcbit_chan *chan, struct sk_buff *skb);
 extern int capi_disc_resp(struct pcbit_chan *chan, struct sk_buff **skb);
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/pcbit/capi.c.old 2005-02-09 
03:28:26.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/pcbit/capi.c 2005-02-09 
03:28:32.0 +0100
@@ -627,16 +627,6 @@
 return 0;
 }
 
-int capi_decode_disc_conf(struct pcbit_chan *chan, struct sk_buff *skb)
-{
-ushort errcode;
-
-errcode = *((ushort*) skb->data);
-skb_pull(skb, 2);
-
-return errcode;
-}
-
 #ifdef DEBUG
 int capi_decode_debug_188(u_char *hdr, ushort hdrlen)
 {
--- linux-2.6.11-rc3-mm1-full/drivers/isdn/pcbit/drv.c.old  2005-02-09 
03:29:07.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/isdn/pcbit/drv.c  2005-02-09 
03:30:10.0 +0100
@@ -56,10 +56,10 @@
  * prototypes
  */
 
-int pcbit_command(isdn_ctrl* ctl);
-int pcbit_stat(u_char __user * buf, int len, int, int);
-int pcbit_xmit(int driver, int chan, int ack, struct sk_buff *skb);
-int pcbit_writecmd(const u_char __user *, int, int, int);
+static int pcbit_command(isdn_ctrl* ctl);
+static int pcbit_stat(u_char __user * buf, int len, int, int);
+static int pcbit_xmit(int driver, int chan, int ack, struct sk_buff *skb);
+static int pcbit_writecmd(const u_char __user *, int, int, int);
 
 static int set_protocol_running(struct pcbit_dev * dev);
 
@@ -238,7 +238,7 @@
 }
 #endif
 
-int pcbit_command(isdn_ctrl* ctl)
+static int pcbit_command(isdn_ctrl* ctl)
 {
struct pcbit_dev  *dev;
struct pcbit_chan *chan;
@@ -330,7 +330,7 @@
 }
 #endif
 
-int pcbit_xmit(int driver, int chnum, int ack, struct sk_buff *skb)
+static int pcbit_xmit(int driver, int chnum, int ack, struct sk_buff *skb)
 {
ushort hdrlen;
int refnum, len;
@@ -389,7 +389,7 @@
return len;
 }
 
-int pcbit_writecmd(const u_char __user *buf, int len, int driver, int channel)
+static int pcbit_writecmd(const u_char __user *buf, int len, int driver, int 
channel)
 {
struct pcbit_dev * dev;
int i, j;
@@ -713,7 +713,7 @@
 static int stat_st = 0;
 static int stat_end = 0;
 
-int pcbit_stat(u_char __user *buf, int len, int driver, int channel)
+static int pcbit_stat(u_char __user *buf, int len, int driver, int channel)
 {
int stat_count;
stat_count = stat_end - stat_st;

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

Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement

[Nick Piggin]

Matthew Dobson wrote:
Nick Piggin wrote:

I didn't really follow where that idea went, but I think at least
a few people thought that sort of functionality wasn't nearly
fancy enough! :)

Well, that's about how far the idea was supposed to go. ;)  I think 
named hierarchical sched_domains would offer the same functionality (at 
least for CPU partitioning) as CPUSETs.  I'm not sure who didn't think 
it was fancy enough, but if you or anyone else can describe CPUSETs 
configurations that couldn't be represented by sched_domains trees, I'd 
be very curious to hear about them.

OK. Someone mentioned wanting to do overlapping sets of CPUs. For
example, 3 groups, first can run on cpus 0 and 1, second 1 and 2,
third 2 and 0. However this in itself doesn't preculde the use of
sched-domains.
In the (hopefully) common case where there are disjoint partitions
_somewhere_, sched domains can do the job in a much better
way than task cpu affinities (better isolation, multiprocessor
balancing shouldn't break down).
Those users with overlapping CPU sets can then use task affinities
on top of sched domains partitions to get the desired result.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Linux Kernel Subversion Howto

[Roman Zippel]

Hi,

On Tue, 8 Feb 2005, Larry McVoy wrote:

> Nice, Roman.  All I need is a cooperating third party who is willing to
> give me your code under a different (albeit invalid) license.

Short version: Bullshit.
Long version: See previous mails.

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: [RFC] Linux Kernel Subversion Howto

[Larry McVoy]

On Wed, Feb 09, 2005 at 03:35:37AM +0100, Roman Zippel wrote:
> Hi,
> 
> On Tue, 8 Feb 2005, Jon Smirl wrote:
> 
> > Larry has said he will do the work you want if you pay him.
> 
> Usually I'm all for giving the benefit of the doubt, but in this case I'd 
> prefer to know exactly, what I would get for the money.
> But as I said by now I know enough about this that I can do the job 
> myself, all I need is a cooperating bk user.

Translation: someone else who is welling to violate the BK license
because I don't want to take the risk.  

Nice, Roman.  All I need is a cooperating third party who is willing to
give me your code under a different (albeit invalid) license.
-- 
---
Larry McVoylm at bitmover.com   http://www.bitkeeper.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Linux Kernel Subversion Howto

[Jon Smirl]

On Wed, 9 Feb 2005 03:35:37 +0100 (CET), Roman Zippel
<[EMAIL PROTECTED]> wrote:
> Hi,
> 
> On Tue, 8 Feb 2005, Jon Smirl wrote:
> 
> > Larry has said he will do the work you want if you pay him.
> 
> Usually I'm all for giving the benefit of the doubt, but in this case I'd
> prefer to know exactly, what I would get for the money.

Write up a proposal of what you need. Send it to Larry and ask for a
quote. Larry will probably even help you fill in things you missed in
the proposal. Come to an agreement on terms for the proposal. Raise
the cash, send it to Larry, wait for the work to be finished. Now you
have your solution.


-- 
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: [RFC] Linux Kernel Subversion Howto

[Roman Zippel]

Hi,

On Tue, 8 Feb 2005, Jon Smirl wrote:

> Larry has said he will do the work you want if you pay him.

Usually I'm all for giving the benefit of the doubt, but in this case I'd 
prefer to know exactly, what I would get for the money.
But as I said by now I know enough about this that I can do the job 
myself, all I need is a cooperating bk user.

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: out-of-line x86 "put_user()" implementation

[Richard Henderson]

On Tue, Feb 08, 2005 at 06:16:15PM -0800, Linus Torvalds wrote:
> I'd happily use your version, but I thought that some versions of gcc
> require that input output registers cannot overlap, and would refuse to do 
> that thing? But if you tell me differently..

No, you're thinking of

asm("" : "=a" (x) : : "eax")

where the clobber overlaps the inputs or outputs.


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

Re: out-of-line x86 "put_user()" implementation

[Richard Henderson]

On Tue, Feb 08, 2005 at 06:27:08PM -0800, Linus Torvalds wrote:
> That brings up another issue: if I don't care which registers a 64-bit 
> value goes into, can I get the "low reg" and "high reg" names some way?

Nope.  We never needed one in the i386 backend itself, so we never
added anything like that.


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

Re: out-of-line x86 "put_user()" implementation

[Linus Torvalds]

On Tue, 8 Feb 2005, Andrew Morton wrote:
> 
> I'll take patches from anyone ;)

You'll never live it down. Once you get a name for being easy, you'll
always be known as Andrew "patch-ho" Morton.

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

Re: out-of-line x86 "put_user()" implementation

[Linus Torvalds]

On Tue, 8 Feb 2005, Linus Torvalds wrote:
> 
> Hmm.. I always thought "A" was the _pairing_ of %eax/%edx, not "eax or
> edx"?

Ahh. Some testing shows that gcc really seems to think of it as "eax or 
edx", ie you can do

asm("uglee %0 %1": :"a" (1), "A" (2));

and it will output

movl$1, %eax
movl$2, %edx
uglee %eax %edx

without complaining. 

Live and learn. 

That brings up another issue: if I don't care which registers a 64-bit 
value goes into, can I get the "low reg" and "high reg" names some way? In 
this case I'm constrained, and do want eactly %eax:%edx, but in some other 
cases I might not care, and wouldn't mind having a

asm("addl %2,%L0 ; adcl $0,%H0"
:"=r" (ll_result)
:"r" (increment), "0" (ll_input));

to add a 32-bit number to a 64-bit one (this is totally made up, since gcc 
can probably generate this sequence itself, but you get the idea - 
allowing the asm to treat the low/high parts of the 64-bit entity 
separately, without forcing them into one specific pair).

v4 with your asm constrain fix appended.

Linus

-
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/02/08 18:18:46-08:00 [EMAIL PROTECTED] 
#   x86: make "put_user()" be out-of-line
#   
#   It's really too big to be inlined.
#   
#   Ingo tests and reports: this shrinks his kernel text size by
#   about 12kB (roughly 0.5%).
#   
#   Updated on input from Richard Henderson on how the "A" constraint
#   works on x86.
# 
# arch/i386/lib/putuser.S
#   2005/02/08 18:18:35-08:00 [EMAIL PROTECTED] +87 -0
# 
# include/asm-i386/uaccess.h
#   2005/02/08 18:18:35-08:00 [EMAIL PROTECTED] +27 -13
#   x86: make "put_user()" be out-of-line
# 
# arch/i386/lib/putuser.S
#   2005/02/08 18:18:35-08:00 [EMAIL PROTECTED] +0 -0
#   BitKeeper file /home/torvalds/v2.6/linux/arch/i386/lib/putuser.S
# 
# arch/i386/lib/Makefile
#   2005/02/08 18:18:34-08:00 [EMAIL PROTECTED] +1 -1
#   x86: make "put_user()" be out-of-line
# 
# arch/i386/kernel/i386_ksyms.c
#   2005/02/08 18:18:34-08:00 [EMAIL PROTECTED] +5 -0
#   x86: make "put_user()" be out-of-line
# 
diff -Nru a/arch/i386/kernel/i386_ksyms.c b/arch/i386/kernel/i386_ksyms.c
--- a/arch/i386/kernel/i386_ksyms.c 2005-02-08 18:25:22 -08:00
+++ b/arch/i386/kernel/i386_ksyms.c 2005-02-08 18:25:22 -08:00
@@ -97,6 +97,11 @@
 EXPORT_SYMBOL(__get_user_2);
 EXPORT_SYMBOL(__get_user_4);
 
+EXPORT_SYMBOL(__put_user_1);
+EXPORT_SYMBOL(__put_user_2);
+EXPORT_SYMBOL(__put_user_4);
+EXPORT_SYMBOL(__put_user_8);
+
 EXPORT_SYMBOL(strpbrk);
 EXPORT_SYMBOL(strstr);
 
diff -Nru a/arch/i386/lib/Makefile b/arch/i386/lib/Makefile
--- a/arch/i386/lib/Makefile2005-02-08 18:25:22 -08:00
+++ b/arch/i386/lib/Makefile2005-02-08 18:25:22 -08:00
@@ -3,7 +3,7 @@
 #
 
 
-lib-y = checksum.o delay.o usercopy.o getuser.o memcpy.o strstr.o \
+lib-y = checksum.o delay.o usercopy.o getuser.o putuser.o memcpy.o strstr.o \
bitops.o
 
 lib-$(CONFIG_X86_USE_3DNOW) += mmx.o
diff -Nru a/arch/i386/lib/putuser.S b/arch/i386/lib/putuser.S
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/arch/i386/lib/putuser.S   2005-02-08 18:25:22 -08:00
@@ -0,0 +1,87 @@
+/*
+ * __put_user functions.
+ *
+ * (C) Copyright 2005 Linus Torvalds
+ *
+ * These functions have a non-standard call interface
+ * to make them more efficient, especially as they
+ * return an error value in addition to the "real"
+ * return value.
+ */
+#include 
+
+
+/*
+ * __put_user_X
+ *
+ * Inputs: %eax[:%edx] contains the data
+ * %ecx contains the address
+ *
+ * Outputs:%eax is error code (0 or -EFAULT)
+ *
+ * These functions should not modify any other registers,
+ * as they get called from within inline assembly.
+ */
+
+#define ENTER  pushl %ebx ; GET_THREAD_INFO(%ebx)
+#define EXIT   popl %ebx ; ret
+
+.text
+.align 4
+.globl __put_user_1
+__put_user_1:
+   ENTER
+   cmpl TI_addr_limit(%ebx),%ecx
+   jae bad_put_user
+1: movb %al,(%ecx)
+   xorl %eax,%eax
+   EXIT
+
+.align 4
+.globl __put_user_2
+__put_user_2:
+   ENTER
+   movl TI_addr_limit(%ebx),%ebx
+   subl $1,%ebx
+   cmpl %ebx,%ecx
+   jae bad_put_user
+2: movw %ax,(%ecx)
+   xorl %eax,%eax
+   EXIT
+
+.align 4
+.globl __put_user_4
+__put_user_4:
+   ENTER
+   movl TI_addr_limit(%ebx),%ebx
+   subl $3,%ebx
+   cmpl %ebx,%ecx
+   jae bad_put_user
+3: movl %eax,(%ecx)
+   xorl %eax,%eax
+   EXIT
+
+.align 4
+.globl __put_user_8
+__put_user_8:
+   ENTER
+   movl TI_addr_limit(%ebx),%ebx
+   subl $7,%ebx
+   cmpl %ebx,%ecx
+   jae bad_put_user
+4: movl %eax,(%ecx)
+5: movl %edx,4(%ecx)
+   xorl %eax,%eax
+   EXIT
+
+bad_put_user:
+   movl $-14,%eax
+   EXIT
+
+.section __ex_table,"a"
+   .long 1b,bad_put_user
+   .long 2b,bad_put_user
+   .long 3b,bad_put_user
+   .long 4b,bad_put_user
+   .long 

[ANNOUNCE][RFC] PlugSched-3.0 meets CKRM-E17

[Peter Williams]

A patch of PlugSched-3.0 against a 2.6.10 kernel with 
ckrm-e17.2610.patch and cpu.ckrm-e17.v10.patch already applied is 
available for download from:


and a patchset and series file are available in at gzipped tarball at:

The model adopted in merging PlugSched with CKRM was to apply the CKRM 
mechanisms as an optional adjunct to each of the schedulers (ingosched, 
staircase, spa_no_frills and zaphod) which can be selected at boot time 
by adding "cpusched=" to the boot command line.  If the 
CKRM scheduler is included in the build then it can be 
selected/deselected in the usual ways.

PlugSched's version number has been bumped to 3.0 as its interface has 
been modified to increase the ability to share code between schedulers 
as well as integrate with CKRM.

A stand alone version of PlugSched-3.0 will be available in a few days.
Peter
--
Peter Williams   [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: out-of-line x86 "put_user()" implementation

[Andrew Morton]

Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> Andrew - do you want to put it in -mm? 

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

Re: [RFC] Linux Kernel Subversion Howto

[Jon Smirl]

On Wed, 9 Feb 2005 03:05:18 +0100 (CET), Roman Zippel
<[EMAIL PROTECTED]> wrote:
> The current problem is more serious and I want that bk users to understand
> that. A large part of kernel history is currently practically locked into
> bk. bk isn't doing what I need, so naturally I'm looking for alternatives,
> but I don't have the freedom to take my data and try it with some other
> tool. Was that really part of the deal when bk was introduced that I'm
> denied of this freedom?

Larry has said he will do the work you want if you pay him. This is
not lack of freedom it is lack of cash. So if you really believe in
this cough up the dough for Larry, and then only if he refuses to do
the work after being paid do you have valid reasons to complain.  This
is not an argument about freedom, it's trying to get someone else to
do work for you for free. Start a PayPal account and get all of the
unhappy people to contribute. I'll chip in $10 just so that I don't
have to read these rants anymore.

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

Re: [PATCH 2.4] Wireless Extension v17 (resend)

[Chris Wright]

* Jean Tourrilhes ([EMAIL PROTECTED]) wrote:
> On Tue, Feb 08, 2005 at 05:51:29PM -0800, Chris Wright wrote:
> > Hmm, having ability to read kernel data is not so nice.
> 
>   It's not like you can read any arbitrary address, exploiting
> such a flaw is in my mind theoritical. Let's not overblow things,
> there are some real bugs to take care of.

If the fix is simple (as it appears to be), there's no good reason to
leave the risk there.

> >  prism54 uses
> > this, and is a reasonably popular card.  Looks to me like this should be
> > plugged.  Is the patch below sufficient? (stolen from full 2.6 patch)
> 
>   Yep, except that you have an extra chunk that should not be
> in. You probably did not use the latest version of the patch (and that
> was not in the one sent to Marcelo). I would not like to introduce a
> real bug in 2.4.X :-(

Yes, you are correct, here it is without that errouneous bit.

thanks,
-chris

= net/core/wireless.c 1.4 vs edited =
--- 1.4/net/core/wireless.c 2003-09-03 04:12:57 -07:00
+++ edited/net/core/wireless.c  2005-02-08 17:45:15 -08:00
@@ -310,7 +310,7 @@ static inline int call_commit_handler(st
 
 /*  */
 /*
- * Number of private arguments
+ * Calculate size of private arguments
  */
 static inline int get_priv_size(__u16  args)
 {
@@ -320,6 +320,24 @@ static inline int get_priv_size(__u16  ar
return num * priv_type_size[type];
 }
 
+/*  */
+/*
+ * Re-calculate the size of private arguments
+ */
+static inline int adjust_priv_size(__u16   args,
+  union iwreq_data *   wrqu)
+{
+   int num = wrqu->data.length;
+   int max = args & IW_PRIV_SIZE_MASK;
+   int type = (args & IW_PRIV_TYPE_MASK) >> 12;
+
+   /* Make sure the driver doesn't goof up */
+   if (max < num)
+   num = max;
+
+   return num * priv_type_size[type];
+}
+
 
 / /proc/net/wireless SUPPORT /
 /*
@@ -701,7 +719,7 @@ static inline int ioctl_private_call(str
   ((extra_size + offset) <= IFNAMSIZ))
extra_size = 0;
} else {
-   /* Size of set arguments */
+   /* Size of get arguments */
extra_size = get_priv_size(descr->get_args);
 
/* Does it fits in iwr ? */
@@ -771,6 +789,14 @@ static inline int ioctl_private_call(str
 
/* If we have something to return to the user */
if (!ret && IW_IS_GET(cmd)) {
+
+   /* Adjust for the actual length if it's variable,
+* avoid leaking kernel bits outside. */
+   if (!(descr->get_args & IW_PRIV_SIZE_FIXED)) {
+   extra_size = adjust_priv_size(descr->get_args,
+ &(iwr->u));
+   }
+
err = copy_to_user(iwr->u.data.pointer, extra,
   extra_size);
if (err)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: out-of-line x86 "put_user()" implementation

[Linus Torvalds]

On Tue, 8 Feb 2005, Richard Henderson wrote:
>
> On Mon, Feb 07, 2005 at 05:20:06PM -0800, Linus Torvalds wrote:
> > +#define __put_user_8(x, ptr) __asm__ __volatile__("call __put_user_8":"=A" 
> > (__ret_pu):"0" ((typeof(*(ptr)))(x)), "c" (ptr))
> 
> This is not constrained enough.  The compiler could choose to put the
> return value in edx.  You want
> 
>   __asm__ __volatile__("call __put_user_8":"=a" (__ret_pu)
>   : "A" ((typeof(*(ptr)))(x)), "c" (ptr))

Hmm.. I always thought "A" was the _pairing_ of %eax/%edx, not "eax or
edx"?

IOW, as far as I know, I'm telling the compiler that the asm is writing a
64-bit value into %eax:%edx, and that that __ret_pu gets that 64-bit value 
assigned to it (and truncated, at that point). No?

Note that he code that actually writes to the register is the assembly 
code, and that one always writes to %eax. So the compiler doesn't get to 
"put the return value" anywhere. It gets told where it is.

I'd happily use your version, but I thought that some versions of gcc
require that input output registers cannot overlap, and would refuse to do 
that thing? But if you tell me differently..

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

Re: 2.6.11-rc3: Kylix application no longer works?

[Andrew Morton]

Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>
> On Tue, 8 Feb 2005 18:51:06 +0100
> Pavel Machek <[EMAIL PROTECTED]> wrote:
> 
> > Hi!
> > 
> > > I wonder if reverting the patch will restore the old behaviour?
> > 
> > This seems to be minimal fix to get Kylix application back to the
> > working state... Maybe it is good idea for 2.6.11?
> > 
> > Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
> > Pavel
> > 
> > --- clean/fs/binfmt_elf.c   2005-02-03 22:27:19.0 +0100
> > +++ linux/fs/binfmt_elf.c   2005-02-08 18:46:38.0 +0100
> > @@ -803,11 +803,8 @@
> > nbyte = ELF_MIN_ALIGN - nbyte;
> > if (nbyte > elf_brk - elf_bss)
> > nbyte = elf_brk - elf_bss;
> > -   if (clear_user((void __user *) elf_bss + 
> > load_bias, nbyte)) {
> > -   retval = -EFAULT;
> > -   send_sig(SIGKILL, current, 0);
> > -   goto out_free_dentry;
> > -   }
> > +   if (clear_user((void __user *) elf_bss + 
> > load_bias, nbyte))
> > +   printk(KERN_ERR "Error clearing BSS, 
> > wrong ELF executable? (Kylix?!)\n");
> 
> do once or rate limit rather than log spamming.

We could just remove the printk and stick a comment over it.  If the
application later tries to access the not-there pages then it'll just
fault.

However I worry if there is some way in which we can leave unzeroed memory
accessible to the application, although it's hard to see how that could
happen.

Daniel, Pavel cruelly chopped you off the Cc when replying.  What's your
diagnosis on the below?



Begin forwarded message:

Date: Tue, 8 Feb 2005 23:27:59 +0100
From: Pavel Machek <[EMAIL PROTECTED]>
To: Andrew Morton <[EMAIL PROTECTED]>, linux-kernel@vger.kernel.org
Subject: Re: 2.6.11-rc3: Kylix application no longer works?


Hi!

> > > I wonder if reverting the patch will restore the old behaviour?
> > 
> > This seems to be minimal fix to get Kylix application back to the
> > working state... Maybe it is good idea for 2.6.11?
> 
> Why does clearing the BSS fail?  Are the program headers bogus?
> (readelf -l).

No idea, probably yes. Here's readelf -l result:

Pavel

Elf file type is EXEC (Executable file)
Entry point 0x80614b4
There are 5 program headers, starting at offset 52

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR   0x34 0x08048034 0x08048034 0x000a0 0x000a0 R E 0x4
  INTERP 0xd4 0x080480d4 0x080480d4 0x00013 0x00013 R   0x1
  [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD   0x00 0x08048000 0x08048000 0xb7354 0x1b7354 R E 0x1000
  LOAD   0x0b7354 0x08200354 0x08200354 0x1e3e4 0x1f648 RW  0x1000
  DYNAMIC0x0d56a0 0x0821e6a0 0x0821e6a0 0x00098 0x00098 RW  0x4

 Section to Segment mapping:
  Segment Sections...
   00 
   01 .interp 
   02 .interp .dynsym .dynstr .hash .rel.plt .plt .text borland.ressym 
borland.resstr borland.reshash borland.resdata borland.resspare 
   03 .data .rodata .got .dynamic .bss 
   04 .dynamic 


-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: out-of-line x86 "put_user()" implementation

[Linus Torvalds]

On Tue, 8 Feb 2005, Richard Henderson wrote:
> 
> The first 3 gets lost.

Thanks. So here's v3 (which also removes the now stale __put_user_check() 
macro).

Andrew - do you want to put it in -mm? 

Linus

---
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/02/08 18:05:45-08:00 [EMAIL PROTECTED] 
#   x86: make "put_user()" be out-of-line
#   
#   It's really too big to be inlined.
#   
#   Ingo tests and reports: this shrinks his kernel text size by
#   about 12kB (roughly 0.5%)
# 
# arch/i386/lib/putuser.S
#   2005/02/08 18:05:32-08:00 [EMAIL PROTECTED] +87 -0
# 
# include/asm-i386/uaccess.h
#   2005/02/08 18:05:32-08:00 [EMAIL PROTECTED] +27 -13
#   x86: make "put_user()" be out-of-line
# 
# arch/i386/lib/putuser.S
#   2005/02/08 18:05:32-08:00 [EMAIL PROTECTED] +0 -0
#   BitKeeper file /home/torvalds/v2.6/linux/arch/i386/lib/putuser.S
# 
# arch/i386/lib/Makefile
#   2005/02/08 18:05:32-08:00 [EMAIL PROTECTED] +1 -1
#   x86: make "put_user()" be out-of-line
# 
# arch/i386/kernel/i386_ksyms.c
#   2005/02/08 18:05:32-08:00 [EMAIL PROTECTED] +5 -0
#   x86: make "put_user()" be out-of-line
# 
diff -Nru a/arch/i386/kernel/i386_ksyms.c b/arch/i386/kernel/i386_ksyms.c
--- a/arch/i386/kernel/i386_ksyms.c 2005-02-08 18:06:14 -08:00
+++ b/arch/i386/kernel/i386_ksyms.c 2005-02-08 18:06:14 -08:00
@@ -97,6 +97,11 @@
 EXPORT_SYMBOL(__get_user_2);
 EXPORT_SYMBOL(__get_user_4);
 
+EXPORT_SYMBOL(__put_user_1);
+EXPORT_SYMBOL(__put_user_2);
+EXPORT_SYMBOL(__put_user_4);
+EXPORT_SYMBOL(__put_user_8);
+
 EXPORT_SYMBOL(strpbrk);
 EXPORT_SYMBOL(strstr);
 
diff -Nru a/arch/i386/lib/Makefile b/arch/i386/lib/Makefile
--- a/arch/i386/lib/Makefile2005-02-08 18:06:14 -08:00
+++ b/arch/i386/lib/Makefile2005-02-08 18:06:14 -08:00
@@ -3,7 +3,7 @@
 #
 
 
-lib-y = checksum.o delay.o usercopy.o getuser.o memcpy.o strstr.o \
+lib-y = checksum.o delay.o usercopy.o getuser.o putuser.o memcpy.o strstr.o \
bitops.o
 
 lib-$(CONFIG_X86_USE_3DNOW) += mmx.o
diff -Nru a/arch/i386/lib/putuser.S b/arch/i386/lib/putuser.S
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/arch/i386/lib/putuser.S   2005-02-08 18:06:14 -08:00
@@ -0,0 +1,87 @@
+/*
+ * __put_user functions.
+ *
+ * (C) Copyright 2005 Linus Torvalds
+ *
+ * These functions have a non-standard call interface
+ * to make them more efficient, especially as they
+ * return an error value in addition to the "real"
+ * return value.
+ */
+#include 
+
+
+/*
+ * __put_user_X
+ *
+ * Inputs: %eax[:%edx] contains the data
+ * %ecx contains the address
+ *
+ * Outputs:%eax is error code (0 or -EFAULT)
+ *
+ * These functions should not modify any other registers,
+ * as they get called from within inline assembly.
+ */
+
+#define ENTER  pushl %ebx ; GET_THREAD_INFO(%ebx)
+#define EXIT   popl %ebx ; ret
+
+.text
+.align 4
+.globl __put_user_1
+__put_user_1:
+   ENTER
+   cmpl TI_addr_limit(%ebx),%ecx
+   jae bad_put_user
+1: movb %al,(%ecx)
+   xorl %eax,%eax
+   EXIT
+
+.align 4
+.globl __put_user_2
+__put_user_2:
+   ENTER
+   movl TI_addr_limit(%ebx),%ebx
+   subl $1,%ebx
+   cmpl %ebx,%ecx
+   jae bad_put_user
+2: movw %ax,(%ecx)
+   xorl %eax,%eax
+   EXIT
+
+.align 4
+.globl __put_user_4
+__put_user_4:
+   ENTER
+   movl TI_addr_limit(%ebx),%ebx
+   subl $3,%ebx
+   cmpl %ebx,%ecx
+   jae bad_put_user
+3: movl %eax,(%ecx)
+   xorl %eax,%eax
+   EXIT
+
+.align 4
+.globl __put_user_8
+__put_user_8:
+   ENTER
+   movl TI_addr_limit(%ebx),%ebx
+   subl $7,%ebx
+   cmpl %ebx,%ecx
+   jae bad_put_user
+4: movl %eax,(%ecx)
+5: movl %edx,4(%ecx)
+   xorl %eax,%eax
+   EXIT
+
+bad_put_user:
+   movl $-14,%eax
+   EXIT
+
+.section __ex_table,"a"
+   .long 1b,bad_put_user
+   .long 2b,bad_put_user
+   .long 3b,bad_put_user
+   .long 4b,bad_put_user
+   .long 5b,bad_put_user
+.previous
diff -Nru a/include/asm-i386/uaccess.h b/include/asm-i386/uaccess.h
--- a/include/asm-i386/uaccess.h2005-02-08 18:06:14 -08:00
+++ b/include/asm-i386/uaccess.h2005-02-08 18:06:14 -08:00
@@ -185,6 +185,21 @@
 
 extern void __put_user_bad(void);
 
+/*
+ * Strange magic calling convention: pointer in %ecx,
+ * value in %eax(:%edx), return value in %eax, no clobbers.
+ */
+extern void __put_user_1(void);
+extern void __put_user_2(void);
+extern void __put_user_4(void);
+extern void __put_user_8(void);
+
+#define __put_user_1(x, ptr) __asm__ __volatile__("call __put_user_1":"=a" 
(__ret_pu):"0" ((typeof(*(ptr)))(x)), "c" (ptr))
+#define __put_user_2(x, ptr) __asm__ __volatile__("call __put_user_2":"=a" 
(__ret_pu):"0" ((typeof(*(ptr)))(x)), "c" (ptr))
+#define __put_user_4(x, ptr) __asm__ __volatile__("call __put_user_4":"=a" 
(__ret_pu):"0" ((typeof(*(ptr)))(x)), "c" (ptr))
+#define __put_user_8(x, ptr) __asm__ __volatile__("call __put_user_8":"=A" 
(__ret_pu):"0" 

Re: [PATCH 2.4] Wireless Extension v17 (resend)

[Jean Tourrilhes]

On Tue, Feb 08, 2005 at 05:51:29PM -0800, Chris Wright wrote:
> * Jean Tourrilhes ([EMAIL PROTECTED]) wrote:
> > The first is the handling of spyoffset which is potentially
> > unsafe. Unfortunately, the fix involve some API/infrastructure change,
> > so is not transparent. Fortunately drivers are clever enough to not
> > trigger this bug.
> > The second is a potential leak of kernel data to user space in
> > private handler handling. Few drivers use that feature, there is no
> > risk of crash or direct attack, so I would not worry about it.
> 
> Hmm, having ability to read kernel data is not so nice.

It's not like you can read any arbitrary address, exploiting
such a flaw is in my mind theoritical. Let's not overblow things,
there are some real bugs to take care of.

>  prism54 uses
> this, and is a reasonably popular card.  Looks to me like this should be
> plugged.  Is the patch below sufficient? (stolen from full 2.6 patch)

Yep, except that you have an extra chunk that should not be
in. You probably did not use the latest version of the patch (and that
was not in the one sent to Marcelo). I would not like to introduce a
real bug in 2.4.X :-(

> thanks,
> -chris

This chunk is erroneous :

> @@ -731,7 +749,7 @@ static inline int ioctl_private_call(str
>   return -EFAULT;
>  
>   /* Does it fits within bounds ? */
> - if(iwr->u.data.length > (descr->set_args &
> + if(iwr->u.data.length > (descr->get_args &
>IW_PRIV_SIZE_MASK))
>   return -E2BIG;
>   } else {

Have fun...

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

Re: [RFC] Linux Kernel Subversion Howto

[Roman Zippel]

Hi,

On Tue, 8 Feb 2005, Theodore Ts'o wrote:

>   I don't know how many years it was before people decided to
> give up on the emacs vs. vi wars, but can we please put a more hasty
> end to the bk license flamewars?  Many thanks,

It's not really the same, if it would be just about personal preferences, 
I would be the first to shut up (unless someone buys the beer :) ).
If people want to use bk because it does the job for them, I'm happy 
for them.
The current problem is more serious and I want that bk users to understand 
that. A large part of kernel history is currently practically locked into 
bk. bk isn't doing what I need, so naturally I'm looking for alternatives, 
but I don't have the freedom to take my data and try it with some other 
tool. Was that really part of the deal when bk was introduced that I'm 
denied of this freedom?
If bk users think this alright, I'd really like to hear from them how this 
fits into a free software project. With every other free software project 
it's possible to just take the data and import into something else, why 
isn't this possible with Linux?

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 2.4] Wireless Extension v17 (resend)

[Marcelo Tosatti]

On Tue, Feb 08, 2005 at 08:09:04PM -0500, kernel wrote:
> On Tue, 2005-02-08 at 13:41, Marcelo Tosatti wrote:
> > >   There need to be some unique features in 2.6.X to force people
> > > to upgrade, I guess...
> > 
> > Faster, cleaner, way more elegant, handles intense loads more gracefully, 
> > handles highmem decently, LSM/SELinux, etc, etc...
> > 
> 
> Please *think* before saying this.  It's not always the case.  Firewire
> support in 2.6 kernel has been less than stellar, for one example.  And
> yes, for many, solid 1394 support is a requirement for business.

Well, if it has problems, like every piece of software is expected to have, 
then it should be fixed. 

We all should invest our efforts in having v2.6 the most stable kernel as 
possible.

I'm sure Ben Collins (1394 maintainer) will appreciate 1394 bug reports and 
he will do his best at fixing them.

> (And we've all seen the testing that has shown both sides (2.4, 2.6)
> have been faster) 
>
> > IMO everyone should upgrade whenever appropriate. 
> > 
> 
> Not sureon 13 January 2005 Alan Cox posted "Given that base 2.6
> kernels are shipped by Linus with known unfixed
> security holes anyone trying to use them really should be doing some
> careful thinking. In truth no 2.6 released kernel is suitable for
> anything but beta testing until you add a few patches anyway."

Alan means that _mainline_ v2.6 kernel might not be as polished as distribution 
kernels.

He does not mean, at all, that individuals should not upgrade to v2.6 based 
kernels.

Note his "until you add a few patches anyway".

> How do you answer this, when telling folks "everyone should upgrade
> whenever appropriate."?

Please realize that pretty much all development efforts have been
centered at the v2.6 kernel, and that means a lot.

> Just some random thoughtsfrom a 2.4 supporter :)

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

[gl34]

Quoting Burton Windle <[EMAIL PROTECTED]>:

> Make sure your CPU type is set correctly.
> CONFIG_MK6=y

It is.

Here's the latest config filtered through grep ^C

CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HOTPLUG=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_SHMEM=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
CONFIG_X86_PC=y
CONFIG_MK6=y
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
CONFIG_PREEMPT=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=m
CONFIG_TOSHIBA=m
CONFIG_I8K=m
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_EDD=m
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PM=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=""
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_THERMAL=m
CONFIG_ACPI_TOSHIBA=m
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_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=y
CONFIG_PCMCIA=m
CONFIG_PCMCIA_DEBUG=y
CONFIG_YENTA=m
CONFIG_CARDBUS=y
CONFIG_PD6729=m
CONFIG_I82092=m
CONFIG_I82365=m
CONFIG_TCIC=m
CONFIG_PCMCIA_PROBE=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=4096
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_TASKFILE_IO=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_CMD640_ENHANCED=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_OPTI621=m
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
CONFIG_BLK_DEV_AMD74XX=y
CONFIG_BLK_DEV_ATIIXP=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_CY82C693=y
CONFIG_BLK_DEV_HPT34X=y
CONFIG_BLK_DEV_HPT366=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_NS87415=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
CONFIG_BLK_DEV_TRM290=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDE_CHIPSETS=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_SCSI_DPT_I2O=m
CONFIG_SCSI_SATA=y
CONFIG_SCSI_ATA_PIIX=y
CONFIG_SCSI_SATA_SX4=m
CONFIG_SCSI_SATA_SIS=m
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
CONFIG_IP_MULTICAST=y
CONFIG_NETFILTER=y
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_TARGET_NOTRACK=m
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_PCI=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
CONFIG_S2IO=m
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_ASYNC=m

[2.6 patch] kill drivers/scsi/hosts.h

[Adrian Bunk]

Since more than half a year ago, drivers/scsi/hosts.h gives a warning, 
so it seems to be time to remove it.


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

--- linux-2.6.11-rc3-mm1-full/drivers/scsi/hosts.h  2004-12-24 
22:34:30.0 +0100
+++ /dev/null   2004-11-25 03:16:25.0 +0100
@@ -1,2 +0,0 @@
-#warning "This file is obsolete, please use  instead"
-#include 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.4] Wireless Extension v17 (resend)

[Chris Wright]

* Jean Tourrilhes ([EMAIL PROTECTED]) wrote:
>   The first is the handling of spyoffset which is potentially
> unsafe. Unfortunately, the fix involve some API/infrastructure change,
> so is not transparent. Fortunately drivers are clever enough to not
> trigger this bug.
>   The second is a potential leak of kernel data to user space in
> private handler handling. Few drivers use that feature, there is no
> risk of crash or direct attack, so I would not worry about it.

Hmm, having ability to read kernel data is not so nice.  prism54 uses
this, and is a reasonably popular card.  Looks to me like this should be
plugged.  Is the patch below sufficient? (stolen from full 2.6 patch)

thanks,
-chris

= net/core/wireless.c 1.4 vs edited =
--- 1.4/net/core/wireless.c 2003-09-03 04:12:57 -07:00
+++ edited/net/core/wireless.c  2005-02-08 17:45:15 -08:00
@@ -310,7 +310,7 @@ static inline int call_commit_handler(st
 
 /*  */
 /*
- * Number of private arguments
+ * Calculate size of private arguments
  */
 static inline int get_priv_size(__u16  args)
 {
@@ -320,6 +320,24 @@ static inline int get_priv_size(__u16  ar
return num * priv_type_size[type];
 }
 
+/*  */
+/*
+ * Re-calculate the size of private arguments
+ */
+static inline int adjust_priv_size(__u16   args,
+  union iwreq_data *   wrqu)
+{
+   int num = wrqu->data.length;
+   int max = args & IW_PRIV_SIZE_MASK;
+   int type = (args & IW_PRIV_TYPE_MASK) >> 12;
+
+   /* Make sure the driver doesn't goof up */
+   if (max < num)
+   num = max;
+
+   return num * priv_type_size[type];
+}
+
 
 / /proc/net/wireless SUPPORT /
 /*
@@ -701,7 +719,7 @@ static inline int ioctl_private_call(str
   ((extra_size + offset) <= IFNAMSIZ))
extra_size = 0;
} else {
-   /* Size of set arguments */
+   /* Size of get arguments */
extra_size = get_priv_size(descr->get_args);
 
/* Does it fits in iwr ? */
@@ -731,7 +749,7 @@ static inline int ioctl_private_call(str
return -EFAULT;
 
/* Does it fits within bounds ? */
-   if(iwr->u.data.length > (descr->set_args &
+   if(iwr->u.data.length > (descr->get_args &
 IW_PRIV_SIZE_MASK))
return -E2BIG;
} else {
@@ -771,6 +789,14 @@ static inline int ioctl_private_call(str
 
/* If we have something to return to the user */
if (!ret && IW_IS_GET(cmd)) {
+
+   /* Adjust for the actual length if it's variable,
+* avoid leaking kernel bits outside. */
+   if (!(descr->get_args & IW_PRIV_SIZE_FIXED)) {
+   extra_size = adjust_priv_size(descr->get_args,
+ &(iwr->u));
+   }
+
err = copy_to_user(iwr->u.data.pointer, extra,
   extra_size);
if (err)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] drivers/isdn/hardware/eicon/: misc possible cleanups

[Adrian Bunk]

On Sun, Feb 06, 2005 at 11:18:18AM +0100, Armin Schindler wrote:

> Hi Adrian,

Hi Armin,

> thanks for the proposed patch.
> Making the functions static is a good idea, I will check and test this.
> Removing some functions, especially from io.* and di.* is not good. These 
> functions are mainly used with other sub-drivers which are not part of the
> kernel. I will check if they are some really outdated and the removals in 
> message.c.

silly question:
Why are these sub-drivers not included in the kernel?

> Armin

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.10-ac12 + kernbench == oom-killer: (OSDL)

[Andries Brouwer]

On Tue, Feb 08, 2005 at 02:57:07PM -0800, cliff white wrote:

> Running 2.6.10-ac10 on the STP 1-CPU machines, we don't seem to be able to 
> complete
> a kernbench run without hitting the OOM-killer. ( kernbench is multiple 
> kernel compiles,
> of course ) Machine is 800 mhz PIII with 1GB memory. We reduce memory for 
> some of the runs.
> 
> Typical results:
> 
> Out of Memory: Killed process 14970 (cc1).
> -
> It looks like some oom-related stuff went into -ac10, will try retest with 
> -ac9 and -ac10, see what happens. Lemme know if we can do more

I am always curious to hear how things are when you set
/proc/sys/vm/overcommit_memory to 2
(and possibly /proc/sys/vm/overcommit_ratio to something
appropriate).

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11-rc3: oops in pdflush

[Gerd v. Egidy]

Hi,

rc3 vanilla oopses within 2 or 3 hours of heavy io load (rdiff-backup of ide 
disk 
(reiserfs3) to usb-storage (reiserfs3 on dm-crypt) and listening to internet 
radio in 
parallel). This is 100% reproducable here.

Usually there occur 4 or 5 of very similar looking oopses within 3 hours until 
the 
machine is not usable anymore (all commands stuck, sysrq-sync not completing) 
and I have to reboot.

To me the error message looks like a lock imbalance but I'm not a kernel 
hacker...

Does anybody have an idea whats going on here?

Please CC me as I'm not subscribed. Thank you.

Kind regards,

Gerd

Feb  8 16:00:38 fire kernel: Unable to handle kernel paging request at virtual 
address 0002ba10
Feb  8 16:00:38 fire kernel:  printing eip:
Feb  8 16:00:38 fire kernel: c01a8377
Feb  8 16:00:38 fire kernel: *pde = 
Feb  8 16:00:38 fire kernel: Oops:  [#4]
Feb  8 16:00:38 fire kernel: Modules linked in: aes_i586 dm_crypt sd_mod 
usb_storage scsi_mod nfsd exportfs lockd sunrpc md5
 ipv6 autofs4 dm_mod video button battery ac uhci_hcd ehci_hcd parport_pc 
parport i2c_viapro i2c_core snd_via82xx snd_ac97_codec
 snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc gameport 
snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore
 8139too mii reiserfs
Feb  8 16:00:38 fire kernel: CPU:0
Feb  8 16:00:38 fire kernel: EIP:0060:[]Not tainted VLI
Feb  8 16:00:38 fire kernel: EFLAGS: 00010282   (2.6.11-rc3) 
Feb  8 16:00:38 fire kernel: EIP is at sync_sb_inodes+0x3b7/0x3e0
Feb  8 16:00:38 fire kernel: eax: d746df48   ebx: c8534570   ecx: d8ac8a40   
edx: cbc46fdc
Feb  8 16:00:38 fire kernel: esi: c8534568   edi: cbc46f30   ebp: d680db3c   
esp: d746dec0
Feb  8 16:00:38 fire kernel: ds: 007b   es: 007b   ss: 0068
Feb  8 16:00:38 fire kernel: Process pdflush (pid: 141, threadinfo=d746c000 
task=d74346f0)
Feb  8 16:00:38 fire kernel: Stack: c047007b d7d1105c 0063 c03eed60 
d746defc c0152200 c02955bf cbc46fe4 
Feb  8 16:00:38 fire kernel:0246 c013c580 0011903f d746df48 
cbc46f30 d746df48 d746df38 c0152200 
Feb  8 16:00:38 fire kernel:c01a8536 c013c580 c0150910 d746df38 
c015093d d746df34 f0da d746df48 
Feb  8 16:00:38 fire kernel: Call Trace:
Feb  8 16:00:38 fire kernel:  [] pdflush+0x0/0x20
Feb  8 16:00:38 fire kernel:  [] blk_congestion_wait+0x7f/0x90
Feb  8 16:00:38 fire kernel:  [] autoremove_wake_function+0x0/0x50
Feb  8 16:00:38 fire kernel:  [] pdflush+0x0/0x20
Feb  8 16:00:38 fire kernel:  [] writeback_inodes+0x196/0x470
Feb  8 16:00:38 fire kernel:  [] autoremove_wake_function+0x0/0x50
Feb  8 16:00:38 fire kernel:  [] get_writeback_state+0x30/0x40
Feb  8 16:00:38 fire kernel:  [] get_dirty_limits+0x1d/0xe0
Feb  8 16:00:38 fire kernel:  [] background_writeout+0x76/0xb0
Feb  8 16:00:38 fire kernel:  [] __pdflush+0x219/0x5f0
Feb  8 16:00:38 fire kernel:  [] pdflush+0x1a/0x20
Feb  8 16:00:38 fire kernel:  [] background_writeout+0x0/0xb0
Feb  8 16:00:38 fire kernel:  [] pdflush+0x0/0x20
Feb  8 16:00:38 fire kernel:  [] kthread+0x94/0xa0
Feb  8 16:00:38 fire kernel:  [] kthread+0x0/0xa0
Feb  8 16:00:38 fire kernel:  [] kernel_thread_helper+0x5/0x18
Feb  8 16:00:38 fire kernel: Code: 97 ac 00 00 00 e9 1c fe ff ff 0f 0b 6b 01 8a 
4d 39 c0 e9 e4 fd ff ff 89 e8 e8 66 10 00 00 85 c0 0f 85 c8 fd ff ff e9 0a fd 
ff ff <8b> 05 10 ba 02 00 00 00 ff d1 e9 25 fd ff ff 8b 9f b4 00 00 00 
Feb  8 16:00:38 fire kernel:  fs/inode.c:785: spin_lock(fs/inode.c:c03d8350) 
already locked by fs/fs-writeback.c/430


Feb  8 16:54:52 fire kernel: Unable to handle kernel paging request at virtual 
address 0002ba10
Feb  8 16:54:52 fire kernel:  printing eip:
Feb  8 16:54:52 fire kernel: c01a8377
Feb  8 16:54:52 fire kernel: *pde = 
Feb  8 16:54:52 fire kernel: Oops:  [#5]
Feb  8 16:54:52 fire kernel: Modules linked in: aes_i586 dm_crypt sd_mod 
usb_storage scsi_mod nfsd exportfs lockd sunrpc md5 
ipv6 autofs4 dm_mod video button battery ac uhci_hcd ehci_hcd parport_pc 
parport i2c_viapro i2c_core snd_via82xx snd_ac97_codec
 snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc gameport 
snd_mpu401_uart snd_rawmidi snd_seq_device snd 
soundcore 8139too mii reiserfs
Feb  8 16:54:52 fire kernel: CPU:0
Feb  8 16:54:52 fire kernel: EIP:0060:[]Not tainted VLI
Feb  8 16:54:52 fire kernel: EFLAGS: 00010282   (2.6.11-rc3) 
Feb  8 16:54:52 fire kernel: EIP is at sync_sb_inodes+0x3b7/0x3e0
Feb  8 16:54:52 fire kernel: eax: ce69bf38   ebx: c8e640f8   ecx: d8ac8a40   
edx: ce69bf38
Feb  8 16:54:52 fire kernel: esi: c8e640f0   edi: cbc46f30   ebp: d680db3c   
esp: ce69bec8
Feb  8 16:54:52 fire kernel: ds: 007b   es: 007b   ss: 0068
Feb  8 16:54:52 fire kernel: Process pdflush (pid: 3136, threadinfo=ce69a000 
task=d74346f0)
Feb  8 16:54:52 fire kernel: Stack: cbc46f30 d8878140 cbc46f30  
  cbc46f30 cbc46fe4 
Feb  8 16:54:52 fire kernel:ce69a000  004339b2 ce69bf38 
cbc46f30 ce69bf38 1bf5 c0152200 
Feb  8 16:54:52 fire kernel:

Re: 2.6.11-rc3-bk5: XFS: fcron: could not write() buf to disk: Resource temporarily unavailable

[Nathan Scott]

On Tue, Feb 08, 2005 at 08:51:36PM +0300, Alexander Y. Fomichev wrote:
> G' day
> 
> It looks like XFS broken somewhere in 2.6.11-rc1,
> sadly i can't sand "right" bugreport, some facts only.
> Upgrade to 2.6.11-rc2 makes fcron non-working for me in case of 
> crontabs directory is placed on XFS partition.
> When i try to install new crontab fcrontab die with error: 
> "could not write() buf to disk: Resource temporarily unavailable"

Is that an O_SYNC write, do you know?  Or a write to an inode
with the sync flag set?

> The same time it works with 2.6.10.

I'm chasing down a problem similar to this atm, so far looks like
something in the generic VM code below sync_page_range is giving
back EAGAIN, and that is getting passed back out to userspace by
XFS.  Not sure where/why/how its been caused yet though ... I'll
let you know once I have a fix or have found the culprit change.

cheers.

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

Re: out-of-line x86 "put_user()" implementation

[Richard Henderson]

On Mon, Feb 07, 2005 at 05:20:06PM -0800, Linus Torvalds wrote:
> +#define __put_user_8(x, ptr) __asm__ __volatile__("call __put_user_8":"=A" 
> (__ret_pu):"0" ((typeof(*(ptr)))(x)), "c" (ptr))

This is not constrained enough.  The compiler could choose to put the
return value in edx.  You want

  __asm__ __volatile__("call __put_user_8":"=a" (__ret_pu)
: "A" ((typeof(*(ptr)))(x)), "c" (ptr))


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

Re: out-of-line x86 "put_user()" implementation

[Richard Henderson]

On Mon, Feb 07, 2005 at 05:20:06PM -0800, Linus Torvalds wrote:
> +3:   movl %eax,(%ecx)
...
> +3:   movl %eax,(%ecx)
> +4:   movl %edx,4(%ecx)
...
> + .long 3b,bad_put_user
> + .long 4b,bad_put_user

The first 3 gets lost.


r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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][I2C] Marvell mv64xxx i2c driver

[Bartlomiej Zolnierkiewicz]

On Tue, 08 Feb 2005 17:32:11 -0700, Mark A. Greer <[EMAIL PROTECTED]> wrote:
> Bartlomiej Zolnierkiewicz wrote:
> 
> >Hi,
> >
> >just a minor thing
> >
> >
> >
> >>+static int __devinit
> >>+mv64xxx_i2c_init(void)
> >>+{
> >>+   return driver_register(_i2c_driver);
> >>+}
> >>
> >>
> >
> >__init
> >
> >
> >
> >>+static void __devexit
> >>+mv64xxx_i2c_exit(void)
> >>+{
> >>+   driver_unregister(_i2c_driver);
> >>+   return;
> >>+}
> >>
> >>
> >
> >__exit
> >
> >these functions relate to module not device
> >
> 
> Gahhh.  Thanks Bartlomiej.
> 
> Below is yet another replacement patch

Thanks, I see that you did global replacement of __devinit
by __init and __devexit by __exit - it seems correct *only* if:
- there can be only one i2c controller in the system
- there can be only one host bridge in the system
- i2c core calls ->probe only once during driver init
  and ->remove only once during driver exit

If all conditions are really true some comment about
this in the code would still be be nice.

While at it more silly, minor nitpicking ;)

> +static void
> +mv64xxx_i2c_wait_for_completion(struct mv64xxx_i2c_data *drv_data)
> +{
> +   longflags, time_left;

'flags' are of 'unsigned long' not 'long' type

> +   charabort = 0;
> +
> +   time_left = wait_event_interruptible_timeout(drv_data->waitq,
> +   !drv_data->block, 
> msecs_to_jiffies(drv_data->adapter.timeout));
> +
> +   spin_lock_irqsave(_data->lock, flags);
> +   if (!time_left) { /* Timed out */
> +   drv_data->rc = -ETIMEDOUT;
> +   abort = 1;
> +   } else if (time_left < 0) { /* Interrupted/Error */
> +   drv_data->rc = time_left; /* errno value */
> +   abort = 1;
> +   }
> +
> +   if (abort && drv_data->block) {
> +   drv_data->state = MV64XXX_I2C_STATE_ABORTING;
> +   spin_unlock_irqrestore(_data->lock, flags);
> +
> +   time_left = wait_event_timeout(drv_data->waitq,
> +   !drv_data->block,
> +   msecs_to_jiffies(drv_data->adapter.timeout));
> +
> +   if (time_left <= 0) {
> +   drv_data->state = MV64XXX_I2C_STATE_IDLE;
> +   dev_err(_data->adapter.dev,
> +   "mv64xxx: I2C bus locked\n");
> +   }
> +   } else
> +   spin_unlock_irqrestore(_data->lock, flags);
> +
> +   return;

there is no need for explicit return in void functions

[ These two comments also apply to other code in the driver. ]

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

Re: [PATCH 2.4] Wireless Extension v17 (resend)

[kernel]

Message below meant for Marcelo!

(sorry rest!)


On Tue, 2005-02-08 at 20:09, kernel wrote:
> On Tue, 2005-02-08 at 13:41, Marcelo Tosatti wrote:
> > >   There need to be some unique features in 2.6.X to force people
> > > to upgrade, I guess...
> > 
> > Faster, cleaner, way more elegant, handles intense loads more gracefully, 
> > handles highmem decently, LSM/SELinux, etc, etc...
> > 
> 
> Please *think* before saying this.  It's not always the case.  Firewire
> support in 2.6 kernel has been less than stellar, for one example.  And
> yes, for many, solid 1394 support is a requirement for business.
> 
> (And we've all seen the testing that has shown both sides (2.4, 2.6)
> have been faster)
> 
> > IMO everyone should upgrade whenever appropriate. 
> > 
> 
> Not sureon 13 January 2005 Alan Cox posted "Given that base 2.6
> kernels are shipped by Linus with known unfixed
> security holes anyone trying to use them really should be doing some
> careful thinking. In truth no 2.6 released kernel is suitable for
> anything but beta testing until you add a few patches anyway."
> 
> How do you answer this, when telling folks "everyone should upgrade
> whenever appropriate."?
> 
> 
> Just some random thoughtsfrom a 2.4 supporter :)
> 
> -fd
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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

Re: [PATCH 2.4] Wireless Extension v17 (resend)

[kernel]

On Tue, 2005-02-08 at 13:41, Marcelo Tosatti wrote:
> > There need to be some unique features in 2.6.X to force people
> > to upgrade, I guess...
> 
> Faster, cleaner, way more elegant, handles intense loads more gracefully, 
> handles highmem decently, LSM/SELinux, etc, etc...
> 

Please *think* before saying this.  It's not always the case.  Firewire
support in 2.6 kernel has been less than stellar, for one example.  And
yes, for many, solid 1394 support is a requirement for business.

(And we've all seen the testing that has shown both sides (2.4, 2.6)
have been faster)

> IMO everyone should upgrade whenever appropriate. 
> 

Not sureon 13 January 2005 Alan Cox posted "Given that base 2.6
kernels are shipped by Linus with known unfixed
security holes anyone trying to use them really should be doing some
careful thinking. In truth no 2.6 released kernel is suitable for
anything but beta testing until you add a few patches anyway."

How do you answer this, when telling folks "everyone should upgrade
whenever appropriate."?


Just some random thoughtsfrom a 2.4 supporter :)

-fd

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

Re: [2.6 patch] kill xfrm_export.c

[David S. Miller]

On Wed, 19 Jan 2005 10:17:15 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:

> This patch removes xfrm_export.c and moves the EXPORT_SYMBOL{,_GPL}'s to 
> the files where the actual functions are.
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

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

bttv : overlay mode and big disk io hang and could corrupt the fs

[matthieu castet]

Hi,
if I run "xawtv" [1] and then do a "grep -r toto /usr", my system 
quickly freeze. If there isn't any xawv running nothing happen. I don't 
try to use xawtv with grab mode (port 54) because I don't want to loose 
data by crashing again my / fs.

I retry it and I arrived to get some log (see the attach file).
But after rebooting, I had a big surprise, the / ext3 fs was corrupted 
and I need to run fsck by hand 

Matthieu

[1]
$xawtv -hwscan
This is xawtv-3.94, running on Linux/i686 (2.6.10)
looking for available devices
port 53-53  [ -xvport 53 ]
type : Xvideo, video overlay
name : video4linux
port 54-54
type : Xvideo, image scaler
name : NV Video Overlay
port 55-86
type : Xvideo, image scaler
name : NV Video Blitter
/dev/video0: OK [ -device /dev/video0 ]
type : v4l2
name : BT878 video (Pinnacle PCTV Stud
flags: overlay capture tuner
$cat /proc/interrupts
   CPU0
  0: 654027IO-APIC-edge  timer
  1:   2679IO-APIC-edge  i8042
  7:  0IO-APIC-edge  parport0
  9:  0   IO-APIC-level  acpi
 12:  23644IO-APIC-edge  i8042
 14:  88469IO-APIC-edge  ide0
 15:  2IO-APIC-edge  ide1
 17:  5   IO-APIC-level  eth0, bttv0, Bt87x audio
 18: 48   IO-APIC-level  ide2, ide3
 19:  0   IO-APIC-level  EMU10K1
 21:  97526   IO-APIC-level  ehci_hcd, uhci_hcd, uhci_hcd, uhci_hcd
 22:  0   IO-APIC-level  VIA8233
NMI:  0
LOC: 661965
ERR:  0
MIS:  0
Feb  9 01:20:32 localhost kernel: ehci_hcd :00:10.3: fatal error
Feb  9 01:20:32 localhost kernel: ehci_hcd :00:10.3: HC died; cleaning up
Feb  9 01:20:32 localhost kernel: bttv0: OCERR @ 3635001c,bits: HSYNC OFLOW 
RISCI* OCERR*
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: init_special_inode: bogus i_mode (0)
Feb  9 01:20:32 localhost last message repeated 11 times
Feb  9 01:20:32 localhost kernel: init_special_inode: bogus i_mode (63)
Feb  9 01:20:32 localhost kernel: init_special_inode: bogus i_mode (0)
Feb  9 01:20:32 localhost kernel: bttv0: OCERR @ 3635001c,bits: HSYNC OFLOW 
RISCI* OCERR*
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb  9 01:20:32 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 

Re: VM disk cache behavior.

[Andy Isaacson]

On Tue, Feb 08, 2005 at 12:06:14PM -0500, jon ross wrote:
> I have an app with a small fixed memory footprint that does a lot of
> random reads from a large file. I thought if I added more memory to
> the machine the VM would do more caching of the disk, but added memory
> does not seem to make any difference. I played with some of the params
> in /proc/sys/vm and none of them seem to have any effect.
> 
> I tired both a 2.4.20 & 2.6.10 kernels with no difference.
> 
> The machine is a Dell 2560. I tired memory configs of 512M, 1G, 4G and
> the average read-times do not change.

Could we get some quant here?  How small is "small"?  How large is
"large"?  What are you measuring?  What are the results?  Does the app
re-use the same data, or is its use a one-time deal?

> Do I need to set/compile anything to allow the VM to use the memory?

No, the Linux VM system should automatically cache for you.

> If is was a way to tell how much memory the VM is using for a drive
> cache I could at least tell if my kernel is miss-configured or my app
> sucks.

Check out the commands "free", "vmstat 1", "top", the contents of
/proc/meminfo, the output of Sysrq-M.

Most likely is that your app isn't behaving in a cache-friendly way.  If
your file will fit in memory, just fault it in sequentially (wc -l file)
and then your app should cook.  If you're not going to fit in memory,
the vm caching will probably only help if you have some reuse; you could
develop a pre-faulter to get your IO started ahead of time, but that's
generally nontrivial.

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

Re: [PATCH 2.4] Wireless Extension v17 (resend)

[Jean Tourrilhes]

On Tue, Feb 08, 2005 at 04:41:46PM -0200, Marcelo Tosatti wrote:
> On Tue, Feb 08, 2005 at 01:51:12PM -0800, Jean Tourrilhes wrote:
> > 
> > You are right, it's not critical, and I was already thinking
> > of not pushing WE-18 to you (the WPA update). I'll stop updating 2.4.X
> > with respect to wireless, the patches will be available on my web page
> > for people who needs it. 
> 
> Please dont miss bugfixes for present functionality. Gracias.

Depend what you call "bugfix". Fortunately, with the long beta
period I do with the WE, bugs are few. There are only two "bugs" in
WE-16 I'm aware off (fixed in WE-17), but I don't think they are worth
fixing.
The first is the handling of spyoffset which is potentially
unsafe. Unfortunately, the fix involve some API/infrastructure change,
so is not transparent. Fortunately drivers are clever enough to not
trigger this bug.
The second is a potential leak of kernel data to user space in
private handler handling. Few drivers use that feature, there is no
risk of crash or direct attack, so I would not worry about it.

> Faster, cleaner, way more elegant, handles intense loads more gracefully, 
> handles highmem decently, LSM/SELinux, etc, etc...
> 
> IMO everyone should upgrade whenever appropriate. 

If people want to use 2.4.X, I won't prevent them...
Have fun...

Jean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

Bartlomiej Zolnierkiewicz wrote:
Hi,
just a minor thing
 

+static int __devinit
+mv64xxx_i2c_init(void)
+{
+   return driver_register(_i2c_driver);
+}
   

__init
 

+static void __devexit
+mv64xxx_i2c_exit(void)
+{
+   driver_unregister(_i2c_driver);
+   return;
+}
   

__exit
these functions relate to module not device
Gahhh.  Thanks Bartlomiej.
Below is yet another replacement patch
--
Marvell makes a line of host bridge for PPC and MIPS systems.  On those 
bridges is an i2c controller.  This patch adds the driver for that i2c 
controller.

Please apply.
Depends on patch submitted by Jean Delvare: 
http://archives.andrew.net.au/lm-sensors/msg29405.html

Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig2005-02-08 17:28:52 -07:00
+++ b/drivers/i2c/busses/Kconfig2005-02-08 17:28:52 -07:00
@@ -486,4 +486,14 @@
  This driver can also be built as a module.  If so, the module
  will be called i2c-pca-isa.
 
+config I2C_MV64XXX
+   tristate "Marvell mv64xxx I2C Controller"
+   depends on I2C && MV64X60 && EXPERIMENTAL
+   help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Marvell 64xxx line of host bridges.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-mv64xxx.
+
 endmenu
diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
--- a/drivers/i2c/busses/Makefile   2005-02-08 17:28:52 -07:00
+++ b/drivers/i2c/busses/Makefile   2005-02-08 17:28:52 -07:00
@@ -21,6 +21,7 @@
 obj-$(CONFIG_I2C_IXP4XX)   += i2c-ixp4xx.o
 obj-$(CONFIG_I2C_KEYWEST)  += i2c-keywest.o
 obj-$(CONFIG_I2C_MPC)  += i2c-mpc.o
+obj-$(CONFIG_I2C_MV64XXX)  += i2c-mv64xxx.o
 obj-$(CONFIG_I2C_NFORCE2)  += i2c-nforce2.o
 obj-$(CONFIG_I2C_PARPORT)  += i2c-parport.o
 obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/busses/i2c-mv64xxx.c  2005-02-08 17:28:52 -07:00
@@ -0,0 +1,606 @@
+/*
+ * drivers/i2c/busses/i2c-mv64xxx.c
+ * 
+ * Driver for the i2c controller on the Marvell line of host bridges for MIPS
+ * and PPC (e.g, gt642[46]0, mv643[46]0, mv644[46]0).
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista, Software, Inc.  This file is licensed under
+ * the terms of the GNU General Public License version 2.  This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register defines */
+#defineMV64XXX_I2C_REG_SLAVE_ADDR  0x00
+#defineMV64XXX_I2C_REG_DATA0x04
+#defineMV64XXX_I2C_REG_CONTROL 0x08
+#defineMV64XXX_I2C_REG_STATUS  0x0c
+#defineMV64XXX_I2C_REG_BAUD0x0c
+#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR  0x10
+#defineMV64XXX_I2C_REG_SOFT_RESET  0x1c
+
+#defineMV64XXX_I2C_REG_CONTROL_ACK 0x0004
+#defineMV64XXX_I2C_REG_CONTROL_IFLG0x0008
+#defineMV64XXX_I2C_REG_CONTROL_STOP0x0010
+#defineMV64XXX_I2C_REG_CONTROL_START   0x0020
+#defineMV64XXX_I2C_REG_CONTROL_TWSIEN  0x0040
+#defineMV64XXX_I2C_REG_CONTROL_INTEN   0x0080
+
+/* Ctlr status values */
+#defineMV64XXX_I2C_STATUS_BUS_ERR  0x00
+#defineMV64XXX_I2C_STATUS_MAST_START   0x08
+#defineMV64XXX_I2C_STATUS_MAST_REPEAT_START0x10
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_NO_ACK  0x20
+#defineMV64XXX_I2C_STATUS_MAST_WR_ACK  0x28
+#defineMV64XXX_I2C_STATUS_MAST_WR_NO_ACK   0x30
+#defineMV64XXX_I2C_STATUS_MAST_LOST_ARB0x38
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_ACK 0x40
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_NO_ACK  0x48
+#defineMV64XXX_I2C_STATUS_MAST_RD_DATA_ACK 0x50
+#defineMV64XXX_I2C_STATUS_MAST_RD_DATA_NO_ACK  0x58
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_2_ACK   0xd0
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_2_NO_ACK0xd8
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_ACK   0xe0
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_NO_ACK0xe8
+#defineMV64XXX_I2C_STATUS_NO_STATUS0xf8
+
+/* Driver states */
+enum {
+

Re: Question regarding e1000 driver and dropped packets (2.6.5 / 2.6.10)?

[Bukie Mabayoje]

Can you do a simple test?
Connect the two box to the same switch. ( No other box should be on the 
physical bus)
1. Send packets from BoxA  --->   BoxB  ( Record the stats)

2. Send packets from BoxB ---> BoxA(Record the stats)

3. Send packets simultaneously  from  BoxB->BoxA and BoxA  -> BoxB  
(Record the stats)

if you can find a third box

4. Send packets [BoxA and BoxC] ->   BoxB and BoxB -> BoxA (Record 
the stats)

5. Send packets [BoxB and BoxC] -> BoxA and BoxA --> BoxB (Record 
the stats)

I don't understand why you received more packet on BoxB. A controlled test will 
help clarify any ambiguity.
  [BoxA]   RX packets:196787934 errors:4 dropped:0 overruns:0 frame:2
TX packets:101356779 errors:0 dropped:0 overruns:0 carrier:0

 [BoxB]RX packets:446380046 errors:1276833 dropped:1276833 
overruns:1276833 frame:0
TX packets:572550636 errors:0 dropped:0 overruns:0 carrier:0


Justin Piszcz wrote:

> I have two identical machines [mobo/hardware wise]:
>
> Each machine is a Dell GX1p (500MHZ).
>
> I have two Intel Gigabit NICs, one in each box, hooked up to a GigE
> switch.
>
> Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller
> Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller
>
> I doubt its the kernel version; does anyone have any suggestions/ideas why
> one machine has virtually NO overruns/errors/drops and the other has tons?
>
> Also, (I doubt this to be the case but I'll ask anyway) - Is the way the
> NIC's are setup in the box next to other cards / alter their PCI/IRQ
> routing which would effect error/drop rates?
>
> IE:
>
> PCI1 - promise card / pata
> PCI2 - promise card / pata
> PCI3 - promise card / sata
> PCI4 - e1000 nic
> PCI5 - 4 port nic

What matters is which INT# [A,B,C,D] line and/or combination  the PCI slot 1, 
2, 3, 4 is using.
You can find out by running lspci -vv
If they are routed to the same system interrupt and  lastly, the interrupt 
priority issues.

>
>
> Would it make sense to order them in a different direction?

May not help in identifying the problem.

>
>
> Also, is there a correlation between errors on the NIC and ERR
> in /proc/interrupts?

Maybe..

>
>
> Secondly, could loading lm-sensors/temperature modules be causing these
> problems?

You don't have any overrun on this box.

>
>
> dmesg from box2 below:
>
> e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
> eth1: Setting full-duplex based on MII#1 link partner capability of 45e1.
> eth2: Setting full-duplex based on MII#1 link partner capability of 45e1.
> nfs warning: mount version older than kernel
> nfs warning: mount version older than kernel
> nfs warning: mount version older than kernel
> nfs warning: mount version older than kernel
> i2c /dev entries driver
> piix4_smbus :00:07.3: Found :00:07.3 device
> piix4_smbus :00:07.3: WARNING: SMBus interface has been FORCEFULLY
> ENABLED!
> mtrr: no MTRR for fd00,80 found
> spurious 8259A interrupt: IRQ7.
> spurious 8259A interrupt: IRQ15.
>
> I am currently out of ideas, if anyone can suggest anything, I'd be most
> greatful, thanks!
>
> On the first box, there are hardly any problems receiving packets:
>
> Note the errors & dropped on the receiving end:
>
> BOX1: (2.6.5)
>
> eth0  Link encap:Ethernet  HWaddr 00:0E:0C:00:CD:B1
>inet addr:10.0.2.254  Bcast:10.0.2.255  Mask:255.255.255.0
>inet6 addr: fe80::20e:cff:fe00:cdb1/64 Scope:Link
>UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>RX packets:196787934 errors:4 dropped:0 overruns:0 frame:2
>TX packets:101356779 errors:0 dropped:0 overruns:0 carrier:0
>collisions:0 txqueuelen:1000
>RX bytes:2602045376 (2481.5 Mb)  TX bytes:4051930608 (3864.2 Mb)
>Base address:0xcc80 Memory:ff02-ff04
>
> BOX1 MODULES:
>
> $ lsmod
> Module  Size  Used by
> ip_nat_ftp  4016  0
> ip_conntrack_ftp   71088  1 ip_nat_ftp
>
> BOX2: (2.6.10)
>
> On another box (same physical HW) I get this:
>
> eth0  Link encap:Ethernet  HWaddr 00:0E:0C:00:D2:06
>inet addr:10.0.2.253  Bcast:10.0.2.255  Mask:255.255.255.0
>UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> -->   RX packets:446380046 errors:1276833 dropped:1276833 
> overruns:1276833 frame:0
>TX packets:572550636 errors:0 dropped:0 overruns:0 carrier:0
>collisions:0 txqueuelen:1000
>RX bytes:2351750726 (2.1 GiB)  TX bytes:3659840330 (3.4 GiB)
>Base address:0xd8c0 Memory:f8fa-f8fc
>
> BOX2 MODULES:
>
> $ lsmod
> Module  Size  Used by
> ip_nat_irc  3408  0
> ip_conntrack_irc   70480  1 ip_nat_irc
> ip_nat_ftp  4112  0
> ip_conntrack_ftp   71344  1 ip_nat_ftp
> adm102111060  0
> i2c_piix4   6000  0
> 

Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement

[Paul Jackson]

Shailabh wrote:
> Well, I'm not sure I want to minutely examine Paul's choice of words !

You're a wise man ;).


> Rereading the earlier posts on the thread, I'd agree. There are some 
> similarities in our interfaces but not enough to warrant a merger.

As I said ... a wise man !

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement

[Paul Jackson]

Matthew wrote:
> I should have been more clear that CKRM and CPUSETs (seem) to 
> be unreconcilable.  Sched_domains and CPUSETs (seem) to have some potential 
> functionality overlap that leads me to (still) believe there is hope to 
> integrate these two systems.

Aha - now we're getting somewhere.

I was under the illusion these last four months that you were going to
serve as priest at the shotgun wedding that Andrew had requested be
arranged between cpusets and CKRM.  All this time, you were hoping to
get cpusets hooked up with sched domains.

My daughter 'cpusets' sure is popular ;).

If cpusets were somehow to be subsumed into CKRM, it would likely have
meant reincarnating cpusets in a new form, varying in some degree, large
or small, from its current form.  If that had been in our forseeable
future, then we would not have wanted to put cpusets in its current form
in the main tree.  It's alot easier to change API's that aren't API's
yet.

I remain certain that cpusets don't fit in CKRM.  Not even close.

The merger of cpusets and sched domains is an entirely different affair,
in my view.  It's an internal optimization, having next to zero impact
on any API's that the kernel presents to userland.  On most systems, it
would be of no particular benefit.  But on big honkin numa boxes making
heavy use of cpusets, it might make the schedulers work more efficient. 
Or might not.  I will leave that up to others to figure out, when and if
they choose to.  I'll be glad to help with such an effort, what little
I can, if it comes about.

If such an integration between cpusets and sched domains is in our
future, we should first get cpusets into the kernel, and then the
appropriate experts can refine the interaction of cpusets with sched
domains.  In this case, the sooner cpusets goes in, the better, so that
the integration effort with sched domains can commence, confident that
cpusets are here to stay.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem in accessing executable files

[Al Viro]

On Tue, Feb 08, 2005 at 07:14:27PM -0500, Vineet Joglekar wrote:
> 
> Hi all,
> 
> 
> 
> 1 more interesting observation regarding my executable file problem.
> 
> 
> 
> If I copy an executable say "prac" from ext2 fs to my encrypted fs as prac1, 
> prac1 doesnt run on the encrypted fs. but, if I make another copy, from prac1 
> to normal ext2 fs, as prac2, then the prac2 executes properly on normal file 
> system. that means my encryption, decryption functions are getting executed 
> properly while using that executable as normal file to read and write, but 
> something else is happening when I try to execute it. I am failing to 
> understand what am I missing.

1) 6 or 7 newlines
2) mmap()
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] New sys_chmod() hook for the LSM framework

[Chris Wright]

* Lorenzo Hernández García-Hierro ([EMAIL PROTECTED]) wrote:
> As commented yesterday, I was going to release a few more hooks for some
> *critical* syscalls, this one adds a hook to sys_chmod(), and makes us
> able to apply checks and logics before releasing the operation to
> sys_chmod().

This is exactly the kind of hook we've tried to avoid.  This is really
asking for permission to alter inode attribute data.  This type of
hook is incomplete because there are other ways to alter this data,
and this access is already controlled by the inode_setattr hook (as
Tony mentioned).  So this is a no go.

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem in accessing executable files

[Vineet Joglekar]

Hi all,



1 more interesting observation regarding my executable file problem.



If I copy an executable say "prac" from ext2 fs to my encrypted fs as prac1, 
prac1 doesnt run on the encrypted fs. but, if I make another copy, from prac1 
to normal ext2 fs, as prac2, then the prac2 executes properly on normal file 
system. that means my encryption, decryption functions are getting executed 
properly while using that executable as normal file to read and write, but 
something else is happening when I try to execute it. I am failing to 
understand what am I missing.



Vineet



 --- On Sun 02/06, Vineet Joglekar < [EMAIL PROTECTED] > wrote:

From: Vineet Joglekar [mailto: [EMAIL PROTECTED]

To: [EMAIL PROTECTED], linux-kernel@vger.kernel.org

 Cc: linux-c-programming@vger.kernel.org

Date: Sun,  6 Feb 2005 17:41:01 -0500 (EST)

Subject: Re: Problem in accessing executable files



Hi John,Thanks for suggesting the single / few bytes encryption 
test. I tried doing that, but in vain. Maybe I am going wrong somewhere 
else.I will briefly tell the functions I have written and the sequence 
if I am doing any mistake in the logic, please let me know.In file.c I have 
added the info about the functions my_generic_file_read and 
my_generic_file_write in ext2_file_operations.For decrypting, the 
sequence is:my_generic_file_read ---> my_do_generic_file_read ---> 
my_file_read_actor ---> my_decrypt_dataI have not made any changes in 
my_generic_file_read  and my_do_generic_file_read. In the function 
my_file_read_actor, I copy the page to my buffer (1 page - allocated at the 
time of mounting) I decrypt that buffer and pass it to the __copy_to_user() 
function.for encrypting, the sequence is:my_generic_file_write ---> 
my_encrypt_dataIn function my_generic_file_write, between functions 
__copy_from_user() and commit_write(), I am calling my_encrypt_data() by 
passing address of the page that is passed to __copy_from_user()My 
encrypt / decrypt routine is very basic at this time - just xoring every byte 
of the page as:*to = *to ^ 0xff; *to++;If I change my 
encrypt/decrypt routines to encrypt / decrypt just first or last byte of the 
page, then I get a different error saying the file is not executable - when I 
try to execute it. I thought there might be a problem with executable header, 
but I guess when I encrypt last byte of the page, header should have been 
bypassed.Is it something like, for executables, the data is refered in 
some other functions - that is, before do_generic_file_read geting 
called?Thanks and regards,Vineet --- On Tue 02/01, John 
T. Williams < [EMAIL PROTECTED] > wrote:From: John T. Williams [mailto: 
[EMAIL PROTECTED]To: [EMAIL PROTECTED], linux-kernel@vger.kernel.org
 Cc: linux-c-programming@vger.kernel.orgDate: Tue, 1 Feb 2005 10:37:30 
-0500Subject: Re: Problem in accessing executable filesThis is just 
a thought.Text files are better able to handle small faults. ie an 
extra space orcharacters or even an unreadable piece of data might not 
cause the file tobecome unreadable by most text editors.  Binary files 
aren't as flexible.Every bit could be an instruction to the processor and 
might cause a segfault.Just to test the theory, I would start by 
making the encrypt decryptfunction only effect the first byte.  If doing 
this doesn't cause a segfault, I would recheck my decrypt encrypt algorithm 
to make sure it doesn'tpad or expand at any point. maybe use them on a 
regular file and the anmd5sum on the file before and after, just to make 
extra sure.- Original Message - From: "Vineet Joglekar" 
<[EMAIL PROTECTED]>To: Cc: 
Sent: Tuesday, February 01, 2005 8:58 
AMSubject: Problem in accessing executable files>> Hi 
all,>> I am trying to add some cryptographic functionality to ext2 file 
systemfor my masters project. I am working with kernel 2.4.21>> 
since the routines do_generic_file_read and do_generic_file_write are 
usedin reading and writing, I am decrypting and encrypting the data in the 
resp.functions. This is working fine for regular data files. If I try to 
copy /execute executable files, I am getting segmentation fault. In 
kernelmessages, I see same functions (read and write) getting called for 
theexecutables also. If I comment encrypt/decrypt functions, its working 
fine.>> Now since it is working for regular text files, I suppose there 
is not aproblem in my encrypt/decrypt routines, then what might be going 
wrong?>> Thanks and regards,>> Vineet>> 
___> Join Excite! - 
http://www.excite.com> The most personalized portal on the Web!> -> 
To unsubscribe from this list:
  send the line "unsubscribelinux-c-programming" in> the body of a 
message to [EMAIL PROTECTED]> More majordomo info at  
http://vger.kernel.org/majordomo-info.html___Join
 Excite! - http://www.excite.comThe most personalized portal on the 
Web!-To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH 01/04] Adding cipher mode context information to crypto_tfm

[James Morris]

On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:

> > You can't call kmap() in softirq context (why was it even trying?):
> 
> Why not? What's the alternative, then?

It can sleep in map_new_virtual().

The alternative is to use atomic kmaps.  For this code, unless you can 
point to something concrete in the existing kernel which would benefit 
from passing an arbitrary number of scatterlists in, just code for the 
case of processing two at once (input & output).


- James
-- 
James Morris
<[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: [RFC] Linux Kernel Subversion Howto

[Theodore Ts'o]

Roman,

I suspect the most of the folks on LKML are sick and tired of
this particular thread.  Could you (and Larry) please take this
off-line, please?  Everyone who has an opinion on this matter is not
likely to change their minds, so continued rehashing of old arguments
is just noise IMHO.

Me, I'm very happy using BitKeeper and am glad that Larry and
his team of merry men have graciously provided that tool for us to
use.  In other situations I use quilt, when it is the right tool for
the job, and I am grateful to Andrew and Andreas and all those who
have provided that tool.  Other times I have played with svn because
that was what a project leader decided to use, and so thanks to the
svn developers  and as far as CVS is concerned, I suppose I'll
grudgingly have to give thanks to them too, being pioneers of
distributed SCM --- but these days, I'm glad I rarely have to use 
CVS.  :-)

I don't know how many years it was before people decided to
give up on the emacs vs. vi wars, but can we please put a more hasty
end to the bk license flamewars?  Many thanks,

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

Re: Question about sendfile

[Gianni Tedesco]

On Mon, 2005-02-07 at 22:26 -0500, Xiuduan Fang wrote:
> Hi,
> 
> I am trying to beat the I/O bottleneck so as to speed up bulk data transfers 
> in high speed network. It seems that the system call sendfile() can help to 
> reduce CPU utilization and speedup data transfers. But I have one question 
> about the system call,
> 
> First,  Linux sendfile requires that the input file descriptor cannot be a 
> network socket. What are the reasons for such a restriction? Sending a 
> socket to a file via zero copy is definitely useful.  Actually this is one 
> approach I am trying to do to improve performance.  Some discussions on 
> Linux zero copy said this is because it is harder. Sending a socket to a 
> file via zero copy needs the support of NICs. I cannot understand this 
> explanation. It seems that FreeBSD has implemented bidirectional zero 
> copy(http://people.freebsd.org/~ken/zero_copy/#Download). So why Linux does 
> not support it? What shall I do to release the restriction that Linux 
> enforces on sendfile?

>From the URL you posted:

"[zero-copy receive] generally requires some sort of intelligence on the
NIC to make sure that the payload starts in its own buffer.  This is
called "header splitting".  Currently the only NICs with support for
header splitting are Alteon Tigon 2 based boards running slightly
modified firmware."

Perhaps that explains it.

Not to mention the other complications that are involved if you scroll
down the page and read the FAQ.

Have you done any profiling work to see where your CPU cycles are being
spent?

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/scaramanga.asc | gpg --import

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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][I2C] Marvell mv64xxx i2c driver

[Bartlomiej Zolnierkiewicz]

Hi,

just a minor thing

> +static int __devinit
> +mv64xxx_i2c_init(void)
> +{
> +   return driver_register(_i2c_driver);
> +}

__init

> +static void __devexit
> +mv64xxx_i2c_exit(void)
> +{
> +   driver_unregister(_i2c_driver);
> +   return;
> +}

__exit

these functions relate to module not device

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

2.6.10 kprobes/jprobes panic

[Badari Pulavarty]

Hi,

I ran into this while playing with jprobes in 2.6.10.

I tried to install jprobe handler on a invalid address,
I get OOPS. I was hoping for a error check and a graceful
exit rather than kernel Oops.

Thanks,
Badari


plant jprobe at c01836b0, handler addr a080
Unable to handle kernel paging request at c01836b0 RIP:
{__memcpy+114}
PML4 17d6cf067 PGD 0
Oops:  [1] SMP
CPU 1
Modules linked in: diotest
Pid: 14225, comm: insmod Not tainted 2.6.10n
RIP: 0010:[] {__memcpy+114}
RSP: 0018:01019b841d58  EFLAGS: 00010047
RAX: ffa7 RBX: 0101bfa44200 RCX: 
RDX: 000f RSI: c01836b0 RDI: ffa7
RBP: a8e0 R08: 01018000 R09: 
R10: 0101bfa44218 R11: 0111 R12: 0216
R13: 804f1440 R14: 0020 R15: 0002
FS:  002a9588e6e0() GS:80628800()
knlGS:55970080
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: c01836b0 CR3: 0001a072c000 CR4: 06e0
Process insmod (pid: 14225, threadinfo 01019b84, task
0101bf9394e0)
Stack: 0101bfa44200 8011edcc 0212
a8e0
   ffef 80158542 804f1480
a940
   804f1440 a05c
Call Trace:{arch_prepare_kprobe+300}
{register_kprobe+82}
   {:diotest:init_dmods+44}
{sys_init_module+6387}
   {__pagevec_free+32}
{release_pages+382}
   {do_munmap+918}
{__down_read+49}
   {__up_write+48}
{system_call+126}

 

 
Code: 4c 8b 06 4c 89 07 48 8d 7f 08 48 8d 76 08 75 ee 89 d1 83 e1
RIP {__memcpy+114} RSP <01019b841d58>
CR2: c01836b0



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

Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement

[Shailabh Nagar]

As best as I can figure out, CKRM is a fair share scheduler with a
gussied up more modular architecture, so that the components to track
usage, control (throttle) tasks, and classify tasks are separate
plugins.  
> I'm not an expert on CKRM, so I'll leave the refuting (or notrefuting)
> of your claims as to CKRM's usefulness to someone with more background
> and expertise on the subject.  Anyone want to pipe up and defend the
> alleged "gussied up" fair-share scheduler?
Well, I'm not sure I want to minutely examine Paul's choice of words !
I would have thought that two OLS and one KS presentation would suffice 
to clarify what CKRM is and isn't but that doesn't seem to be the case 
:-) So here we go again

CKRM is both a resource management infrastructure AND
a set of controllers. The two are independent.
The infrastructure provides for
a) grouping of kernel objects (currently only tasks & sockets but can be 
extended to any others)
b) an external interface for manipulating attributes of the grouping 
such as shares, statistics and members
c) an internal interface for controllers to exploit this grouping 
information in whatever way it wants.

The controllers do whatever they want with the grouping info.
The IBM folks on the project have written ONE set of controllers for 
cpu, mem, io, net and numtasks which HAPPENS to be/aspire to be 
fair-share. Others are free to write ones which ignore share settings 
and be unfair, callous or whatever else they want.

We would love to have people write alternate controllers for the same 
resources (cpu,mem,io,net,numtasks) and others. The former will provide 
alternatives to our implementation, the latter will validate the 
architecture's utility.


I can find no significant and useful overlap on any of these
fronts, either the existing plugins or their infrastructure, with what
cpusets has and needs.
There are claims that CKRM has some generalized resource management
architecture that should be able to handle cpusets needs, but despite my
repeated (albeit not entirely successful) efforts to find documentation
and read source and my pleadings with Matthew and earlier on this
thread, I was never able to figure out what this meant, or find anything
that could profitably integrate with cpusets.
Rereading the earlier posts on the thread, I'd agree. There are some 
similarities in our interfaces but not enough to warrant a merger.

-- Shailabh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 01/04] Adding cipher mode context information to crypto_tfm

[Fruhwirth Clemens]

On Tue, 2005-02-08 at 18:30 -0500, James Morris wrote:
> On Tue, 8 Feb 2005, Fruhwirth Clemens wrote:
> 
> > I shot out the last patch too quickly. Having reviewed the mapping one
> > more time I noticed, that there as the possibility of "off-by-one"
> > unmapping, and instead of doing doubtful guesses, if that's the case, I
> > added a base pointer to scatter_walk, which is the pointer returned by
> > kmap. Exactly this pointer will be unmapped again, so the vaddr
> > comparison in crypto_kunmap doesn't have to do any masking.
> 
> You can't call kmap() in softirq context (why was it even trying?):

Why not? What's the alternative, then?

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

Re: [PATCH 2.4] SIOCSIFNAME wildcard support (resend)

[David S. Miller]

On Tue, 8 Feb 2005 14:37:15 -0800
Jean Tourrilhes <[EMAIL PROTECTED]> wrote:

>   It was sent to netdev :
> http://marc.theaimsgroup.com/?l=linux-netdev=110747857226852=2

Resend it to netdev instead, please.

If nobody responds, it means the networking maintainers simply
are backlogged and don't have time to review and integrate your
patch at this 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: [PATCH] BSD Secure Levels: nits, 2.6.11-rc2-mm1 (6/8)

[Chris Wright]

* Michael Halcrow ([EMAIL PROTECTED]) wrote:
> This is the sixth in a series of eight patches to the BSD Secure
> Levels LSM.  It makes several trivial changes to make the code
> consistent.

These are inconsistent with CodingStyle.  I'd drop this, and go the
other way (patch is smaller) ala Lindent.

>  struct seclvl_obj {
> - char *name;
> + char * name;

This is opposite of typical style.

> -seclvl_attr_store(struct kobject *kobj,
> -   struct attribute *attr, const char *buf, size_t len)
> +seclvl_attr_store(struct kobject * kobj,
> +   struct attribute * attr, const char * buf, size_t len)

same here...etc.

Lindent nearly undoes all these changes.  If we're going to reformat
code, I'd prefer to see it done via Lindent.

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Fix ALPS sync loss

[Dmitry Torokhov]

Hi,

Here is the promised patch. It turns out protocol validation code was
a bit (or rather a byte ;) ) off.

Please let me know if it fixes your touchpad and I believe it would be
nice to have it in 2.6.11.

-- 
Dmitry


===


[EMAIL PROTECTED], 2005-02-08 18:12:06-05:00, [EMAIL PROTECTED]
  Input: alps - fix protocol validation rules causing touchpad
 to lose sync if an absolute packet is received after
 a relative packet with negative Y displacement.
  
  Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
  


 alps.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


===



diff -Nru a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
--- a/drivers/input/mouse/alps.c2005-02-08 18:16:27 -05:00
+++ b/drivers/input/mouse/alps.c2005-02-08 18:16:27 -05:00
@@ -198,8 +198,8 @@
return PSMOUSE_BAD_DATA;
 
/* Bytes 2 - 6 should have 0 in the highest bit */
-   if (psmouse->pktcnt > 1 && psmouse->pktcnt <= 6 &&
-   (psmouse->packet[psmouse->pktcnt] & 0x80))
+   if (psmouse->pktcnt >= 2 && psmouse->pktcnt <= 6 &&
+   (psmouse->packet[psmouse->pktcnt - 1] & 0x80))
return PSMOUSE_BAD_DATA;
 
if (psmouse->pktcnt == 6) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] BSD Secure Levels: claim block dev in file struct rather than inode struct, 2.6.11-rc2-mm1 (3/8)

[Chris Wright]

* Michael Halcrow ([EMAIL PROTECTED]) wrote:
> [...].  This occurs because the bd_release function will
> bd_release(bdev) and set inode->i_security to NULL on the close(fd1).
> Hence, we want to place the control at the level of the file struct,
> not the inode.

This is basically what I was referring to pre-merge.  And it is still
not fully sufficient.  Multiple processes can share an fd.  So the test
against current is broken.  Also well-behaved apps that are already
using O_EXCL will break.  Using filp as the holder is sufficient to fix
both of these issues.  Here's a 3.5/8 that will fix this.  6/8 no longer
applies cleanly with this change.

Signed-off-by: Chris Wright <[EMAIL PROTECTED]>

--- a/security/seclvl.c~bd_claim2005-02-08 15:05:09.0 -0800
+++ b/security/seclvl.c 2005-02-08 15:05:17.0 -0800
@@ -492,17 +492,16 @@
  */
 static int seclvl_bd_claim(struct file * filp)
 {
-   int holder;
struct block_device *bdev = NULL;
dev_t dev = filp->f_dentry->d_inode->i_rdev;
bdev = open_by_devnum(dev, FMODE_WRITE);
if (bdev) {
-   if (bd_claim(bdev, )) {
+   if (bd_claim(bdev, filp)) {
blkdev_put(bdev);
return -EPERM;
}
/* Claimed; mark it to release on close */
-   filp->f_security = current;
+   filp->f_security = filp;
}
return 0;
 }
@@ -597,7 +596,7 @@
if (dentry && (filp->f_mode & FMODE_WRITE)) {
struct inode * inode = dentry->d_inode;
if (inode && S_ISBLK(inode->i_mode)
-   && filp->f_security == current) {
+   && filp->f_security == filp) {
struct block_device *bdev = inode->i_bdev;
if (bdev) {
bd_release(bdev);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.4] Wireless Extension v17 (resend)

[Marcelo Tosatti]

On Tue, Feb 08, 2005 at 11:45:31PM +0100, Willy Tarreau wrote:
> Hi Marcelo,
> 
> On Tue, Feb 08, 2005 at 04:41:46PM -0200, Marcelo Tosatti wrote:
> > > 
> > >   There need to be some unique features in 2.6.X to force people
> > > to upgrade, I guess...
> > 
> > Faster, cleaner, way more elegant, handles intense loads more gracefully, 
> 
> When a CPU-hungry task freezes another one for more than 13 seconds, I cannot
> agree with your last statement, and that's why I still don't upgrade. I have
> already posted examples of worst case scenarios, but I now start to have a
> more meaningful example to show so that people working on the scheduler may
> have something clearer to work with. I also did not have time to retest -ck
> or staircase recently, but I will do for completeness.

v2.6 scheduler regressions cannot be tolerated. 

Please prepare more detailed data about your problem - I'm sure Ingo and friends
will appreciate it.

> > handles highmem decently, LSM/SELinux, etc, etc...
> > 
> > IMO everyone should upgrade whenever appropriate. 
> 
> I still know about a tens of 2.2 still running around at customers ;-)
> However, if it had not been for lazyness, they should have upgraded. 

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

Re: 3TB disk hassles

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Neil Conway <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> Since writing the above, I've been searching for more info.  I
> downloaded four different versions of grub (GNU Grub Legacy, GNU Grub2,
> gentoo and Fedora Core 3).  NONE of these showed any evidence of GPT
> support (I was in a hurry, so I searched for strings EFI, GUID, GPT,
> TB).
> 
> Mucho confused puppy here.
> 
> I fail to see how grub can work on a GPT boot device if it can't parse
> the partition table.  I conclude that I'm still missing something. 
> Perhaps a layer before grub is supposed to parse the GPT instead?  If
> so, isn't that getting us straight back to a GPT-aware BIOS?
> 
> Tell me if this logic is broken: even if a special boot sector is used,
> which IS GPT-aware (though fitting that into the boot sector would be a
> challenge ;-)), once grub loads, it's still going to have to figure out
> how to find the root(hdX,Y) partition from which to load the kernel
> image.  This surely means it has to have either a GPT-parser
> internally, or rely on a pre-parsed list.  No?
> 
> Perhaps one of the other several distros (that I didn't check) has a
> GPT-aware grub.  But Tomas Carnecky said early in this thread that
> gentoo had allowed him to set up a GPT-booting system on x86.  I guess
> it's possible that a cheat was used - maybe an old-style partition
> table in the MBR was used to define the first (boot) partition, but
> surely that's forbidden by the whole EFI spec anyway?
> 

No, it's encouraged.

> 
> Andries Brouwer kindly wrote a patch which I haven't had time to test
> yet (see earlier in thread).  While it would be nice to find a way
> around the problem which didn't require deviations from vanilla
> distros, I think Andries' patch is looking like the only sane fix right
> now.
> 

Note that Andries' patch does *EXACTLY* the same thing as the GPT/EFI
spec does (by using an old-style partition table for the first 2 TB.)

It should be pretty easy to add native support for this in EXTLINUX;
the big problem is supporting true access > 2 TB, which I currently
don't have any way to test.

I'll put that on my todo list.

-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 01/04] Adding cipher mode context information to crypto_tfm

[James Morris]

On Tue, 8 Feb 2005, Fruhwirth Clemens wrote:

> I shot out the last patch too quickly. Having reviewed the mapping one
> more time I noticed, that there as the possibility of "off-by-one"
> unmapping, and instead of doing doubtful guesses, if that's the case, I
> added a base pointer to scatter_walk, which is the pointer returned by
> kmap. Exactly this pointer will be unmapped again, so the vaddr
> comparison in crypto_kunmap doesn't have to do any masking.

You can't call kmap() in softirq context (why was it even trying?):

Debug: sleeping function called from invalid context at arch/i386/mm/highmem.c:5
in_atomic():1, irqs_disabled():0
 [] dump_stack+0x17/0x19
 [] __might_sleep+0xc4/0xd7
 [] kmap+0x15/0x2e
 [] scatterwalk_map+0x5a/0x68
 [] scatterwalk_walk+0x2e/0x45b
 [] cbc_decrypt_iv+0x11a/0x15f
 [] cbc_decrypt+0x19/0x1f
 [] esp_input+0x17d/0x409 [esp4]
 [] xfrm4_rcv_encap+0x102/0x512
 [] ip_local_deliver+0x9d/0x28c
 [] ip_rcv+0x251/0x508
 [] netif_receive_skb+0x1f6/0x223
 [] process_backlog+0x7c/0x10f
 [] net_rx_action+0x79/0xfb
 [] __do_softirq+0x62/0xcc
 [] do_softirq+0x57/0x5b



- James
-- 
James Morris
<[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: prezeroing V6 [2/3]: ScrubD

[cliff white]

On Tue, 8 Feb 2005 12:51:05 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:

> On Tue, 8 Feb 2005, Andrew Morton wrote:
> 
> > We also need to try to identify workloads whcih might experience a
> > regression and test them too.  It isn't very hard.
> 
> I'd be glad if you could provide some instructions on how exactly to do
> that. I have run lmbench, aim9, aim7, unixbench, ubench for a couple of
> configurations. But which configurations do you want?

If we can run some tests for you on STP let me know.
( we do 1,2,4,8 CPU x86 boxes )
cliffw


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


-- 
"Ive always gone through periods where I bolt upright at four in the morning; 
now at least theres a reason." -Michael Feldman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: EBDA Question

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:"Moore, Eric Dean" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> EBDA - Extended Bios Data Area
> 
> Does Linux and various boot loaders(lilo/grub/etc)
> having any restrictions on where and how big 
> memory allocated in EBDA is? Is this
> handled for 2.4/2.6 Kernels?
> 
> Reason I ask is we are considering having
> BIOS(for a SCSI HBA Controller) allocating
> memory in EBDA for Firmware use. 
> We are concerned whether Linux would be writing
> over this region of memory during the handoff
> of BIOS to scsi lower layer driver loading.
> 

In general, dropping the EBDA below 0x9a000 is probably a
bad idea.  Recent Linux kernels and boot loaders should handle it,
though.  Keep in mind that you might find yourself in serious trouble
if you then have, for example, a PXE stack layered on top of your SCSI
BIOS.

-hpa

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][I2C] Marvell mv64xxx i2c driver

[Mark A. Greer]

Marvell makes a line of host bridge for PPC and MIPS systems.  On those 
bridges is an i2c controller.  This patch adds the driver for that i2c 
controller.

Please apply.
Depends on patch submitted by Jean Delvare: 
http://archives.andrew.net.au/lm-sensors/msg29405.html

Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
[Note: This patch is a *replacement* patch]
--
diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
--- a/drivers/i2c/busses/Kconfig2005-02-08 16:24:33 -07:00
+++ b/drivers/i2c/busses/Kconfig2005-02-08 16:24:33 -07:00
@@ -486,4 +486,14 @@
  This driver can also be built as a module.  If so, the module
  will be called i2c-pca-isa.
 
+config I2C_MV64XXX
+   tristate "Marvell mv64xxx I2C Controller"
+   depends on I2C && MV64X60 && EXPERIMENTAL
+   help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Marvell 64xxx line of host bridges.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-mv64xxx.
+
 endmenu
diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
--- a/drivers/i2c/busses/Makefile   2005-02-08 16:24:33 -07:00
+++ b/drivers/i2c/busses/Makefile   2005-02-08 16:24:33 -07:00
@@ -21,6 +21,7 @@
 obj-$(CONFIG_I2C_IXP4XX)   += i2c-ixp4xx.o
 obj-$(CONFIG_I2C_KEYWEST)  += i2c-keywest.o
 obj-$(CONFIG_I2C_MPC)  += i2c-mpc.o
+obj-$(CONFIG_I2C_MV64XXX)  += i2c-mv64xxx.o
 obj-$(CONFIG_I2C_NFORCE2)  += i2c-nforce2.o
 obj-$(CONFIG_I2C_PARPORT)  += i2c-parport.o
 obj-$(CONFIG_I2C_PARPORT_LIGHT)+= i2c-parport-light.o
diff -Nru a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/busses/i2c-mv64xxx.c  2005-02-08 16:24:33 -07:00
@@ -0,0 +1,606 @@
+/*
+ * drivers/i2c/busses/i2c-mv64xxx.c
+ * 
+ * Driver for the i2c controller on the Marvell line of host bridges for MIPS
+ * and PPC (e.g, gt642[46]0, mv643[46]0, mv644[46]0).
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista, Software, Inc.  This file is licensed under
+ * the terms of the GNU General Public License version 2.  This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register defines */
+#defineMV64XXX_I2C_REG_SLAVE_ADDR  0x00
+#defineMV64XXX_I2C_REG_DATA0x04
+#defineMV64XXX_I2C_REG_CONTROL 0x08
+#defineMV64XXX_I2C_REG_STATUS  0x0c
+#defineMV64XXX_I2C_REG_BAUD0x0c
+#defineMV64XXX_I2C_REG_EXT_SLAVE_ADDR  0x10
+#defineMV64XXX_I2C_REG_SOFT_RESET  0x1c
+
+#defineMV64XXX_I2C_REG_CONTROL_ACK 0x0004
+#defineMV64XXX_I2C_REG_CONTROL_IFLG0x0008
+#defineMV64XXX_I2C_REG_CONTROL_STOP0x0010
+#defineMV64XXX_I2C_REG_CONTROL_START   0x0020
+#defineMV64XXX_I2C_REG_CONTROL_TWSIEN  0x0040
+#defineMV64XXX_I2C_REG_CONTROL_INTEN   0x0080
+
+/* Ctlr status values */
+#defineMV64XXX_I2C_STATUS_BUS_ERR  0x00
+#defineMV64XXX_I2C_STATUS_MAST_START   0x08
+#defineMV64XXX_I2C_STATUS_MAST_REPEAT_START0x10
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_ACK 0x18
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_NO_ACK  0x20
+#defineMV64XXX_I2C_STATUS_MAST_WR_ACK  0x28
+#defineMV64XXX_I2C_STATUS_MAST_WR_NO_ACK   0x30
+#defineMV64XXX_I2C_STATUS_MAST_LOST_ARB0x38
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_ACK 0x40
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_NO_ACK  0x48
+#defineMV64XXX_I2C_STATUS_MAST_RD_DATA_ACK 0x50
+#defineMV64XXX_I2C_STATUS_MAST_RD_DATA_NO_ACK  0x58
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_2_ACK   0xd0
+#defineMV64XXX_I2C_STATUS_MAST_WR_ADDR_2_NO_ACK0xd8
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_ACK   0xe0
+#defineMV64XXX_I2C_STATUS_MAST_RD_ADDR_2_NO_ACK0xe8
+#defineMV64XXX_I2C_STATUS_NO_STATUS0xf8
+
+/* Driver states */
+enum {
+   MV64XXX_I2C_STATE_INVALID,
+   MV64XXX_I2C_STATE_IDLE,
+   MV64XXX_I2C_STATE_WAITING_FOR_START_COND,
+   MV64XXX_I2C_STATE_WAITING_FOR_ADDR_1_ACK,
+   MV64XXX_I2C_STATE_WAITING_FOR_ADDR_2_ACK,
+   MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_ACK,
+   MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_DATA,
+   MV64XXX_I2C_STATE_ABORTING,
+};
+
+/* 

Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement

[Nick Piggin]

Martin J. Bligh wrote:
What about your proposed sched domain changes?
Cant sched domains be used handle the CPU groupings and the
existing code in cpusets that handle memory continue as is?
Weren't sched somains supposed to give the scheduler better knowledge
of the CPU groupings afterall ?
sched domains can provide non overlapping top level partitions.
It would basically just stop the multiprocessor balancing from
moving tasks between these partitions (they would be manually
moved by setting explicit cpu affinities).
I didn't really follow where that idea went, but I think at least
a few people thought that sort of functionality wasn't nearly
fancy enough! :)

Not fancy seems like a positive thing to me ;-)
Yes :)
I was thinking the sched domains soft-partitioning could be a
useful feature in its own right, considering the runtime impact
would be exactly zero, and the setup code should already be mostly
there.
If anyone was interested, I could try to cook up an implementation
on the scheduler side. The biggest issues may be the userspace
interface and a decent userspace management tool.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] swsusp: do not use higher order allocations on resume [update 2]

[Rafael J. Wysocki]

On Tuesday, 8 of February 2005 23:42, Pavel Machek wrote:
> Hi!
> 
> > +static inline void eat_page(void *page) {
> 
> Please put { on new line.

Oh, I still tend to forget about this.  Corrected in the patch that is
available on the web
(http://www.sisk.pl/kernel/patches/2.6.11-rc3-mm1/swsusp-use-list-resume-v4.patch).


> Okay, as you can see, I could find very little wrong with this
> patch. That hopefully means it is okay ;-). I should still check error
> handling, but I guess I'll do it when it is applied because it is hard
> to do on a diff. I guess it should go into -mm just after 2.6.11 is
> released...

That would be great!

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: [PATCH] Re: msdos/vfat defaults are annoying

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:=?iso-8859-1?Q?Pozs=E1r_Bal=E1zs?= <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> Granted, I could override the default order by using a /etc/filesystems 
> file. But the kernel should have a much more sane default on its own, 
> namely "try vfat before msdos".
> 

What it really means is that mount(8) should know this is a special
case; presumably it already knows to try ext3 over ext2.

-hpa

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

Re: 2.6.11-rc3-mm1

[Peter Osterlund]

Robert Love <[EMAIL PROTECTED]> writes:

> On Sun, 2005-02-06 at 22:22 +0100, Peter Osterlund wrote:
> 
> > > > > EIP is a strncpy_from_user+0x33/0x47
> > > > > ...
> > > > > Call Trace:
> > > > >  getname+0x69/0xa5
> > > > >  sys_open+0x12/0xc6
> > > > >  sysenter_past_esp+0x52/0x75
> > > > > ...
> > > > > Kernel panic - not syncing: Attempted to kill init!
> > 
> > I found the if I disable CONFIG_INOTIFY, the problem goes away.
> 
> Weird.  While we touch sys_open() with an inotify hook, we do so after
> the call to getname, and we don't touch getname() or strncpy_from_user()
> at all.
> 
> I wonder if there is another bug and inotify is just affecting the
> timing?

Possible, but it fails every time with CONFIG_INOTIFY enabled and
works every time with CONFIG_INOTIFY disabled.

I added some printk's to do_getname and got this:

...
Freeing unused kernel memory: 160k freed
...
do_getname: init /etc/localtime
do_getname: init seg:1 page:df404000 filename:455dd11f len:4096
do_getname: init /etc/localtime
do_getname: init seg:1 page:df404000 filename:455dd11f len:4096
do_getname: init /etc/localtime
do_getname: init seg:1 page:df404000 filename:455dd11f len:4096
do_getname: init /etc/localtime
do_getname: init seg:1 page:df404000 filename: len:4096
Unable to handle kernel NULL pointer dereference at virtual address 
 printing eip:
c01d8257
*pde = 
Oops:  [#1]
PREEMPT 
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010206   (2.6.11-rc3-mm1) 
EIP is at strncpy_from_user+0x33/0x47
eax: c14f   ebx: fff2   ecx: 1000   edx: 1000
esi:    edi: df404000   ebp:    esp: c14f1f60
ds: 007b   es: 007b   ss: 0068
Process init (pid: 1, threadinfo=c14f task=dff4ba40)
Stack: c14f fff4 df404000  c0166854 df404000  
1000 
   df404000  1000 1000   0901 
c14f 
   c0158725    0002   
0901 
Call Trace:
 [] getname+0xb4/0x10f
 [] sys_open+0x12/0xc6
 [] sysenter_past_esp+0x52/0x75
Code: 57 56 53 bb f2 ff ff ff 8b 74 24 18 8b 7c 24 14 8b 4c 24 1c 89 f2 83 
c2 01 19 ed 39 50 18 83 dd 00 85 ed 75 13 89 ca 85 c9 74 0b  aa 84 c0 74 03 
49 75 f7 29 ca 89 d3 89 d8 5b 5e 5f 5d c3 57 
 do_getname: hotplug seg:1 page:dfca1000 filename:080e6770 len:4096
do_getname: hotplug /etc/hotplug.d/default/20-hal.hotplug
do_getname: hotplug seg:1 page:df6d1000 filename:080e6770 len:4096
do_getname: hotplug /etc/hotplug.d/default/20-hal.hotplug
Kernel panic - not syncing: Attempted to kill init!

If I add this code to do_getname()

+   if (!filename)
+   return -EFAULT;

the machine boots correctly, but then fails later when trying to start
the X server:

Unable to handle kernel paging request at virtual address 8050
 printing eip:
c01d840a
*pde = 16fd4067
*pte = 
Oops: 0002 [#1]
PREEMPT 
Modules linked in: radeon joydev mousedev nfs psmouse snd_atiixp_modem nfsd 
exportfs lockd parport_pc lp parport autofs4 pcmcia sunrpc ipt_LOG ipt_limit 
ipt_state ipt_REJECT iptable_filter ipt_MASQUERADE iptable_nat ip_tables 
binfmt_misc dm_mod yenta_socket rsrc_nonstatic pcmcia_core ohci_hcd ehci_hcd 
usbcore ide_cd cdrom
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00013246   (2.6.11-rc3-mm1) 
EIP is at __copy_to_user_ll+0x3c/0x64
eax:    ebx: 8050   ecx: 0002   edx: 8058
esi: e1a5cc67   edi: 8050   ebp:    esp: d75e9e58
ds: 007b   es: 007b   ss: 0068
Process X (pid: 4757, threadinfo=d75e8000 task=d7584020)
Stack: 0027 8050   e1a5cc70 c01d84ce 8050 
e1a5cc67 
   0008 0008 d75e9ec8 e1a51140 8050 e1a5cc67 0008 
 
   d75e9f08 c01d8511 d75e9f08 bfd4a320 d7957800 bfd4a320 d75e9f08 
ffea 
Call Trace:
 [] copy_to_user+0x38/0x42
 [] version+0xe8/0x138 [radeon]
 [] copy_from_user+0x39/0x68
 [] drm_setversion+0x49/0x11b
 [] drm_ioctl+0xeb/0x1c1
 [] handle_vm86_fault+0x78f/0x909
 [] handle_vm86_fault+0x78f/0x909
 [] do_ioctl+0x57/0x85
 [] handle_vm86_fault+0x78f/0x909
 [] vfs_ioctl+0x5c/0x1c3
 [] handle_vm86_fault+0x78f/0x909
 [] sys_ioctl+0x3c/0x59
 [] handle_vm86_fault+0x78f/0x909
 [] sysenter_past_esp+0x52/0x75
 [] handle_vm86_fault+0x78f/0x909
Code: 83 f9 3f 76 0c 89 f8 31 f0 85 05 80 bd 44 c0 75 28 89 c8 83 f9 07 76 
17 89 f9 f7 d9 83 e1 07 29 c8 f3 a4 89 c1 c1 e9 02 83 e0 03  a5 89 c1 f3 a4 
83 c4 0c 5e 89 c8 5f c3 89 4c 24 08 89 74 24 
 <3>[drm:drm_release] *ERROR* Device busy: 1 0

Patch used during tests:

diff -puN fs/namei.c~panic-debug fs/namei.c
--- 

Re: Real-Time Preemption and UML?

[Esben Nielsen]

On Tue, 8 Feb 2005, Ingo Molnar wrote:

> 
> * Esben Nielsen <[EMAIL PROTECTED]> wrote:
> 
> > Now I don't really know who I am responding to. But both up()s now
> > changed to complete()s are in something looking very much like an
> > interrupt handler. But again, as I said, I didn't analyze the code in
> > detail, I just made it compile and checked that it worked in bare
> > 2.6.11-rc2 UML - which I am not too sure how to set up and use to
> > begin with!
> 
> btw., UML is really easy to begin with: after you've compiled you get a
> 'linux' binary in the toplevel directory - just execute it via './linux'
> and you'll see a Linux kernel booting - that's all you need!
> 
> Add a filesystem image via a root= parameter to that command and the UML
> kernel will start booting that filesystem image. (if you are adventurous
> you can even boot a real partition, but for the first user this is
> strongly discouraged.) There are a number of UML-ready filesystem images
> downloadable from the net.
> 
Thanks, I managed to get that far after googling a bit. I have had some 
problems with the filesystem though. Fixed now (I forgot to compile ext3
in *blush*.) But you might still be interessted in this trace (2.6.11-rc2
with or without my changes):

line_ioctl: tty0: ioctl KDSIGACCEPT called
Debug: sleeping function called from invalid context at
include/asm/arch/semaphore.h:107
in_atomic():0, irqs_disabled():1
Call Trace: 
a08639e0:  [] __might_sleep+0x9b/0xb8
a0863a10:  [] uml_console_write+0x20/0x54
a0863a30:  [] __call_console_drivers+0x50/0x58
a0863a60:  [] call_console_drivers+0x7d/0x124
a0863a90:  [] release_console_sem+0xa3/0x25c
a0863aa0:  [] release_console_sem+0xbc/0x25c
a0863ac0:  [] vprintk+0x193/0x2d0
a0863ae0:  [] printk+0x12/0x14
a0863b00:  [] line_ioctl+0x8e/0x94
a0863b24:  [] line_ioctl+0x0/0x94
a0863b30:  [] tty_ioctl+0xfd/0x680
a0863b80:  [] do_ioctl+0x3f/0x64
a0863bb0:  [] sys_ioctl+0x13d/0x350
a0863bd0:  [] sys_open+0x5b/0x74
a0863be0:  [] sys_open+0x4c/0x74
a0863c00:  [] execute_syscall_tt+0xa1/0xe0
a0863c1c:  [] sigemptyset+0x17/0x30
a0863c70:  [] record_syscall_start+0x4e/0x58
a0863c90:  [] syscall_handler_tt+0x3f/0x74
a0863cc0:  [] sig_handler_common_tt+0x90/0x108
a0863cd0:  [] sig_handler_common_tt+0xf1/0x108
a0863d00:  [] sig_handler+0x1f/0x38
a0863d20:  [] __restore+0x0/0x8

It could look like a semaphore which should be replaced by a spinlock
(which will become a mutex in preempt-realtime :-)


Esben

>   Ingo

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

2.6.10-ac12 + kernbench == oom-killer: (OSDL)

[cliff white]

Running 2.6.10-ac10 on the STP 1-CPU machines, we don't seem to be able to 
complete
a kernbench run without hitting the OOM-killer. ( kernbench is multiple kernel 
compiles,
of course ) Machine is 800 mhz PIII with 1GB memory. We reduce memory for some 
of the runs.

Typical results:

stp1-001 login: oom-killer: gfp_mask=0xd2
DMA per-cpu:
cpu 0 hot: low 2, high 6, batch 1
cpu 0 cold: low 0, high 2, batch 1
Normal per-cpu:
cpu 0 hot: low 32, high 96, batch 16
cpu 0 cold: low 0, high 32, batch 16
HighMem per-cpu: empty

Free pages:   14084kB (0kB HighMem)
Active:95617 inactive:4153 dirty:0 writeback:78 unstable:0 free:3521 slab:10320 
mapped:99590 pagetables:12514
DMA free:1860kB min:88kB low:108kB high:132kB active:3512kB inactive:3428kB pres
ent:16384kB pages_scanned:3318 all_unreclaimable? no
protections[]: 0 0 0
Normal free:12224kB min:2800kB low:3500kB high:4200kB active:378956kB inactive:1
3184kB present:506880kB pages_scanned:10146 all_unreclaimable? no
protections[]: 0 0 0
HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present:
0kB pages_scanned:0 all_unreclaimable? no
protections[]: 0 0 0
DMA: 375*4kB 33*8kB 2*16kB 0*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048
kB 0*4096kB = 1860kB
Normal: 2194*4kB 107*8kB 24*16kB 1*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 
1*2048kB 0*4096kB = 12224kB
HighMem: empty
Swap cache: add 14113357, delete 14112531, find 151467/1660782, race 427+1738
Out of Memory: Killed process 14970 (cc1).
-
It looks like some oom-related stuff went into -ac10, will try retest with 
-ac9 and -ac10, see what happens. Lemme know if we can do more

cliffw


-- 
"Ive always gone through periods where I bolt upright at four in the morning; 
now at least theres a reason." -Michael Feldman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.4] Wireless Extension v17 (resend)

[Willy Tarreau]

Hi Marcelo,

On Tue, Feb 08, 2005 at 04:41:46PM -0200, Marcelo Tosatti wrote:
> > 
> > There need to be some unique features in 2.6.X to force people
> > to upgrade, I guess...
> 
> Faster, cleaner, way more elegant, handles intense loads more gracefully, 

When a CPU-hungry task freezes another one for more than 13 seconds, I cannot
agree with your last statement, and that's why I still don't upgrade. I have
already posted examples of worst case scenarios, but I now start to have a
more meaningful example to show so that people working on the scheduler may
have something clearer to work with. I also did not have time to retest -ck
or staircase recently, but I will do for completeness.

> handles highmem decently, LSM/SELinux, etc, etc...
> 
> IMO everyone should upgrade whenever appropriate. 

I still know about a tens of 2.2 still running around at customers ;-)
However, if it had not been for lazyness, they should have upgraded.

Cheers,
Willy

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

Re: where to export system tuneables, /proc/sys/kernel or /sys/?

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Chris Friesen <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> I'm doing some kernel work that will export tuneables to userspace.  In 
> 2.4 I would have used /proc/sys/kernel, but now there is /sys, which was 
> supposed to be for system information.
> 
> However, a bit of poking around in /sys didn't reveal any obvious place 
> to put it.  Is current practice to still put this sort of thing in /proc?
> 

/proc/sys/kernel, using the sysctl internals, yes.

Note that the use of the sysctl(2) system call is highly deprecated,
but the /proc/sys filesystem tree is not; the reason is that the
numeric API used by the former is unstable.

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

Re: [RFC][PATCH] swsusp: do not use higher order allocations on resume [update 2]

[Pavel Machek]

Hi!

> +static inline void eat_page(void *page) {

Please put { on new line.

Okay, as you can see, I could find very little wrong with this
patch. That hopefully means it is okay ;-). I should still check error
handling, but I guess I'll do it when it is applied because it is hard
to do on a diff. I guess it should go into -mm just after 2.6.11 is
released...

Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: the "Turing Attack" (was: Sabotaged PaXtest)

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Ingo Molnar <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> This, on the face of it, seems like a ridiculous possibility as the
> chances of that are reverse proportional to the number of bits necessary
> to implement the simplest Turing Machine. (which for anything even
> closely usable are on the order of 2^1, less likely than the
> likelyhood of us all living to the end of the Universe.)
> 

2^1?  Not even close.  You can build a fully Turing-complete
interpreter in a few tens of bytes (a few hundred bits) on most
architectures, and you have to consider ALL bit combinations that can
form an accidental Turing machine.

What is far less clear is whether or not you can use that accidental
Turing machine to do real damage.  After all, it's not computation (in
the strict sense) that causes security violations, it's I/O.  Thus,
the severity of the problem depends on which I/O primitives the
accidental Turing machine happens to embody.  Note that writing to the
memory of the host process is considered I/O for this purpose.

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

Re: [PATCH 2.4] SIOCSIFNAME wildcard support (resend)

[Jean Tourrilhes]

On Tue, Feb 08, 2005 at 02:24:22PM -0800, David S. Miller wrote:
> On Tue, 8 Feb 2005 16:04:45 -0200
> Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, Feb 08, 2005 at 10:14:36AM -0800, Jean Tourrilhes wrote:
> > >   Hi Marcelo,
> > > 
> > >   I did not receive any feedback on this e-mail, so I assume it
> > > was lost on the way. Would you mind pushing that in 2.4.x ?
> > >   Thanks...
> > 
> > As an ignorant person I have no problems with it.
> > 
> > David, what is your opinion?
> 
> If networking patches are sent purely to linux-kernel, they will often
> be missed.  Please use netdev@oss.sgi.com, Jean of all people should be
> more than aware of netdev@oss.sgi.com as the place to post and discuss
> networking patches, not linux-kernel and not privately to Marcelo or
> myself.
> 
> I only happened to spot this post by accident this time, I'm being
> asked a question and I'm not even CC:'d on the email. :-)

It was sent to netdev :
http://marc.theaimsgroup.com/?l=linux-netdev=110747857226852=2

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

[Nigel Cunningham]

Hi.

On Wed, 2005-02-09 at 09:32, Pavel Machek wrote:
> Hi!
> 
> > > > The main change involves the introduction of a new SYNCTHREAD flag. We
> > > > use this to avoid deadlocking over processes that are running sys_sync
> > > > and siblings. Processes that enter those routines get the flag added,
> > > > and it's removed when they exit the sync routine. We then freeze in four
> > > > stages: 
> > > 
> > > Is SYNCTHREAD neccessary for me, too, or is it needed for suspend2, only?
> > 
> > It's necessary for reliable freezing under I/O load. Signalling the
> > non-sync threads first removes the race involved in some threads
> > submitting I/O while others are trying to sync. Try doing a dd and a
> > sync at the same time. The sync can take ages to return, worst case,
> > sometimes not until the dd is completed. (Actually, try doing anything
> > while a dd is running :>)
> 
> Okay, just attach this explanation when you are merging it otherwise
> I'll surely ask again...

Okay.

> > > > Finally I'd like to merge the support for freezer flags on workqueues.
> > 
> > No comment here? :>
> 
> :-). I forgot why it was neccessary, but I was too shy to ask
> ;-). Just attach nice explanation when you attempt to merge it.

Okay.

Thanks!

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028  Mob: +61 (417) 100 574

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