Re: New XFS, ReiserFS and Ext2 benchmarks
Ricardo Galli wrote: > > Hi, > you can find at http://bulma.lug.net/static/ a few new benchmarks among > Reiser, XFS and Ext2 (also one with JFS). > > This time there is a comprehensive Hans' Mongo benchmarks > (http://bulma.lug.net/static/mongo/ )and a couple of kernel compilations and > read/write/fsync operations tests (I was very careful of populating the > cache before the measures for the last two cases). > > Regards, > > --ricardo > http://m3d.uib.es/~gallir/ These are interesting benchmarks, my only caveats are that make bzImage is probably CPU bound not IO bound (the traditional value of compiles as FS benchmarks does not apply to Linux filesystems, as they don't do the misdesigned synchronization policy of older Unices, and compiles are CPU bound for them in my experience), that I don't understand fully why we are so much faster at the cp -ar, and I would like Yura to try to reproduce the cp -ar as it seems too good to be true. Thanks for investing the time into this Ricardo. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
On Tue, May 22, 2001 at 05:22:35AM +0200, Dave Jones wrote: > On Mon, 21 May 2001, Steven Walter wrote: > > > > Any particular reason this needs to be done in the kernel, as opposed > > > to having your script read /dev/cpu/*/cpuid? > > Wouldn't that be the same reason we have /anything/ in cpuinfo? > > When /proc/cpuinfo was added, we didn't have /dev/cpu/*/cpuid > Now that we do, we're stuck with keeping /proc/cpuinfo for > compatability reasons. AFAIK, not all processors support cpuid. /david _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Unresolved symbols with i2c and lm-sensors2
When I compile support for my hardware sensor using 2.4.4-ac12 and the latest CVS i2c and lm-sensors2 I get the following errors about unresolved symbols, is this possibly due to improperly exported symbols? Jordan ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/parport/driver.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o drivers/usb/usbdrv.o drivers/sensors/sensor.o drivers/input/inputdrv.o drivers/acpi/acpi.o \ net/network.o \ /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a /usr/src/linux/arch/i386/lib/lib.a \ --end-group \ -o vmlinux drivers/char/char.o: In function `chr_dev_init': drivers/char/char.o(.text.init+0x54): undefined reference to `i2c_init_all' drivers/sensors/sensor.o: In function `via686a_attach_adapter': drivers/sensors/sensor.o(.text+0x10): undefined reference to `sensors_detect' drivers/sensors/sensor.o: In function `via686a_detect': drivers/sensors/sensor.o(.text+0x27a): undefined reference to `i2c_attach_client' drivers/sensors/sensor.o(.text+0x293): undefined reference to `sensors_register_entry' drivers/sensors/sensor.o(.text+0x2b2): undefined reference to `i2c_detach_client' drivers/sensors/sensor.o: In function `via686a_detach_client': drivers/sensors/sensor.o(.text+0x2ee): undefined reference to `sensors_deregister_entry' drivers/sensors/sensor.o(.text+0x2f4): undefined reference to `i2c_detach_client' drivers/sensors/sensor.o: In function `sensors_init_all': drivers/sensors/sensor.o(.text.init+0x1): undefined reference to `sensors_init' drivers/sensors/sensor.o: In function `sensors_via686a_init': drivers/sensors/sensor.o(.text.init+0x61): undefined reference to `i2c_add_driver' drivers/sensors/sensor.o: In function `via686a_cleanup': drivers/sensors/sensor.o(.text.init+0xa1): undefined reference to `i2c_del_driver' drivers/sensors/sensor.o(.data+0x314): undefined reference to `sensors_proc_real' drivers/sensors/sensor.o(.data+0x318): undefined reference to `sensors_sysctl_real' drivers/sensors/sensor.o(.data+0x340): undefined reference to `sensors_proc_real' drivers/sensors/sensor.o(.data+0x344): undefined reference to `sensors_sysctl_real' drivers/sensors/sensor.o(.data+0x36c): undefined reference to `sensors_proc_real' drivers/sensors/sensor.o(.data+0x370): undefined reference to `sensors_sysctl_real' drivers/sensors/sensor.o(.data+0x398): undefined reference to `sensors_proc_real' drivers/sensors/sensor.o(.data+0x39c): undefined reference to `sensors_sysctl_real' drivers/sensors/sensor.o(.data+0x3c4): undefined reference to `sensors_proc_real' drivers/sensors/sensor.o(.data+0x3c8): undefined reference to `sensors_sysctl_real' drivers/sensors/sensor.o(.data+0x3f0): undefined reference to `sensors_proc_real' drivers/sensors/sensor.o(.data+0x3f4): undefined reference to `sensors_sysctl_real' drivers/sensors/sensor.o(.data+0x41c): undefined reference to `sensors_proc_real' drivers/sensors/sensor.o(.data+0x420): undefined reference to `sensors_sysctl_real' drivers/sensors/sensor.o(.data+0x448): undefined reference to `sensors_proc_real' drivers/sensors/sensor.o(.data+0x44c): undefined reference to `sensors_sysctl_real' drivers/sensors/sensor.o(.data+0x474): undefined reference to `sensors_proc_real' drivers/sensors/sensor.o(.data+0x478): undefined reference to `sensors_sysctl_real' drivers/sensors/sensor.o(.data+0x4a0): undefined reference to `sensors_proc_real' drivers/sensors/sensor.o(.data+0x4a4): undefined reference to `sensors_sysctl_real' drivers/sensors/sensor.o(.data+0x4cc): undefined reference to `sensors_proc_real' drivers/sensors/sensor.o(.data+0x4d0): undefined reference to `sensors_sysctl_real' drivers/sensors/sensor.o(.data+0x4f8): undefined reference to `sensors_proc_real' drivers/sensors/sensor.o(.data+0x4fc): undefined reference to `sensors_sysctl_real' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] include/linux/coda.h
Coda.h assumes that __KERNEL__ can only be defined if __linux__ is, which is
painfully false. This allows the kernel compile to get farther on my token
FreeBSD box.
-Ryan
--- linux/include/linux/coda.h Wed Apr 25 16:18:54 2001
+++ linux/include/linux/coda.h Mon May 21 21:19:21 2001
@@ -100,6 +100,10 @@
#if defined(__linux__)
#define cdev_t u_quad_t
+#else
+#define cdev_t dev_t
+#endif
+
#ifndef __KERNEL__
#if !defined(_UQUAD_T_) && (!defined(__GLIBC__) || __GLIBC__ < 2)
#define _UQUAD_T_ 1
@@ -108,9 +112,6 @@
#else /*__KERNEL__ */
typedef unsigned long long u_quad_t;
#endif /* __KERNEL__ */
-#else
-#define cdev_t dev_t
-#endif
#ifdef __CYGWIN32__
struct timespec {
Re:
send a mail to [EMAIL PROTECTED] with 'help' in the body of the mail cheers rajiv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
No Subject
I want to include my self in your mailing list, Thanks Anita [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers/acpi/driver.c (repost)
Hello!
This is a repost of my previous message, which came out garbled. Now you
should be able to run patch -pO from the root linux dir on the files...
There is a bug in driver.c of not freeing memory on error
paths. buf.pointer is allocated but not freed if copy_to_user fails. The
addition I made was to kfree buf.pointer before returning -EFAULT. Thanks!
Philip
--- drivers/acpi/driver.c.orig Mon May 21 20:36:55 2001
+++ drivers/acpi/driver.cMon May 21 20:37:21 2001
@@ -311,8 +311,10 @@
size = buf.length - file->f_pos;
if (size > *len)
size = *len;
- if (copy_to_user(buffer, data, size))
- return -EFAULT;
+ if (copy_to_user(buffer, data, size)) {
+ kfree(buf.pointer);
+ return -EFAULT;
+ }
}
kfree(buf.pointer);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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]drivers/net/wan/lmc/lmc_main.c
Hey All,
I am working with Dawson Engler's meta-compillation group @ stanford.
Sorry if this is reposted, previous one seemed to get tied up.
Here is a patch to the drivers/net/wan/lmc/lmc_main.c file.
On line 503, the authors use the GFP_KERNEL argument to kmalloc, how
ever
they are holding a spin lock during this period. They should use
GFP_ATOMIC here.
On line 510, the authors rely on a macro, LMC_COPY_FROM_USER which is
designed to work with stack memory, not heap memory. In all other cases
it is fine, here however, the memory must be deallocated before -EFAULT
can be returned. Note that this is a potential security hole as it is
leaking memory and can be exploited by passing bogus pointers to
copy_to_user - thus creating a DOS situation.
--- drivers/net/wan/lmc/lmc_main.c.orig Thu May 17 12:03:49 2001
+++ drivers/net/wan/lmc/lmc_main.c Mon May 21 20:13:49 2001
@@ -500,14 +500,17 @@
break;
}
-data = kmalloc(xc.len, GFP_KERNEL);
+data = kmalloc(xc.len, GFP_ATOMIC);
if(data == 0x0){
printk(KERN_WARNING "%s: Failed to allocate memory for
copy\n", dev->name);
ret = -ENOMEM;
break;
}
-LMC_COPY_FROM_USER(data, xc.data, xc.len);
+ if(copy_from_user(data, xc.data, xc.len)){
+ kfree(data);
+ return -EFAULT;
+ }
printk("%s: Starting load of data Len: %d at 0x%p == 0x%p\n",
dev->name, xc.len, xc.data, data)
Thanks!
-Akash Jain
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
On Mon, 21 May 2001, Steven Walter wrote: > > Any particular reason this needs to be done in the kernel, as opposed > > to having your script read /dev/cpu/*/cpuid? > Wouldn't that be the same reason we have /anything/ in cpuinfo? When /proc/cpuinfo was added, we didn't have /dev/cpu/*/cpuid Now that we do, we're stuck with keeping /proc/cpuinfo for compatability reasons. regards, Dave. -- | Dave Jones.http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
On Mon, May 21, 2001 at 08:16:18AM -0700, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:"Martin.Knoblauch" <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Hi, > > > > while trying to enhance a small hardware inventory script, I found that > > cpuinfo is missing the details of L1, L2 and L3 size, although they may > > be available at boot time. One could of cource grep them from "dmesg" > > output, but that may scroll away on long lived systems. > > > > Any particular reason this needs to be done in the kernel, as opposed > to having your script read /dev/cpu/*/cpuid? Wouldn't that be the same reason we have /anything/ in cpuinfo? -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] drivers/acpi/driver.c
Hello!
There is a bug in driver.c of not freeing memory on error
paths. buf.pointer is allocated but not freed if copy_to_user fails. The
addition I made was to kfree buf.pointer before returning -EFAULT. Thanks!
Philip
--- /2.4.4/linux/drivers/acpi/driver.c Fri Feb 9 11:45:58 2001
+++ driver.cMon May 21 19:21:14 2001
@@ -311,8 +311,10 @@
size = buf.length - file->f_pos;
if (size > *len)
size = *len;
- if (copy_to_user(buffer, data, size))
- return -EFAULT;
+ if (copy_to_user(buffer, data, size)) {
+ kfree(buf.pointer);
+ return -EFAULT;
+ }
}
kfree(buf.pointer);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
New XFS, ReiserFS and Ext2 benchmarks
Hi, you can find at http://bulma.lug.net/static/ a few new benchmarks among Reiser, XFS and Ext2 (also one with JFS). This time there is a comprehensive Hans' Mongo benchmarks (http://bulma.lug.net/static/mongo/ )and a couple of kernel compilations and read/write/fsync operations tests (I was very careful of populating the cache before the measures for the last two cases). Regards, --ricardo http://m3d.uib.es/~gallir/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
Urban Widmark <[EMAIL PROTECTED]>: > What happened with the discussion on configurable colors in make > menuconfig? Darkblue on black as frozen options get isn't exactly optimal > ... at least not for my eyes. Being next to a bold, white text doesn't > help either. Nobody could come up with a way to support configurable colors that didn't seem like way more trouble than it was worth. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond "...quemadmodum gladius neminem occidit, occidentis telum est." [...a sword never kills anybody; it's a tool in the killer's hand.] -- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD), - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
Alexander Viro writes:
> drivers/net/ppp_generic.c:
> ppp_set_compress(struct ppp *ppp, unsigned long arg)
> {
[snip]
> if (copy_from_user(&data, (void *) arg, sizeof(data))
> || (data.length <= CCP_MAX_OPTION_LENGTH
> && copy_from_user(ccp_option, data.ptr, data.length)))
> goto out;
>
> And that's far from being uncommon. They _do_ follow pointers. Some - more
> than once.
:) That particular example is one that would probably be much cleaner
as a write on a control fd. What is there currently is just a
relatively ugly way of getting a variable-sized lump of data from
usermode into the kernel.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 del_timer_sync oops in schedule_timeout
On Mon, 21 May 2001, Andrew Morton wrote:
> It could be timer-list corruption. Someone released some memory
> which had a live timer in it. The memory got recycled and then
> the timer list traversal fell over it.
Well I do have another oops now (artsd this time). Once again it's in
del_timer_sync in 2.4.4, same computer after a reboot, same kernel. It is
a UP system (SMP kernel) btw.
Could it be that the aic7xxx driver is improperly destroying a timer? I
am having some problems with a scanner attached to the SCSI card in
question that usually result in the driver setting the scanner inactive
until I reset the scanner and rmmod/insmod the driver again.
Unable to handle kernel paging request at virtual address 2d5ca71f
printing eip:
c011bf13
*pde =
Oops: 0002
CPU:0
EIP:0010:[del_timer_sync+47/132]
EFLAGS: 00013006
eax: a2e17a6a ebx: 3246 ecx: c4047f28 edx: 2d5ca71b
esi: edi: 0010 ebp: c4045f3c esp: c4045f0c
ds: 0018 es: 0018 ss: 0018
Process artsd (pid: 2873, stackpage=c4045000)
Stack: c4047f28 0061afd0 c0112b54 c4047f28 c4045f28 c78143e0
0061afd0 c4044000 c0112a80 c4045f70 c0140b7c 0001 0004
c305c9d8 0304 c4044000 0014 0005
Call Trace: [schedule_timeout+120/144] [process_timeout+0/92]
[do_select+456/512] [sys_select+816/1136] [system_call+55/64]
Code: 89 42 04 89 10 b8 01 00 00 00 01 c6 a1 68 20 30 c0 c7 41 04
-Jacob
--
At a global level, the most developed countries "stabilize" the wars
among the outcasts depending on how important each conflict is to the
global economy.
- ``The Hacker Ethic'' by Pekka Himanen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kernel Sound Card Support
Will the kernel gain support for newer Turtle Beach soundcards, such as the Santa Cruz, anytime soon? Thanks for any info. Jordan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Dead symbols in CMl1
I think I've identified a number of dead symbols. Here's a list: CONFIG_BAGETBSM (Baget Backplane Shared Memory support) Set in arch/mips64/config.in, not used anywhere. CONFIG_ACPI_INTERPRETER (ACPI interpreter) Set in arch/ia64/config.in, not used anywhere. CONFIG_BINFMT_JAVA (Kernel support for JAVA binaries) Set in arch/parisc/config.in and arch/cris/config.in, not used anywhere. CONFIG_SCSI_DECSII (DEC SII SCSI Driver) Set in drivers/scsi/Config.in, not used anywhere. CONFIG_PROFILE (Enable traffic profiling) CONFIG_PROFILE_SHIFT (Profile shift count) Set in arch/cris/config.in, not used anywhere. CONFIG_SERIAL_21285_OLD (Use /dev/ttyS0 device) Set in drivers/char/Config.in, not used anywhere The following patch removes them cleanly: Diffs between last version checked in and current workfile(s): --- arch/cris/config.in 2001/05/22 00:55:28 1.1 +++ arch/cris/config.in 2001/05/22 00:56:22 @@ -20,9 +20,6 @@ bool 'System V IPC' CONFIG_SYSVIPC tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF -if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then - tristate 'Kernel support for JAVA binaries' CONFIG_BINFMT_JAVA -fi bool 'Use kernel gdb debugger' CONFIG_ETRAX_KGDB @@ -232,8 +229,4 @@ comment 'Kernel hacking' #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC -bool 'Kernel profiling support' CONFIG_PROFILE -if [ "$CONFIG_PROFILE" = "y" ]; then - int ' Profile shift count' CONFIG_PROFILE_SHIFT 2 -fi endmenu --- arch/ia64/config.in 2001/05/22 00:51:05 1.1 +++ arch/ia64/config.in 2001/05/22 00:51:26 @@ -89,7 +89,6 @@ if [ "$CONFIG_ACPI_KERNEL_CONFIG" = "y" ]; then define_bool CONFIG_PM y define_bool CONFIG_ACPI y - define_bool CONFIG_ACPI_INTERPRETER y fi fi --- arch/mips64/config.in 2001/05/22 00:50:33 1.1 +++ arch/mips64/config.in 2001/05/22 00:50:44 @@ -183,7 +183,6 @@ fi if [ "$CONFIG_BAGET_MIPS" = "y" ]; then tristate 'Baget AMD LANCE support' CONFIG_BAGETLANCE -tristate 'Baget Backplane Shared Memory support' CONFIG_BAGETBSM fi if [ "$CONFIG_ATM" = "y" ]; then source drivers/atm/Config.in --- arch/parisc/config.in 2001/05/22 00:55:04 1.1 +++ arch/parisc/config.in 2001/05/22 00:55:14 @@ -68,9 +68,6 @@ tristate 'Kernel support for SOM binaries' CONFIG_BINFMT_SOM tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC -if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then - tristate 'Kernel support for JAVA binaries (obsolete)' CONFIG_BINFMT_JAVA -fi endmenu --- drivers/char/Config.in 2001/05/22 00:56:44 1.1 +++ drivers/char/Config.in 2001/05/22 00:56:56 @@ -63,9 +63,6 @@ if [ "$CONFIG_FOOTBRIDGE" = "y" ]; then bool 'DC21285 serial port support' CONFIG_SERIAL_21285 if [ "$CONFIG_SERIAL_21285" = "y" ]; then - if [ "$CONFIG_OBSOLETE" = "y" ]; then - bool ' Use /dev/ttyS0 device (OBSOLETE)' CONFIG_SERIAL_21285_OLD - fi bool ' Console on DC21285 serial port' CONFIG_SERIAL_21285_CONSOLE fi fi --- drivers/scsi/Config.in 2001/05/22 00:55:54 1.1 +++ drivers/scsi/Config.in 2001/05/22 00:56:01 @@ -39,7 +39,6 @@ if [ "$CONFIG_TC" = "y" ]; then dep_tristate 'DEC NCR53C94 Scsi Driver' CONFIG_SCSI_DECNCR $CONFIG_SCSI fi - dep_tristate 'DEC SII Scsi Driver' CONFIG_SCSI_DECSII $CONFIG_SCSI fi if [ "$CONFIG_PCI" = "y" ]; then End of diffs. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Hoplophobia (n.): The irrational fear of weapons, correctly described by Freud as "a sign of emotional and sexual immaturity". Hoplophobia, like homophobia, is a displacement symptom; hoplophobes fear their own "forbidden" feelings and urges to commit violence. This would be harmless, except that they project these feelings onto others. The sequelae of this neurosis include irrational and dangerous behaviors such as passing "gun-control" laws and trashing the Constitution. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Mon, May 21, 2001 at 10:53:39AM -0700, Richard Henderson wrote: > should probably just go ahead and allocate the 512M or 1G > scatter-gather arena. I just have a bugreport in my mailbox about pci_map faliures even after I enlarged to window to 1G argghh (at first it looked apparently stable by growing the window), so I'm stuck again, it seems I was right in not being careless about the pci_map_* bugs today even if the 1G window looked to offer a rasonable marging at first. The pci_map_* failed triggers during a benchmark with a certain driver that does massive DMA (similar to the examples I did previously), the developers of the driver simply told me the hardware wants to do massive zerocopy dma to userspace and they apparently excluded it could be a memleak in the driver missing some pci_unmap_* after I told them to check for that. Even enabling HIGHMEM would not be enough because they do dma on userspace but on the network side, so it won't be taken care by create_bounces(), so I at least would need to put another bounce buffer layer in the driver to make highmem to work. Other more efficient ways to go besides highmem plus additional bounce buffer layer are: 2) fixing all buggy drivers now (would be a great pain as it seems to me I should do that alone apparently as it seems everybody else doesn't care about those bugs for 2.4) 3) let the "massing DMA" hardware to use DAC Theoritically I could also cheat again and take a way 4) that is to try to enlarge the window beyond 1G and see if the bugs gets hided also during the benchmark that way, but I would take this as last resort as this would again not be a definitive solution and I'd risk to get stuck again tomorrow like I'm right now. I think I will prefer to take a dirty way 3) just for those drivers to solve this production problem even if it won't be implemented in a generic manner at first (I got the idea from the quadrics folks that do this just now with their nics if I understood well). If I understand correctly on the tsunami enabling DAC simply means to enable the pchip->pctl |= MWIN (monster window) bit during the boot stage on both pchip. Then the device driver of the "massive DMA" hardware should simply program the registers of the nic to do use DAC with bus addresses that are the phys address of the destination/source memory of the DMA, only changed to have bit 40th set to 1. Those should be all the needed changes necessary to make pci64 to work on tsunami at the same time of pci32 direct/dynamic windows and it would be very efficient and it sounds the best way to workaround the broken pci_map_* in 2.4 given fixing the pci_map_* the right way is a pain. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Tue, May 22, 2001 at 02:22:34AM +0200, Ingo Oeser wrote: > ioctl has actually 4 semantics: > > command only > command + read > command + write > command + rw-transaction > > Separating these would be a first step. And yes, I consider each > of them useful. > > command only: reset drive echo 'reset' >/dev/sg0ctl > command + rw-transaction: "dear device please mangle this data" >(crypto processors come to mind...) I can't think of a reasonable tool-based approach to this, but I can definitely see that a program could use this well. It simply requires that you use the filp to store your state. fd = open(/dev/crypto) -> creates filp write(fd, "Death to all fanatics!\n"); -> calls crypto device, stores result in private data structure sleep(100); read(fd, "Qrngu gb nyy snangvpf!\n"); -> frees data structure [You'll note the advanced design of my crypto processor.] Clearly, this is open to abuse by persons never calling read() and passing in far too much to write(). I think this can be alleviated by refusing to accept more than (say) 4k at a time, or bean-counter. A sick way would be to allow the ->write() call to have its buffer modified. But I don't think we want to go down that path. -- Revolutions do not require corporate support. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, May 21, 2001 at 06:13:18PM -0700, Linus Torvalds wrote: > Nope. You can (and people do, quite often) share filps. So you can't > associate state with it. For _devices_, though? I don't expect my mouse to work if gpm and xfree both try to consume device events from the same filp. Heck, it doesn't even work when they try to consume events from the same inode :-) I think this is a reasonable restriction for the class of devices in question. -- Revolutions do not require corporate support. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Tue, 22 May 2001, Matthew Wilcox wrote: > > > command + rw-transaction: "dear device please mangle this data" > >(crypto processors come to mind...) > > I can't think of a reasonable tool-based approach to this, but I can > definitely see that a program could use this well. It simply requires > that you use the filp to store your state. Nope. You can (and people do, quite often) share filps. So you can't associate state with it. 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/
Just FYI...
vger.kernel.org is now ECN enabled. Later, David S. Miller [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: Background to the argument about CML2 design philosophy
On Mon, 21 May 2001 16:38:34 -0400,
John Stoffel <[EMAIL PROTECTED]> wrote:
>All that CML2 does is enforce dependencies in the configuration
>language. You can't make a .config which conflicts. Admittedly
>there's nothing stopping you from hacking it with vi after the fact,
>but why?
CML2 will not stop you hacking .config by hand. But the 2.5 makefile
rewrite will, because we have had too many bug reports caused by people
who hand edited .config, did not revalidate it and generated invalid
kernels. Yes, you can hand edit .config. No, you cannot compile until
.config has been (re-)validated.
# Not a real dependency, this checks for hand editing of .config.
$(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
@echo Your .config is newer than include/linux/autoconf.h, this should not
happen.
@echo Always run make one of "{menu,old,x}config" after manually updating
.config.
@/bin/false
And before people complain: Don't create a config that violates the CML
rules, correct the CML rules, the Makefiles and the source so .config
is valid. The kernel build requires a valid .config.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Bug-fix for Maestro dock/hardware volume control patch
This patch, to be applied on top of the patch sent to linux-kernel last week, fixes a bug which caused the driver to crash on insertion if a hardware volume button had been pushed. --- linux-2.4.4-ac12.vanilla/drivers/sound/maestro.cMon May 21 19:18:49 2001 +++ linux-2.4.5pre1/drivers/sound/maestro.c Mon May 21 18:27:39 2001 @@ -3226,7 +3359,7 @@ outw(w, iobase+0x18); w=inw(iobase+0x18); - w|=1<<6;/* Hardware volume control interrupt on. */ + w&=~(1<<6); /* Hardware volume control interrupt off... for now. */ outw(w, iobase+0x18); w=inw(iobase+0x18); @@ -3549,6 +3680,15 @@ kfree(card); return 0; } + + /* Turn on hardware volume control interrupt. + This has to come after we grab the IRQ above, + or a crash will result on installation if a button has been pressed, + because in that case we'll get an immediate interrupt. */ + n = inw(iobase+0x18); + n|=(1<<6); + outw(n, iobase+0x18); + /* now go to sleep 'till something interesting happens */ maestro_power(card,ACPI_D2); -- Ben Pfaff <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> MSU Student - Debian GNU/Linux Maintainer - GNU Developer Personal webpage: http://www.msu.edu/user/pfaffben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] drivers/media/video/zr36120.c
Hello!
I'm Philip, from Professor Dawson Engler's Meta-Compilation Group at
Stanford University.
There is a bug in zr36120.c of not freeing memory on error paths. This one
is particularly dangerous, because kmalloc allocates a memory block the
size of a memory clip! I simply free the local pointer, vcp, before
returning -EFAULT.
Warmly,
Philip
linux/2.4.4/drivers/media/video/zr36120.c Fri Mar 2 11:12:10 2001
+++ zr36120.c Mon May 21 13:26:17 2001
@@ -1195,8 +1195,10 @@
if (vcp==NULL)
return -ENOMEM;
if (vw.clipcount &&
copy_from_user(vcp,vw.clips,sizeof(struct video_clip)*vw.clipcount))
- return -EFAULT;
-
+ {
+ vfree(vcp);
+ return -EFAULT;
+ }
on = ztv->running;
if (on)
zoran_cap(ztv, 0);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
>If you run into a case where you have a config which would work, but >CML2 doesn't let you, why don't you fix the grammar instead of saying >CML2 is wrong? Let's not confuse these two issues as well. Strongly agree. Especially since I'm pushing for an explicit recognition of the difference between a hard dependancy and a soft derivation. The latter can be over-ridden safely by someone who knows what he's after. The former will cause a miscompile. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: tmpfs + sendfile bug ?
On 21-May-2001 David Schwartz wrote: > >> Any idea ? > > Looks like a bug in the program. If 'sendfile' returns 'EINVAL', that means > you can't use 'sendfile' to send this particular file, and should default to > read/write or mmap/write. If this program doesn't, it doesn't understand > Linux's 'sendfile' semantics. Agreed, I came up to the same conclusion. Applications shouldn't assume that sendfile will always work, and be ready to fall back to the traditional DIY way of sending data. I just downloaded more recent sources of proftpd (1.2.2rc2), and it looks fixed, already... Time to upgrade :) Regards, Pierre. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
HUGE contiguous mem space with 2.4
Hi... I am facing an odd problem here. I have an application here that requires a HUGE physically contiguous memory area to be locked (yes, I have hardware DMA'ing in and out of that area, over the PCI bus). HUGE being like one Gig (could be more if needed...) I am trying to use the mem=1024M option at boot time (yes, the box has 2 Gigs of RAM) and then ioremap() from within my module. There I have a couple of issues: - if I use high_memory as is, I cannot remap any area (high_memory=f800: ???) - if I use high_memory thru virt_to_phys, I can then remap... up to 64 Megs (maybe a little more, but for sure less than 128 Megs) (virt_to_phys(high_mem)=3800:) I tried with other values (like mem=250M 512M 1536M) and could NOT remap anything close to the whole amount of "reserved" memory (best case being with mem=256M I can remap 512M out of 1.75Gigs) I guess I am missing a point somewhere or have totally been "ignoring" some doc somewhere (alessandro could be the man for this one thing *-) ) [system is a dual P3 with 2 gigs of RAM, a 2.4.3 kernel with SMP turned on... and the nice option for 4Gigs of RAM... would the 64Gig option help me??? just wondering there...] Any pointer, advise, help, hint... laugh at the stupid thing I have forgotten is more than welcome.. tia Chris. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question: permission checking for network filesystem
> Agree, but it will improve behavior. Or speed, rather. Otherwise open would > take 3(!) roundtrips (instead of two - now lookup can't be get rid of) - > lookup, permission and open. The protocol can do all three in one request. > The problem is I can't tell the 3 calls from VFS belong together. You can write lookup so that it always succeeds and returns dummy inode without sending anything and do all the work in open & inode operations. > > > Could anyone see a solution other than adding a flags to open mode (say > > > O_EXEC and O_EXEC_LIB), that would be added to the dentry_open in open_exec > > > and sys_uselib? I don't like the idea of pathing vfs for this. > > > > Send always 'open for read' and ignore 'open for execute'. > > Won't work for many reasons. Correct error code is one (could be removed by > pre-checking permission), > exclusivity of write versus execute is the other > (can't be workaround). MAP_DENYWRITE is used for this. If somebody is mapping file with MAP_DENYWRITE, lock it on server. Write locking does not depend on exec, and it is bad to expect that it may be used only in exec. Mikulas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
debugging xterm.
I'm trying to debug xterm and it seems like it is just not my day (I suppose the "Abandon All Hope, Ye Who Enter Here" in the README for xterm is for a reason there after all :P ) I running gdb on xterm. I'm running it as root, the current execution is at main.c:main() and gdb seems to get lost when calling getuid), any idea? Is there something special about getuid() I'm missing? (gdb) next 1612uid_t ruid = getuid(); 2: screen->respond = 1448543468 1: screen = (TScreen *) 0x4000ae60 (gdb) next 1613gid_t rgid = getgid(); 2: screen->respond = Cannot access memory at address 0x4 Disabling display 2 to avoid infinite recursion. (gdb) it does not know where screen data structure is anymore.. -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SMC-IRCC broken? 2.4.5-pre4 / -ac5+
Good afternoon! Between pre3 and 4 (also somewhere in the middle of the -ac series) the smc-ircc and/or irda subsystem went broken (at least for me). The kernel stops while booting at: TCP: Hash tables configured (established 16384 bind 16384) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. SMC IrDA Controller found; IrCC version 2.0, port 0x118, dma=3, irq=3 The next message shuld be (in 2.4.4): IrDA: Registered device irda0 It looks like it's some kind of loop, because the CPU fan starts running at full speed. This is on a Fujitsu-Siemens Lifebook S-4546 grep ^CONFIG_ .config | remove unimpotant lines: CONFIG_IRDA=y CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m CONFIG_IRTTY_SIR=m CONFIG_IRPORT_SIR=m CONFIG_SMC_IRCC_FIR=y gcc: (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81)) More info? just ask! ps. I'm not on the list so please cc. Regards Pawel Worach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.4-ac11 initrd image load from floppy hang keyboard
Hi I tried 2.4.4-ac11, plain kernel for booting custom installer, and loading an initrd image from a secondary floppydisk, using syslinux 1.62 to boot the kernel. These parameters were used: ramdisk_start=0 load_ramdisk=1 prompt_ramdisk=1 ramdisk_size=12288 root=/dev/fd/0 This resulted in hanged keyboard, no response. But screenblanking obviously worked as the screen blacked out after some time. But the keyboard no response, not even Ctrl + Alt + Del worked. The same kernel configuration on vanilla 2.4.4 worked fine. So... something is terribly wrong here. -- Tryggve ___ Get your free @pakistanmail.com email address http://pakistanmail.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: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, 21 May 2001, Linus Torvalds wrote:
> It shouldn't be impossible to do the same thing to ioctl numbers. Nastier,
> yes. No question about it. But we don't necessarily have to redesign the
> whole approach - we only want to re-design the internal kernel interfaces.
>
> That, in turn, might be as simple as changing the ioctl incoming arguments
> of into a structure like .
drivers/net/ppp_generic.c:
ppp_set_compress(struct ppp *ppp, unsigned long arg)
{
int err;
struct compressor *cp;
struct ppp_option_data data;
void *state;
unsigned char ccp_option[CCP_MAX_OPTION_LENGTH];
#ifdef CONFIG_KMOD
char modname[32];
#endif
err = -EFAULT;
if (copy_from_user(&data, (void *) arg, sizeof(data))
|| (data.length <= CCP_MAX_OPTION_LENGTH
&& copy_from_user(ccp_option, data.ptr, data.length)))
goto out;
And that's far from being uncommon. They _do_ follow pointers. Some - more
than once.
We _will_ have to support ioctls for long. No questions about that. And
there is no magic trick that would work for all of them, simply because
many are too disgusting to be left alive. Let's clean the groups that can
be cleaned and see what's left.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Mon, May 21 2001, Andi Kleen wrote: > On Mon, May 21, 2001 at 03:00:24AM -0700, David S. Miller wrote: > > > That's currently the case, but at least on IA32 the block layer > > > must be fixed soon because it's a serious performance problem in > > > some cases (and fixing it is not very hard). > > > > If such a far reaching change goes into 2.4.x, I would probably > > begin looking at enhancing the PCI dma interfaces as needed ;-) > > Hmm, I don't think it'll be a far reaching change. As far as I can see > all it needs is a new entry point for block device drivers that uses > bh->b_page. When that entry point exists skip the create_bounce call > in __make_request. After that it is purely problem for selected drivers. I've already done it, however not as a 2.4 solution. The partial and WIP patches is here: *.kernel.org/pub/linux/kernel/people/axboe/v2.5/bio-7 Block driver can indicate the need for bounce buffers above a certain page. Of course I can hack up something for 2.4 as well, but is this really a pressing need? -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, 21 May 2001, Alan Cox wrote: > > > Sure. But we have to do two syscalls only if ioctl has both in- and out- > > arguments that way. Moreover, we are talking about non-trivial in- arguments. > > How many of these are in hotspots? > > There is also a second question. How do you ensure the read is for the right > data when you are sharing a file handle with another thread.. > > ioctl() has the nice property that an in/out ioctl is implicitly synchronized I don't think we can generically replace ioctl's with read-write, and we shouldn't bend over backwards even _trying_. The important thing would be to give them more structure, and as far as I'm personally concerned I don't even care if the user-level access method ends up being the same old thing. After all, we have magic numbers everywhere: even a system call uses magic numbers for the syscall entry numbering. The thing that makes system call numbers nice is that the number gets turned into a more structured thing with proper type checking and well-defined semantics very very early on indeed. It shouldn't be impossible to do the same thing to ioctl numbers. Nastier, yes. No question about it. But we don't necessarily have to redesign the whole approach - we only want to re-design the internal kernel interfaces. That, in turn, might be as simple as changing the ioctl incoming arguments of into a structure like . 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: tmpfs + sendfile bug ?
In article <[EMAIL PROTECTED]>, Christoph Rohland <[EMAIL PROTECTED]> wrote:
>
>tmpfs does not provide the necessary functions for sendfile and lo:
>readpage, prepare_write and commitwrite.
>
>And I do not see a way how to provide readpage in tmpfs :-(
Why not just do it the same way ramfs does?
If you don't have any backing store, you know that the page is empty. If
you _do_ have backing store, a readpage() won't be called. Ergo:
static int ramfs_readpage(struct file *file, struct page * page)
{
if (!Page_Uptodate(page)) {
memset(kmap(page), 0, PAGE_CACHE_SIZE);
kunmap(page);
flush_dcache_page(page);
SetPageUptodate(page);
}
UnlockPage(page);
return 0;
}
while the writepage ones just do a "SetPageDirty(page)" (with
prepare_write() needing to do the same "Page_Uptodate()" checks to see
if we need to clear stuff first).
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: [RFD w/info-PATCH] device arguments from lookup, partion code
> Sure. But we have to do two syscalls only if ioctl has both in- and out- > arguments that way. Moreover, we are talking about non-trivial in- arguments. > How many of these are in hotspots? There is also a second question. How do you ensure the read is for the right data when you are sharing a file handle with another thread.. ioctl() has the nice property that an in/out ioctl is implicitly synchronized - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.2.19+ide: corrupts ide tape output
On 21 May 2001 14:49:55 -0400, Camm Maguire <[EMAIL PROTECTED]> wrote:
>Greetings! 2.2.19+ide, applied the patch because this box has a new
>Promise PDC20267 ide controller. 14GB HP Colorado tape drive. Before
>we installed the new ide controller and patched the kernel, i.e. with
>unpatched 2.2.19 running on a different ide controller, this setup
>works just fine. Now I get the following occasionally, which results
>in corrupted dumps to tape:
>
>May 21 10:27:47 intech9 kernel: hdh: status error: status=0x40 { DriveReady }
>May 21 10:27:47 intech9 kernel: ide-scsi: Strange, packet command initiated yet DRQ
>isn't asserted
You added a Promise Ultra100 PCI card, right?
>From what I hear, it doesn't support ATAPI devices well, only disks.
So if you moved the HP tape drive to the PDC, move it back to
the mainboard's IDE controller.
Also, don't disable the mainboard's controller thinking you can save
some interrupts that way. Andre Hedrick (Linux IDE guy) once wrote
that this could cause the PDC to grab IRQ 14, which had some nasty
side-effects.
(My main box runs with disks on a Promise Ultra100 card and
ATAPI CD-RW and tape on the mainboard's IDE (440BX) controller.
Both 2.2+ide and 2.4 work fine.)
/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: New iSeries Device Drivers
Hi All, Enclosed you will find for your consideration a set of new device drivers for iSeries boxes. This submission is against 2.4.4. Additionally in the background there is also a submission which has been made to the ppc maintainers for the set of changes to arch/ppc and include/asm-ppc to enable iSeries boxes to run Linux. Those should bubble up soon. The new device drivers are for: virtual console virtual harddrive virtual ethernet virtual tape virtual cd These device drivers will also be used in the up coming ppc64 architecture. Rather than spamming the list with ~6800 lines of driver code, you can obtain it via http://www.ibm.com/linux/ltc/projects/ppc/patches/patch-lpar-dev.gz or via ftp.kernel.org/pub/linux/kernel/people/tgall/patch-lpar-dev.gz Background: iSeries boxes are otherwise known as IBM's AS/400, a midrange business computer. Linux runs on these machines in a logical partition, so akin to how the S390 runs Linux, iSeries allows you to have multiple Linux boxes running side by side on the same machine. Since multiple linux boxes must share physical resources, these virtual drivers were developed. The virtual ethernet goes a step beyond and allows you to setup your own high speed lan "inside" of the box without consuming physical resources. Also see http://www.ibm.com/linux/ltc/projects/ppc/iSeries_notes.php or http://www.ibm.com/servers/eserver/iseries/linux/ for more information. Regards, Tom -- Tom Gall - PPC64 "Where's the ka-boom? There was Linux Technology Center supposed to be an earth (w) [EMAIL PROTECTED] shattering ka-boom!" (w) 507-253-4558 -- Marvin Martian (h) [EMAIL PROTECTED] http://www.ibm.com/linux/ltc/projects/ppc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT]: Multicasting
I know this is off topic. I am not sure where else to go. All of my google searches lead me to very dead and very old information on multicasting. I am sure most of it is not useful, though some of the basics are. If people have a problem answering on list, please answer off. My questions: What protocols and session management (besides IGMP) does the kernel support (say, does it support source specific multicasting?)? Are the old how tos on multicast programming still the only things I need to worry about? If there are only X groups (in the few thousand if IRC), does the protocl allow only forwarding Y port on X group to the end person, or do they get the entire group? Anyone know of good books for Linux/Unix multicast programming? Trever Adams P.S. I am sure I have left out 1 million and 1 valuable questions that I need/want answers to, please feel free to add in what you think might be good for me to know. P.P.S. Sorry if this got here twice, I didn't see a copy returned to me last week through the list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT]: Multicasting
I know this is off topic. I am not sure where else to go. All of my google searches lead me to very dead and very old information on multicasting. I am sure most of it is not useful, though some of the basics are. If people have a problem answering on list, please answer off. My questions: What protocols and session management (besides IGMP) does the kernel support (say, does it support source specific multicasting?)? Are the old how tos on multicast programming still the only things I need to worry about? If there are only X groups (in the few thousand if IRC), does the protocl allow only forwarding Y port on X group to the end person, or do they get the entire group? Anyone know of good books for Linux/Unix multicast programming? Trever Adams P.S. I am sure I have left out 1 million and 1 valuable questions that I need/want answers to, please feel free to add in what you think might be good for me to know. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac12
On 05.21 Alan Cox wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
>
>Intermediate diffs are available from
> http://www.bzimage.org
>
>
> 2.4.4-ac12
> o Just tracking Linus 2.4.5pre4
> - A chunk more merged with Linus
> - dropped out some oddments that are now
> obsolete
>
Two buglets:
- missing version bump from ac11 to ac12...
- missing change in binfmt_misc.c from lookup_one to lookup_one_len
(is this the correct fix ? len is not already on Node...)
--- linux-2.4.4-ac12/fs/binfmt_misc.c.orig Mon May 21 23:22:29 2001
+++ linux-2.4.4-ac12/fs/binfmt_misc.c Mon May 21 23:24:53 2001
@@ -501,7 +501,7 @@
root = dget(sb->s_root);
down(&root->d_inode->i_sem);
- dentry = lookup_one(e->name, root);
+ dentry = lookup_one_len(e->name, root, strlen(e->name));
err = PTR_ERR(dentry);
if (!IS_ERR(dentry)) {
down(&root->d_inode->i_zombie);
--
J.A. Magallon # Let the source be with you...
mailto:[EMAIL PROTECTED]
Linux Mandrake release 8.1 (Cooker) for i586
Linux werewolf 2.4.4-ac11 #2 SMP Fri May 18 12:27:06 CEST 2001 i686
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
> Which, BTW, is a wonderful reason for having multiple channels. Instead > of write(fd, "critical_command", 8); read(fd,); you read from the right fd. > Opened before you enter the hotspot. Less overhead than ioctl() would > have... The ioctl is one syscall, the read/write pair are two. Im not sure that ioctl is going to be more overhead there. In the video4linux case the high overhead is acking frames received by mmap so might conceivably be considered one way - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: maestro ported to 2.4 PCI API
> > @@ -3406,7 +3429,7 @@
> > if(card == NULL)
> > {
> > printk(KERN_WARNING "maestro: out of memory\n");
> > - return 0;
> > + return -ENOMEM;
>
> request_region is unbalanced in this return path.
Thanks!
Fixed patch below.
Ciao, Marcus
Index: drivers/sound/maestro.c
===
RCS file: /build/mm/work/repository/linux-mm/drivers/sound/maestro.c,v
retrieving revision 1.7
diff -u -r1.7 maestro.c
--- drivers/sound/maestro.c 2001/05/18 08:06:38 1.7
+++ drivers/sound/maestro.c 2001/05/21 21:06:55
@@ -115,6 +115,10 @@
* themselves, but we'll see.
*
* History
+ * v0.15 - May 21 2001 - Marcus Meissner <[EMAIL PROTECTED]>
+ * Ported to Linux 2.4 PCI API. Some clean ups, global devs list
+ * removed (now using pci device driver data).
+ * PM needs to be polished still. Bumped version.
* (still kind of v0.14) May 13 2001 - Ben Pfaff <[EMAIL PROTECTED]>
* Add support for 978 docking and basic hardware volume control
* (still kind of v0.14) Nov 23 - Alan Cox <[EMAIL PROTECTED]>
@@ -206,28 +210,6 @@
#include
#include
#include
-
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,0)
-
- #define DECLARE_WAITQUEUE(QUEUE,INIT) struct wait_queue QUEUE = {INIT, NULL}
- #define wait_queue_head_t struct wait_queue *
- #define SILLY_PCI_BASE_ADDRESS(PCIDEV) (PCIDEV->base_address[0] &
PCI_BASE_ADDRESS_IO_MASK)
- #define SILLY_INIT_SEM(SEM) SEM=MUTEX;
- #define init_waitqueue_head init_waitqueue
- #define SILLY_MAKE_INIT(FUNC) __initfunc(FUNC)
- #define SILLY_OFFSET(VMA) ((VMA)->vm_offset)
-
-
-#else
-
- #define SILLY_PCI_BASE_ADDRESS(PCIDEV) (PCIDEV->resource[0].start)
- #define SILLY_INIT_SEM(SEM) init_MUTEX(&SEM)
- #define SILLY_MAKE_INIT(FUNC) __init FUNC
- #define SILLY_OFFSET(VMA) ((VMA)->vm_pgoff)
-
-
-#endif
-
#include
#include
#include
@@ -251,6 +233,8 @@
#include "maestro.h"
+static struct pci_driver maestro_pci_driver;
+
/* - */
#define M_DEBUG 1
@@ -271,8 +255,17 @@
static int clocking=48000;
+MODULE_AUTHOR("Zach Brown <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("ESS Maestro Driver");
+#ifdef M_DEBUG
+MODULE_PARM(debug,"i");
+#endif
+MODULE_PARM(dsps_order,"i");
+MODULE_PARM(use_pm,"i");
+MODULE_PARM(clocking, "i");
+
/* - */
-#define DRIVER_VERSION "0.14"
+#define DRIVER_VERSION "0.15"
#ifndef PCI_VENDOR_ESS
#define PCI_VENDOR_ESS 0x125D
@@ -354,6 +347,11 @@
[ACPI_D3] = ACPI_NONE
};
+static char version[] __devinitdata =
+KERN_INFO "maestro: version " DRIVER_VERSION " time " __TIME__ " " __DATE__ "\n";
+
+
+
static const unsigned sample_size[] = { 1, 2, 2, 4 };
static const unsigned sample_shift[] = { 0, 1, 1, 2 };
@@ -522,8 +520,6 @@
static void check_suspend(struct ess_card *card);
-static struct ess_card *devs = NULL;
-
/* - */
@@ -2133,17 +2129,25 @@
}
/* - */
-
static int ess_open_mixdev(struct inode *inode, struct file *file)
{
int minor = MINOR(inode->i_rdev);
- struct ess_card *card = devs;
-
- while (card && card->dev_mixer != minor)
- card = card->next;
+ struct ess_card *card = NULL;
+ struct pci_dev *pdev;
+ struct pci_driver *drvr;
+
+ pci_for_each_dev(pdev) {
+ drvr = pci_dev_driver (pdev);
+ if (drvr == &maestro_pci_driver) {
+ card = (struct ess_card*)pci_get_drvdata (pdev);
+ if (!card)
+ continue;
+ if (card->dev_mixer == minor)
+ break;
+ }
+ }
if (!card)
return -ENODEV;
-
file->private_data = card;
return 0;
}
@@ -2505,7 +2509,7 @@
#endif
goto out;
ret = -EINVAL;
- if (SILLY_OFFSET(vma) != 0)
+ if (vma->vm_pgoff != 0)
goto out;
size = vma->vm_end - vma->vm_start;
if (size > (PAGE_SIZE << db->buforder))
@@ -2969,33 +2973,40 @@
ess_open(struct inode *inode, struct file *file)
{
int minor = MINOR(inode->i_rdev);
- struct ess_card *c = devs;
- struct ess_state *s = NULL, *sp;
- int i;
+ struct ess_state *s = NULL;
unsigned char fmtm = ~0, fmts = 0;
-
+ struct pci_dev *pdev;
/*
* Scan the cards and find the channel. We only
* do this at open time so it is ok
*/
-
- while (c!=NULL)
- {
- for(i=0;ichannels[i];
- if(sp->dev_audio < 0)
- continue;
-
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, 21 May 2001, Alan Cox wrote: > > > I don't need to read it. Don't be insulting. Sure, you *can* use a > > > write(2)/read(2) cycle. But that's two syscalls compared to one with > > > ioctl(2) or transaction(2). That can matter to some applications. > > > > I just don't think so. Where did you see performance-critical use of > > ioctl()? > > AGP, video4linux,... Which, BTW, is a wonderful reason for having multiple channels. Instead of write(fd, "critical_command", 8); read(fd,); you read from the right fd. Opened before you enter the hotspot. Less overhead than ioctl() would have... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
David> Actually, the current system has both types. As well as the David> "hard" dependencies, we also have stuff like David> CONFIG_PARTITION_ADVANCED, CONFIG_CPU_ADVANCED, David> CONFIG_FBCON_ADVANCED, CONFIG_MTD_DOCPROBE_ADVANCED, David> etc. CONFIG_EXPERIMENTAL serves a very similar purpose, too. David> These things have already been set up in the way that David> developers prefer it. *some* developers prefer it. Not all. David> CML2 allows us to be more flexible than we were before, and David> that can be a good thing when used in moderation. But please, David> for the sake of the sanity of all concerned, do things one at a David> time. Provide for merging into 2.5 a set of rules which David> reproduce the existing CML1 behaviour in this respect. Can you define what you mean here? It's not really clear to me, and I suspect others. David> Eric, if you want to make further changes later to introduce David> new 'modes' for kernel configuration, that's an entirely David> separate issue. Please don't confuse the issue by trying to do David> it at the same time as introducing CML2. I don't think he is introducing new modes, he's just trying to make sure that you can't create a .config which is broken. Part of my complaint early on was that it would just barf on a config it thought wasn't legall, and just drop me to the 'vi' level. I don't think this is acceptable because you (CML2 or CML) should be able to prompt the user for a suggested fix. David> CONFIG_AUNT_TILLIE does not require CML2. Correct. David> CML2 does not require CONFIG_AUNT_TILLIE. Correct. And never has offered it either! David> Let's not talk about CONFIG_AUNT_TILLIE any more, or change the David> existing behaviour of config options to make that the default, David> until we've settled the discussion about CML2. I think it comes down to people who just want one or more of: - the existing interface of vi .config; make oldconfig - fear that CML2 won't let them make crazy configurations, such as an 8-way SMP box with ISA. Can't see how CML2 would restrict this choice myself. - Don't want to install python 2.x for a kernel upgrade. - fear that some configuration corner case will be handled wrong for a strange (read not common) system config. All that CML2 does is enforce dependencies in the configuration language. You can't make a .config which conflicts. Admittedly there's nothing stopping you from hacking it with vi after the fact, but why? If you run into a case where you have a config which would work, but CML2 doesn't let you, why don't you fix the grammar instead of saying CML2 is wrong? Let's not confuse these two issues as well. John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Re: Linux 2.4.4-ac10
On Sun, May 20, 2001 at 11:54:09PM +0200, Pavel Machek wrote: > Hi! > > > > You're right. It should never dump too much data at once. OTOH, if > > > those cleaned pages are really old (front of reclaim list), there's no > > > value in keeping them either. Maybe there should be a slow bleed for > > > mostly idle or lightly loaded conditions. > > > > If you don't think it's worthwhile keeping the oldest pages > > in memory around, please hand me your excess DIMMS ;) > > Sorry, Rik, you can't have that that DIMM. You know, you are > developing memory managment, and we can't have you having too much > memory available ;-). IMVHO every developer involved in memory-management (and indeed, any software development; the authors of ntpd comes in mind here) should have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's still a pain to work with. /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: maestro ported to 2.4 PCI API
> Its useful to have version ids. So it would be better people used them more I wasn't sure, so am happy leaving them in as well :) I suppose they're an easier way to sync dmesg with code version than knowing what is in which kernel version. -- zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
> > I don't need to read it. Don't be insulting. Sure, you *can* use a > > write(2)/read(2) cycle. But that's two syscalls compared to one with > > ioctl(2) or transaction(2). That can matter to some applications. > > I just don't think so. Where did you see performance-critical use of > ioctl()? AGP, video4linux,... Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Compile fails an Alpha: include/asm/pci.h included from arch/alpha/kernel/setup.c
On Mon, May 21, 2001 at 05:18:55PM +0200, Jan-Benedict Glaw wrote: > > Kernel 2.4.5-pre[34] don't compile on Alpha: > > 152 struct pci_controller *hose = pdev->sysdata; ^^^ This is the problem (a type for 'pdev' is not defined). And this is a possible fix: --- linux-2.4.4ac/include/asm-alpha/pci.h~ Sat May 19 16:43:11 2001 +++ linux-2.4.4ac/include/asm-alpha/pci.h Sat May 19 17:23:56 2001 @@ -6,6 +6,7 @@ #include #include #include +#include /* * The following structure is used to manage multiple PCI busses. The patch is for 2.4.4-ac11, so offsets are possibly slightly different, but probably not. :-) Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Hi! > Yes, and that is exactly the difference between having a side effect > on the open(2), versus having the effect as a result of a write(2). > > Unfortunately, there are already some cases where an open > on a device can have unexpected results. If you don't want > to get blocked waiting for the carrier-detect signal from the > modem when opening a tty device, you had better specify the > O_NONBLOCK option on the open. If you don't want this flag > to be active during the actual I/O operations, then you would > have to do an fcntl to clear the O_NONBLOCK again after the open. > > So I guess things have already been a bit messy in this > area for many years, even before linux even existed, and > in some cases you can't really do anything about it because > the behaviour is mandated by the applicable standards, like > POSIX, SUS, or whatever. > (The blocking of the open on a tty device is explicitly > documented in my copy of the X/Open specification.) > > Fortunately, blocking the nightly backup program by making it > accidentally open a tty is not quite as catastrophic as having > it start a nuclear war, or format the disks, or something, > just because a user was playing games with symlinks. Maybe not *as* catastrophic, but security hole, anyway. User should not be able to block system backups. Small demonstration for bugtraq, anyone? Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [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][PATCH] Re: Linux 2.4.4-ac10
Hi! > > You're right. It should never dump too much data at once. OTOH, if > > those cleaned pages are really old (front of reclaim list), there's no > > value in keeping them either. Maybe there should be a slow bleed for > > mostly idle or lightly loaded conditions. > > If you don't think it's worthwhile keeping the oldest pages > in memory around, please hand me your excess DIMMS ;) Sorry, Rik, you can't have that that DIMM. You know, you are developing memory managment, and we can't have you having too much memory available ;-). Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [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: [RFD w/info-PATCH] device arguments from lookup, partion code
Hi! > > > The transaction(2) syscall can be just as easily abused as ioctl(2) in > > > this respect. People can pass pointers to ill-designed structures very > > > > Right. Moreover, it's not needed. The same functionality can be > > trivially implemented by write() and read(). As the matter of fact, > > had been done in userland context for decades. Go and buy > > Stevens. Read it. Then come back. > > I don't need to read it. Don't be insulting. Sure, you *can* use a > write(2)/read(2) cycle. But that's two syscalls compared to one with > ioctl(2) or transaction(2). That can matter to some applications. I just don't think so. Where did you see performance-critical use of ioctl()? Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [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: BUG ? and questions
On Sun, May 20, 2001 at 08:09:45AM -0700, szonyi calin wrote: > I have a Cx 486/66 with 12 Megs of ram AST computer > gcc 2.95.3, glibc 2.1.3, make 3.79.1 binutils 2.11 ?? > Problems: > 1. When I try to run multiple (2) compilations on a > 2.4.4 kernel usually one > of them dies -- if it's gcc - signal 11 , if it's sh > or rarely make - > segmentation fault. > > It is not a hardware problem (with kernel 2.2.x it > does not do this > and I have a cooler on my cpu) Are your sure? Check out the SIG11 FAQ at http://www.bitwizard.nl/sig11/ . Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH] device arguments from lookup)
Hi! > A lot of stuff relies on the fact that close(open(foo, O_RDONLY)) is a > no-op. Breaking that assumption is a Bad Thing(tm). Then we have a problem. Just opening /dev/ttyS0 currently *has* side effects (it is visible on modem lines from serial port; it can block you forever). If this assumption is somewhere, we should fix that place... Or fix serial ports. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [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: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Hi! > So I guess things have already been a bit messy in this > area for many years, even before linux even existed, and > in some cases you can't really do anything about it because > the behaviour is mandated by the applicable standards, like > POSIX, SUS, or whatever. > (The blocking of the open on a tty device is explicitly > documented in my copy of the X/Open specification.) If X/Open documents security hole, then, I guess, X/Open will have to be changed. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [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: [RFD w/info-PATCH] device arguments from lookup, partion code
Hi! > > Now that I'm awake and refreshed, yeah, that's awful. But > > echo "hot-add,slot=5,device=/dev/sda" >/dev/md0/control *is* sane. Heck, > > the system can even send back result codes that way. > > Only to an English speaker. I suspect Quebec City canadians would prefer a > different command set. Alan, bad idea. This is less evil than magic numbers, and *users* should not be touching this anyway. They should have nice gui tools that do it for them. English is *way* better than magic numbers. It makes sense at least for someone. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [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: your mail
On Mon, 21 May 2001, Thomas Palm wrote: > there ist still file-corruption. I use an ASUS A7V133 (Revision 1.05, > including Sound + Raid). My tests: > 1st run of "diff -r srcdir destdir" -> no differs > 2nd run of "diff -r srcdir destdir" -> 2 files differ > 3rd run of "diff -r srcdir destdir" -> 1 file differs > 4th run of "diff -r srcdir destdir" -> 1 file differs > 5th run of "diff -r srcdir destdir" -> no differs Could you check WHERE the file differ and WHERE the data come from ? I've got the same mobo AND some nasty DAT tape corruption problems... (also, VERY rarely, on the CD burner). I've got all on SCSI, but if it's the DMA troubling us... -- Lorenzo Marcantonio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CML2 and Python 1.5.x?
I've seen alot of people bitching and moaning about CML2 and mostly it seems to be a need for Python 2.x that is really upsetting people. I don't know the status of the port to C, but I do remember that Eric said he had looked at doing it in Python 1.5 language, but decided against it. Would it make people happier if we could convice (or help) Eric to move back a version in Python? Also, but the time 2.5 (really 2.6) is released and CML2 is the defacto configuration language, don't you all think that Python 2.x will be a standard part of the distros? Hmmm, I've just shot my own arguement in the foot here... dang. As for the others who are complaining about how CML2 will ruin the world, bring a plague of locusts, and "You'll have to pry make menuconfig from my cold, dead hands", have you *tried* CML2 yet? I have, and once I complained enough about what I thought was a mis-feature, Eric did fix it. Moving forward requires some pain and adjustment from time to time, and I can't imagine that all you core kernel people who keep compiling kernels all the time, can't take the time to learn something new. Isn't that our strength, being able to learn? Cheers, John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
On Mon, 21 May 2001, Eric S. Raymond wrote: > the NEW tag). That phase ended almost a month ago. Nobody who has > actually tried the CML2 tools more recently has reported that the UI > changes present any difficulty. What happened with the discussion on configurable colors in make menuconfig? Darkblue on black as frozen options get isn't exactly optimal ... at least not for my eyes. Being next to a bold, white text doesn't help either. > CML2 drops its configuration results in the same place, in the same > formats, as CML1. So you should in fact be able to type `make menuconfig' > and `make oldconfig' with good results. Have you actually tried this? It works for me, but anyone testing this should know that the CML2 tools read "config.out" if it finds one. So people that do things like: make mrproper ; cp ../.config-2.4 .config ; make oldconfig will have to change to copying config.out instead. Doing like this sort of works* if there is no config.out, otherwise it does not (as it uses the config.out). Saying that the config result ends up in the same place and same format is somewhat misleading, you do get a copy in the CML1 output format but the tools doesn't care about that if it can find a file in the new format. *) "Sort of works", since doing like I do will cause you to get a lot of questions that you have already answered. That appears to be a one-time problem as 'oldconfig' does not read "# CONFIG_FOO is not set" as "no". Would be nice if it did. make mrproper doesn't remove config.out. It should since that's what it does with .config* files. Not sure if it should remove the rules.out file also, but I think it should as the idea(?) with mrproper is to clean up anything that is generated. /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: const __init
On 05.21 Richard Henderson wrote: > On Mon, May 21, 2001 at 01:07:50PM +1000, Keith Owens wrote: > > does cause a section conflict, egcs 1.1.2. > > > > Interestingly enough, if var[12] are together, without the intervening > > text, then gcc does not flag an error, instead it puts both variables > > in section .data.init and marks it as read only. This looks like a bug > > in gcc. > > Fixed in compilers newer than 2 years old. > Somebody should officially certify 2.95.2 (or better 2.95.3, if all the kernel related bugs are solved), and change: "The recommended compiler for the kernel is egcs 1.1.2 (gcc 2.91.66), and it should be used when you need absolute stability. You may use gcc 2.95.x instead if you wish, although it may cause problems." -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.4-ac11 #2 SMP Fri May 18 12:27:06 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
[EMAIL PROTECTED] (Linus Torvalds) wrote on 20.05.01 in <[EMAIL PROTECTED]>: > If we had nice infrastructure to make ioctl's more palatable, we could > probably make do even with the current binary-number interfaces, simply > because people would use the infrastructure without ever even _seeing_ how > lacking the user-level accesses are. > > But that absolutely _requires_ that the driver writers should never see > the silly "pass a random number and a random argument type" kind of > interface with no structure or infrastructure in place. Hmm. So would it be worthwile to invent some infrastructure - possibly including macros, possibly even including a (very small) code generator, I don't really have any details clear at this point - that allows you to specify an interface in a sane way (for example, but not necessarily, as a C function definition, though that may be too hard to parse), and have the infrastructure generate 1. some code to call ioctl() with these arguments 2. some other code to pick apart the ioctl buffer and call the actual function with these arguments preferrably so that (a) the code from 1 is suitable for use in libc or similar places, (b) the code from 2 is suitable for the kernel, (c) most (all would be better but may not be practical) existing ioctls could be described that way? (If so, the first task would obviously be to analyze existing code in those places, and the actual structure of existing ioctls, to find out what sort of stuff needs to be supported, before trying to design the mechanism to support it.) A variant possibility (that I suspect you'll like significantly less) would be a data structure to describe the ioctl that gets interpreted at runtime. I think I prefer specific code for that job. At least *some* ioctls are in hot spots, and interpreting is slow. And that hypothetical encapsulation certainly should not know the difference between fast and slow interrupts^Wioctls. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
No Subject
-> moved from comp.os.linux.hardware: Hi, I still have problems with the VIA Apollo southbridge (Kernel 2.4.2 (Redhat 7.1) and Kernel 2.4.4). In rare circumstances, there ist still file-corruption. I use an ASUS A7V133 (Revision 1.05, including Sound + Raid). My tests: - copying 4 GB of CD-ISO-Files from Promise Secondary Master to Promise Secondary Slave. After that "diff -r srcdir destdir". Test was succesfull, no differs, even after 15 executions - (same test with small files) copying 4GB of small files (50 to 500 KB) from Promise Secondary Master to Promise Secondary Slave. 1st run of "diff -r srcdir destdir" -> no differs 2nd run of "diff -r srcdir destdir" -> 2 files differ 3rd run of "diff -r srcdir destdir" -> 1 file differs 4th run of "diff -r srcdir destdir" -> 1 file differs 5th run of "diff -r srcdir destdir" -> no differs - I d did the same tests on the Promise Primary, same results. Also on the the VIA Secondary but my feeling is that there are even more corruptions. I stripped the machine to the bone, PCI-VGA only, same results. I cannot say for sure, but before I stripped my adaptec SCSI-Card, there may even been "differs" after copying from SCSI-Disk to SCSI-Disk. Off course I thought other parts of my Hardware was flacky (e.g. RAM...), but I swapped everything: RAM from different manufacturers, IDE-Cables, CPU (Duron 900 -> Duron 850), VGA-Card, I tried the most conservative Setting in the A7V-Bios, Bios-Update 1003 -> 1004 -> 1004 beta3, UDMA6->UDMA2 all to no avail. Any hints? Post a follow-up to this message Message 2 in thread Von:Bobby D. Bryant ([EMAIL PROTECTED]) Betrifft:Re: VIA Apollo Southbridge again Newsgroups:comp.os.linux.hardware Datum:2001-05-20 09:45:08 PST Thomas Palm wrote: > I still have problems with the VIA Apollo southbridge (Kernel 2.4.2 (Redhat 7.1) and Kernel 2.4.4). There are known to be bugs in the VIA chipsets, but you might want to report this to [EMAIL PROTECTED] anyway. Bobby Bryant Austin, Texas -- Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1! http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.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: Giant disk on 2.2.17: Any concerns?
On Mon, May 21, 2001 at 06:25:39PM +0200, Harald Dunkel wrote: > Do you expect any problems with the partition table? No. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.4-ac12
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org 2.4.4-ac12 o Just tracking Linus 2.4.5pre4 - A chunk more merged with Linus - dropped out some oddments that are now obsolete 2.4.4-ac11 o Fix hang after "Freeing unused.." on S/390 (Dick Hitt) o Fix ramfs accounting bug(Christoph Rohland) o Raw HID access interface for USB(Brad Hards) o Fix missing release_region on QlogicFAS (Marcus Meissner) o Fix missing release region in NCR53c406 code(Marcus Meissner) o Make trident use the new pm callbacks (Pavel Roskin) o Fix dmi ident handling (Arjan van de Ven) o dc2xx locking fixes (Greg Kroah-Hartmann) o Fix overrun on the acm driver (Greg Kroah-Hartmann) o Sitecom workarounds for mct-u232(Stelian Pop) o Makefile fixes (Al Viro) o Make hgafb show logo if non modular only like (me) the rest o Merge back the invalidate_device changes into (me) the new cciss/cpqarray o Rio and sx serial driver updates(Rogier Wolff) o Add another SB AWE 32 variant to the tables (Jeremy Manson) o Fix serial.c warning(Jesper Juhl) o Basic maestro dock support (Ben Pfaff) o Add defines for testing prefetch(Arjan van de Ven) o Protect nls.h from repeat include (Anton Altaparmakov) o Clean up resource handling in esssolo1 (Marcus Meissner) o Fix mysnc on /dev/fb(Andrea Arcangeli) o Further IBM token ring updates (Mike Phillips) o Fix usermode Linux makefile problem (Andrew Morton) o Merge first block of LVM changes(Heinz & others) o Forward port 2.2 syncppp flags features (Paul Fulghum) o Merge lp486e driver for 2.4 (Andries Brouwer) | Experimental... o Merge new cmpci driver (ChenLi Tien) o & remove 2.2 back compat gunge, modem gunge (me) o Update frame buffer project/mailing list data (Geert Uytterhoeven) o Fix m68k bitops (Roman Zippel) o Add w83877f watchdog driver (Scott Jennings) o Merge A2232 serial driver (Enver Haase) o Fix wrong memory free in isdn_ppp (Christopher Kanaan) 2.4.4-ac10 o Move cs46xx docs into the right spot(Arjan van de Ven) o Merge Linus 2.4.5pre3 - switch to Linus page fault race fixes - switch to Linus arch/ppc - merged serial driver cli fixes but also added an extra missing moxa check - used -ac better version of comx fix - used -ac better version of scsi fix - now 2.4.5pre vm seems sane dump other vmscan experiments [not merged; rage-xl code] o 2.4.4-ac9 o Clean up x86isms from the UML code (Chris Emerson) o Remove un-needed UML flag,fix hang under load (Jeff Dike) o Fix attach race in UML (Jeff Dike) o Fix warnings, clean up cpp abuses in UML(Roman Zippel) o Remove -D__KERNEL__ from user space of UML (Roman Zippel) o Add NCR53c700 and 53c700/66 driver (James Bottomley) |For NCR Dual 700 microchannel card o Alpha semaphore updates (Ivan Kokshaysky) p Fix ibmtr build a bit (Andrzej Krzysztofowicz) o Tidy sysrq-t output (Russell King) o Fix miata halt to SRM (Tom Vier) o Fix aging on buffer cache pages (Marcelo Tosatti) o Fix looping behaviour on failing memory (Marcelo Tosatti) allocations o Handle the PIIX4 on the new intel 82801BAM (Tim Raymond) o Fix user visible -ENOIOCTLCMD returns (Shane Wegner) o Fix startech uart detection problem (Val Henson) o Further tulip updates (Jeff Garzik) o Revert hpt366 patch 2.4.4-ac8 o Prefetch constant copy_to_user data (Arjan van de Ven) o Update cpqarray driver - use pci dma api(Charles White) o Update cciss driver - use pci dma api (Charles White) o Enable compiled in synclink driver (Paul Fulghum) o Fix plip section conflict (Keith Owens) o Tulip driver updates(Jeff Garzik) o Frame
Re: Background to the argument about CML2 design philosophy
On 05/21/2001 at 12:58:57 [EMAIL PROTECTED] wrote: >CML2 drops its configuration results in the same place, in the same >formats, as CML1. So you should in fact be able to type `make menuconfig' >and `make oldconfig' with good results. Have you actually tried this? No, I haven't tried it yet. I usually wait for things like this to be included in Linus' or Alan's kernels before trying them. In this case, I might have tried it by now but I only have Python 1.5.2 on my system and don't want to upgrade it until/unless it's absolutely necessary. So I probably won't see CML2 until Linus puts it in 2.5. My comments have been based on your descriptions of it on lkml. Wayne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Mon, 21 May 2001, Alexander Viro wrote:
> On Mon, 21 May 2001, Oliver Xymoron wrote:
>
> > K - so what? I'm guessing what you want me to see is that these
> > implement multiple channels. Is there a reason that eia001stat couldn't be
> > implemented as
> >
> > f=open("/dev/eia001ctl",O_RDWR);
> > write(f,"stat\n");
> > status=read(f); /* returns "stat foo\n" */
>
> Less convenient.
True enough.
> > We don't want to implement a separate device node for every OOB ioctl that
> > returns data, do we? Why should stat be any different?
>
> For every? Probably not. Forcing all of them together? I bet that in many
> cases it will be damn inconvenient. You are forcing the policy on all
> drivers. For no good reason, AFAICS.
No - I'm merely pointing out that it's sufficient. And I'm pretty sure we
want to make additional control or stream interfaces the exception rather
than the rule. And having a standard read and write protocol of some sort
for ctl devices is more or less mandatory, otherwise they will all work
differently. This is not to say driver writers aren't allowed to depart
from it, just that it'll be more work if they do.
> > /dev/draw is interesting but largely irrelevant. And again, colormap and
> > refresh - why are they not part of ctl? You've got to select on refresh
> > anyway, might as well accept asynchronous messages through ctl.
>
> You've got to do _what_ on refresh?
I'm guessing some sort of poll or select on the refresh device, assuming a
single-threaded app. But no, I've never used 9 nor am I especially
interested in exploring it in depth, given its license and lack of
community.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
In article <[EMAIL PROTECTED]> you wrote: > On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: >> distributions). 18 months is more realistic for it to be deployed >> widely enough. > People who are going to be savvy enough to install a development 2.5.* > kernel that is defining a new configuration utility are going to be savvy > enough to install python. In the first months, yes. Once we freeze you've just lost a major part of your testersbase... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Mon, 21 May 2001, Oliver Xymoron wrote:
> K - so what? I'm guessing what you want me to see is that these
> implement multiple channels. Is there a reason that eia001stat couldn't be
> implemented as
>
> f=open("/dev/eia001ctl",O_RDWR);
> write(f,"stat\n");
> status=read(f); /* returns "stat foo\n" */
Less convenient.
> We don't want to implement a separate device node for every OOB ioctl that
> returns data, do we? Why should stat be any different?
For every? Probably not. Forcing all of them together? I bet that in many
cases it will be damn inconvenient. You are forcing the policy on all
drivers. For no good reason, AFAICS.
> /dev/draw is interesting but largely irrelevant. And again, colormap and
> refresh - why are they not part of ctl? You've got to select on refresh
> anyway, might as well accept asynchronous messages through ctl.
You've got to do _what_ on refresh?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.2.19+ide: corrupts ide tape output
Greetings! 2.2.19+ide, applied the patch because this box has a new
Promise PDC20267 ide controller. 14GB HP Colorado tape drive. Before
we installed the new ide controller and patched the kernel, i.e. with
unpatched 2.2.19 running on a different ide controller, this setup
works just fine. Now I get the following occasionally, which results
in corrupted dumps to tape:
May 21 10:27:47 intech9 kernel: hdh: status error: status=0x40 { DriveReady }
May 21 10:27:47 intech9 kernel: ide-scsi: Strange, packet command initiated yet DRQ
isn't asserted
Any advice much appreciated!
--
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: tmpfs + sendfile bug ?
> That could be a bug with tmpfs and sendfile in 2.4.5-pre4 : > > [...] > read(8, "%PDF-1.4\r%\342\343\317\323\r\n870 0 obj\r<< \r/L"..., > 8192) = 8192 > shmat(11, 0x4cfe65, 0x3)= 0xb4d4 > sendfile(11, 8, [0], 5045861) = -1 EINVAL (Invalid argument) > [...] > > Any idea ? Looks like a bug in the program. If 'sendfile' returns 'EINVAL', that means you can't use 'sendfile' to send this particular file, and should default to read/write or mmap/write. If this program doesn't, it doesn't understand Linux's 'sendfile' semantics. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: maestro ported to 2.4 PCI API
> - ported to Linux 2.4 PCI API, PCI module based, cleaned up > return values. (taking into account all the hints Jeff has given > me ;) cool :) > - did NOT change any power management support, since I don't know > anything about power management. someone else (in .de, it appears to be the source of maestro hacking nowadays :)) is cleaning up the power management. > - bumped version. we might as well just stop using these, they don't mean much of anything anymore. - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: maestro ported to 2.4 PCI API
> > - bumped version. > > we might as well just stop using these, they don't mean much of anything > anymore. Its useful to have version ids. So it would be better people used them more > 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: "clock timer configuration lost" on Serverworks chipset
> The 2.2.20-pre2 patch doesn't change time.c, and I don't see > this code in 2.4.4 or 2.4.5pre. its in 2.4.4-ac where Im testing the change > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3c905C-TX [Fast Etherlink] problem ...
Robert Vojta wrote: > > Hi, > I have this card in intranet server and I'm very confused about very often > message in log like this: > > eth0: Transmit error, Tx status register 82. > Flags; bus-master 1, dirty 20979238(6) current 20979242(10) > Transmit list 1f659290 vs. df659260. > 0: @df659200 length 85ea status 000105ea > 1: @df659210 length 8296 status 00010296 > 2: @df659220 length 85ea status 000105ea [snip] Hi, I had the same problem with 2.4.3-pre6 (also with the 3c905C). Alle problems were gone with 2.4.4, so I stopped bothering. Hope this helps... Wilfried - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Compile fails an Alpha: include/asm/pci.h included from arch/alpha/kernel/setup.c
Jan-Benedict Glaw wrote: > > Hi! > > Kernel 2.4.5-pre[34] don't compile on Alpha: > > In incluse/asm-alpha/pci.h (include during compile of > arch/alpha/kernel/setup.c), there is include linux/pci.h not asm/pci.h... I've got a fix patch going to Linus today, along with some other small Alpha build fixes like this. -- Jeff Garzik | "Are you the police?" Building 1024| "No, ma'am. We're musicians." MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Mon, 21 May 2001, Alexander Viro wrote:
> On Mon, 21 May 2001, Oliver Xymoron wrote:
>
> > If you've got side channels that are of a packet nature (aka commands),
> > then they can all happily coexist on one device. If you've got channels
> > that are streams or intended for mmap, those ought to be different
> > devices.
>
> Since you've been refering to -9 - care to take a look at the contents of
> uart(3)? Or lpt(3). Or draw(3), for that matter.
K - so what? I'm guessing what you want me to see is that these
implement multiple channels. Is there a reason that eia001stat couldn't be
implemented as
f=open("/dev/eia001ctl",O_RDWR);
write(f,"stat\n");
status=read(f); /* returns "stat foo\n" */
We don't want to implement a separate device node for every OOB ioctl that
returns data, do we? Why should stat be any different?
/dev/draw is interesting but largely irrelevant. And again, colormap and
refresh - why are they not part of ctl? You've got to select on refresh
anyway, might as well accept asynchronous messages through ctl.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
On Mon, 21 May 2001, Udo A. Steinberg wrote: > Not just crap hardware, but also vendors who refuse to release proper material > required for writing drivers. NVidia springs to my mind. This would be a browser-busting webpage, the page would be so long... -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
On Mon, 21 May 2001, Gerhard Mack wrote: > > Its what I would describe as lack of enforcement by trading standards bodies, > > and I suspect what the US would call 'insufficient class action lawsuits' > What we need is a web page for listing crap hardware so less people buy > it. And then get sued by the manufacturers so that they can keep running their scams of selling broken shit hardware to the public. -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Mon, 21 May 2001, Oliver Xymoron wrote: > If you've got side channels that are of a packet nature (aka commands), > then they can all happily coexist on one device. If you've got channels > that are streams or intended for mmap, those ought to be different > devices. Since you've been refering to -9 - care to take a look at the contents of uart(3)? Or lpt(3). Or draw(3), for that matter. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFT] smbfs bugfixes for 2.4.4
On Mon, 21 May 2001, Xuan Baldauf wrote:
> Hello Urban,
>
> I've been playing around a while with that patch and so far could not find any
> problems anymore. But I've noticed some other annoying behaviour, which might
Good.
> be caused by trying to work around the initially reported bug where the
> win98se server does not update something (the new file contents after writing
> to a file or the file size?) when something is written by the client: Every
> little SMBwrite is followed by an SMBflush, which is translated by win98se
> into a "commit" of the file, which seems to be an fsync(2) equivalent.
Yes, I know.
>
> That is annoying, because it heavily slows down bulk transfers of small
> writes, like automatically unzipping a new mozilla build from the linux box to
> the windows box. Every write of say 100 bytes is implemented as
>
> send write req
> recv write ack
> send flush req
> sync to disk (on the windows machine)
> recv flush ack
>
> This creates heaviest disk load (on the windows machine) for minimal
> throughput. Is the SMBflush needed anymore, after you seem to have found
> another, better workaround?
SMBflush is the better variant of the workaround I sent you first, as
flush will always work but setting that flag doesn't ("correctness" over
speed, or something like that).
But does it really do that? It will only flush when the page you wrote to
is sent to the fs for writing. The page cache doesn't do that on each
write (I assume, should check) so then a 10 byte write, followed by
another 10 doesn't give 2 flushes but only one when that page is written.
It's still very much a slowdown with win9x servers.
I'll see if I can come up with something better than flush. What I need is
a way to tell the server that the file did change so that it will start
giving back the correct size.
I'm guessing that the win9x smb server caches some values but doesn't
understand that writing changes that. Possibly an assumption that the
client "knows" the correct filesize (but that breaks if someone else
changes the file).
People shouldn't be using win9x as "servers" anyway ... :)
/Urban
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Mon, 21 May 2001, David Lang wrote: > what makes you think it's safe to say there's only one floppy drive? Read as: it doesn't make sense to have per-fd state on a single floppy device given that there's only one actual hardware instance associated with it and multiple openers don't make sense. Opening a floppy at different densities with magic filenames was an example Linus used earlier in the thread. Surely there can be more than one drive and more than one serial port. > On Mon, 21 May 2001, Oliver Xymoron wrote: > > > On Sat, 19 May 2001, Alexander Viro wrote: > > > > > Let's distinguish between per-fd effects (that's what name in > > > open(name, flags) is for - you are asking for descriptor and telling > > > what behaviour do you want for IO on it) and system-wide side effects. > > > > > > IMO encoding the former into name is perfectly fine, and no write on > > > another file can be sanely used for that purpose. For the latter, though, > > > we need to write commands into files and here your miscdevices (or procfs > > > files, or /dev/foo/ctl - whatever) is needed. > > > > I'm a little skeptical about the necessity of these per-fd effects in the > > first place - after all, Plan 9 does without them. There's only one > > floppy drive, yes? No concurrent users of serial ports? The counter that > > comes to mind is sound devices supporting multiple opens, but I think > > esound and friends are a better solution to that problem. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] <[EMAIL PROTECTED]>: > Speaking from the perspective of a user of the CML tools, rather > than as a developer, all I've been trying to say is this: When I > type "make menuconfig" or "make oldconfig" in the future, I want to > see the same interface and the same results that I've always seen, > because it's always worked for me in the past. Visual details will differ, but I've been careful about maintaining functional compatibility. There was a phase of the development during which I was mostly processing feature requests from people who wanted features of the old system that I had not properly understood (such as the NEW tag). That phase ended almost a month ago. Nobody who has actually tried the CML2 tools more recently has reported that the UI changes present any difficulty. CML2 drops its configuration results in the same place, in the same formats, as CML1. So you should in fact be able to type `make menuconfig' and `make oldconfig' with good results. Have you actually tried this? -- http://www.tuxedo.org/~esr/";>Eric S. Raymond The right of the citizens to keep and bear arms has justly been considered as the palladium of the liberties of a republic; since it offers a strong moral check against usurpation and arbitrary power of rulers; and will generally, even if these are successful in the first instance, enable the people to resist and triumph over them." -- Supreme Court Justice Joseph Story of the John Marshall Court - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Mon, May 21, 2001 at 03:51:51PM +0400, Ivan Kokshaysky wrote:
> I'm unable reproduce it with *8Mb* window, so I'm asking.
Me either. But Tom Vier, the guy who started this thread
was able to use up the 8MB. Which is completely believable.
The following should aleviate the situation on these smaller
machines where the direct map does cover all physical memory.
Really, we were failing gratuitously before.
On Tsunami and Titan, espectially with more than 4G ram we
should probably just go ahead and allocate the 512M or 1G
scatter-gather arena.
(BTW, Andrea, it's easy enough to work around the Cypress
problem by marking the last 1M of the 1G arena in use.)
r~
diff -ruNp linux/arch/alpha/kernel/pci_iommu.c linux-new/arch/alpha/kernel/pci_iommu.c
--- linux/arch/alpha/kernel/pci_iommu.c Fri Mar 2 11:12:07 2001
+++ linux-new/arch/alpha/kernel/pci_iommu.c Mon May 21 01:25:25 2001
@@ -402,8 +402,20 @@ sg_fill(struct scatterlist *leader, stru
paddr &= ~PAGE_MASK;
npages = calc_npages(paddr + size);
dma_ofs = iommu_arena_alloc(arena, npages);
- if (dma_ofs < 0)
- return -1;
+ if (dma_ofs < 0) {
+ /* If we attempted a direct map above but failed, die. */
+ if (leader->dma_address == 0)
+ return -1;
+
+ /* Otherwise, break up the remaining virtually contiguous
+ hunks into individual direct maps. */
+ for (sg = leader; sg < end; ++sg)
+ if (sg->dma_address == 2 || sg->dma_address == -2)
+ sg->dma_address = 0;
+
+ /* Retry. */
+ return sg_fill(leader, end, out, arena, max_dma);
+ }
out->dma_address = arena->dma_base + dma_ofs*PAGE_SIZE + paddr;
out->dma_length = size;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: "clock timer configuration lost" on Serverworks chipset
I'm confused. The 2.2.19 time.c is already doing ">":
/* VIA686a test code... reset the latch if count > max */
if (count > LATCH-1) {
[adjust count and whine]
The 2.2.20-pre2 patch doesn't change time.c, and I don't see
this code in 2.4.4 or 2.4.5pre.
Are you saying the code should be doing the equivalent of
"(count > LATCH)", or is 2.2.19 correct and the whines I'm
seeing mean there really is a problem with the Serverworks
chipset?
Thanks,
jcastle
Alan Cox wrote:
>Jim Castleberry)wrote:
>> How well has the problem been nailed down? Could it be that it just
>> showed up first on VIA and the real cause (and fix) remains to be
>> discovered? Or does Serverworks somehow have an identical bug in
>> their chipset?
>
>There is a notional off by one in the check at least by the rules of the
>original chip which do allow the overflow value to be visible momentarily.
>Later -ac checks for > not >=
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Ext2, fsync() and MTA's?
Hi, On Sun, May 13, 2001 at 12:53:37AM +1000, Andrew McNamara wrote: > I seem to recall that in 2.2, fsync behaved like fdatasync, and that > it's only in 2.4 that it also syncs metadata - is this correct? No, fsync should be safe on 2.2. There was a problem with O_SYNC not syncing all metadata on 2.2 if you were extending a file, but that never applied to fsync. > Do the BSD's sync the directory data on an fsync of a file? I guess > this is the bone of contention No --- the old BSDs were safe because their directory operations were fully synchronous so they *never* needed to be sync'ed manually. According to SuS, an application relying on sync directory updates is buggy, because SuS simply makes no such guarantees. Just set chattr +S on the spool dir. That's what the flag is for. The biggest problem with that is that it propagates to subdirectories and files --- would a version of the flag which applied only to directories be a help here? Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ext2, fsync() and MTA's?
Hi, On Sat, May 12, 2001 at 03:13:55PM +0100, Alan Cox wrote: > fsync guarantees the inode data is up to date, fdatasync just the data. fdatasync guarantees "important" inode data too. The only thing that fdatasync is allowed to skip is the timestamps. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Sun, 20 May 2001, Alexander Viro wrote: > On Sun, 20 May 2001, Abramo Bagnara wrote: > > > > It may have several. Which one? > > > > Can you explain better this? > > Example: console. You want to be able to pass font changes. I'm > less than sure that putting them on the same channel as, e.g., > keyboard mapping changes is a good idea. If you've got side channels that are of a packet nature (aka commands), then they can all happily coexist on one device. If you've got channels that are streams or intended for mmap, those ought to be different devices. > Moreover, we have channels that are not tied to a particular device - > they are for a group of them. Example: setting timings for IDE controller. > Sure, we can just say "open /dev/hda instead of /dev/hda5", but then we > are back to the "find related file" problem you tried to avoid. Hmmm.. I suspect there's a permission issue lurking here anyway. It's probably valid to want to give out raw partition access, say to a database user, but not to give out permission to fiddle with the underlying drive. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Brent D. Norris <[EMAIL PROTECTED]>: > didn't Eric say that this has stalled though? Is that not the case? Nope. Greg is still working. He got the first version of the theorem prover working recently. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond A wise and frugal government, which shall restrain men from injuring one another, which shall leave them otherwise free to regulate their own pursuits of industry and improvement, and shall not take from the mouth of labor the bread it has earned. This is the sum of good government, and all that is necessary to close the circle of our felicities. -- Thomas Jefferson, in his 1801 inaugural address - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
On 05/21/2001 at 05:04:40 AM [EMAIL PROTECTED] wrote: >See, I've already written off the chronic bellyachers. Since I can't >please them without scrapping the whole plan, I'm going to ignore >them. In particular, anybody who repeated "fsck Python..." after Linus >ruled that Python is not an issue and Greg Banks announced the C >implementation of CML2 has got a sufficiently severe case of >rectocranial insertion that they've defined themselves out of the >conversation. I probably qualify as one of the bellyachers. If so, I apologize. It was not my intention to disparage the work of Eric or anyone else involved in this project. Speaking from the perspective of a user of the CML tools, rather than as a developer, all I've been trying to say is this: When I type "make menuconfig" or "make oldconfig" in the future, I want to see the same interface and the same results that I've always seen, because it's always worked for me in the past. It really doesn't matter to me if, down underneath, this is being done by CML1, CML2, or a little man in my computer who slaughters chickens and reads their entrails for omens to determine dependencies. Right now I can grab a new -pre or -ac patch, use oldconfig, and have a compile going in a few minutes, without knowing or caring about the details of the config process. In the rare case that a patch breaks an existing driver, it takes only a couple of minutes with menuconfig to disable that driver and compile without it, and then put it back in when it's fixed. And when, every once in a great while, I decide to scrap my .config and start over, I can fly through all the menuconfig options very quickly and make my customary selections almost without thinking about it. I just want to be able to keep using the tools in this way. If that's not going to be possible... well, I'll adapt. But from my point of view, learning a new set of tools just to keep doing the same things I've always done isn't a pleasant prospect. I understand that changes may be necessary to meet others' needs, but I'd like to see those changes made without affecting the way my own needs are met. I'm off my soapbox now and won't bellyache about it any further. Wayne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI - console problems 2.4.4
Alan Cox <[EMAIL PROTECTED]> writes: > > Is anyone having problems with ACPI causing console problems in kernel > > 2.4.4 w/ Intel's patches? When watching my system boot over the > > serial console, things work fine. When looking at my VAIO-FX140's > > LCD, my console no longer updates after ACPI starts initializing _INI methods. > > Generally a good rule is 'dont bother with ACPI'. But do let Andrew Grover > know how it fails on your box > My VAIO doesn't support APM. :( I was trying to understand the call path on _INIT. Hopefully with some printk's I can track down the problem. Any direction or areas for me to examine? Thanks. -- Nick PGP KEY: http://www.coelacanth.com/~nick/npapadon.public.asc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: VIA's Southbridge bug: Latest (pseudo-)patch
There is such a web page, and it's the .html version of the Hardware-HOWTO on any LDP mirror. Some distribution even print it and include with their booklets accompanying the installation CDs. Make sure you send case reports about any unsupported crap hardware there... > -Original Message- > What we need is a web page for listing crap hardware so less > people buy > it. > > Gerhard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: compile failure in 2.4.5-pre4
Ok, so the code was easy to fix ;p
On Mon, 21 May 2001, Keith Owens wrote:
> On Mon, 21 May 101 16:38:45 +1000 (EST),
> Allan Duncan <[EMAIL PROTECTED]> wrote:
> >drivers/ide/ide-pci.c:711
> > if (!IDE_PCI_DEVID_EQ(d->devid, DEVID_CS5530)
>
> for (i = 0; i < 1000; ++i)
> printf("I must scan kernel archives before report bugs\n");
>
> http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg45470.html
>
> >Allan Duncan [EMAIL PROTECTED] (+613) 9253 6708, Fax 9253 6775
> > (We are just a number)
>
> Who is number 1?
> You are number 6.
> I am not a number, I am a free man!
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: VIA's Southbridge bug: Latest (pseudo-)patch
Gerhard Mack wrote: > > > Its what I would describe as lack of enforcement by trading standards bodies, > > and I suspect what the US would call 'insufficient class action lawsuits' > > What we need is a web page for listing crap hardware so less people buy > it. Not just crap hardware, but also vendors who refuse to release proper material required for writing drivers. NVidia springs to my mind. -Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: compile failure in 2.4.5-pre4
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o ide-pci.o ide-pci.c ide-pci.c: In function `ide_setup_pci_device': ide-pci.c:712: parse error before `hwif' make[3]: *** [ide-pci.o] Error 1 Yeah, same compile bug. On Mon, 21 May 101, Allan Duncan wrote: > This addition for 2.4.5-pre4 has caused a compile failure with a parsing error: > > drivers/ide/ide-pci.c:711 > if (!IDE_PCI_DEVID_EQ(d->devid, DEVID_CS5530) > > In my case CONFIG_BLK_DEV_CS5530 is not defined. > > -- > Allan Duncan [EMAIL PROTECTED] (+613) 9253 6708, Fax 9253 6775 > (We are just a number) > Next Generation Infrastructure Program - Transport Architecture Project > Telstra Research Labs, Box 249 Rosebank MDC, Clayton, Victoria, 3169, Australia > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message 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: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Sat, 19 May 2001, Jeff Garzik wrote: > Why are LVM and EVMS(competing LVM project) needed at all? > > Surely the same can be accomplished with > * md > * snapshot blkdev (attached in previous e-mail) > * giving partitions and blkdevs the ability to grow and shrink > * giving filesystems the ability to grow and shrink You can migrate data off disks while the filesystems on top of them are live. Add disk b, migrate a->b, remove disk a. Perhaps this is intrinsic in the above somehow but I don't see it. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3C905C and error e401 : problem solved
Hi Mr Morton and all linux-kernel, I have been experimenting with the 3C905C, trying to get rid of the annoying e401 error (too much work in interrupt). I've tried using 64 as max_interrupt_work and it solves completely the e401 problem on this particular machine : - yoda.rez-gif.supelec.fr (dns/proxy for 500 clients, on a 10Mbits/s direct Internet connexion, local network is 100Mbits/s) ASUS P2B-DS dual PII-350 512MB RAM (2*128+1*256) 3*IBM 18GB 10KT U2W SCSI 3C905C S3 Virge Linux Slackware-current, 2.2.19 or 2.4.4 both built for smp with APIC. Before setting max_interrupt_work at 64, the e401 error could occur 20 times a day. Now it doesn't occur anymore. I have waited for a long time to test that on the SMP PC because it is critical for our network. I have tried to link these e401 messages with another activity on the PC, like heavy I/O, to no avail. The 3C905C does 10 times as many interruptions as the SCSI controller does. Lowering the max_interrupt_work creates a lot more errors in the logs (all are e401). On that second PC, the message still appears (very rarely though, about once in two or three days. I cannot relate those occurences to anything). It used to appear very often (about 40 times a day). I have tried to put the machine under stress (4 heavy FTP transfers at once, each 400MB long, with 4 different clients, connected in 100 MBits FD). The e401 message has not appeared... I'm a bit at a loss here. - lando.rez-gif.supelec.fr (FTP for the same network) ABIT LX6 PII300 128MB RAM IBM 8.4GB IDE (1st Master) + Maxtor 60GB IDE (2nd Master) 3C905C S3 Virge Linux Slackware-current, 2.4.4, ProFTPD All our network is 100MBits Full Duplex, switched with 3COM switches. Best regards, thanks for all your work François Cami - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
> Its what I would describe as lack of enforcement by trading standards bodies, > and I suspect what the US would call 'insufficient class action lawsuits' What we need is a web page for listing crap hardware so less people buy it. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Sat, 19 May 2001, Alexander Viro wrote: > Let's distinguish between per-fd effects (that's what name in > open(name, flags) is for - you are asking for descriptor and telling > what behaviour do you want for IO on it) and system-wide side effects. > > IMO encoding the former into name is perfectly fine, and no write on > another file can be sanely used for that purpose. For the latter, though, > we need to write commands into files and here your miscdevices (or procfs > files, or /dev/foo/ctl - whatever) is needed. I'm a little skeptical about the necessity of these per-fd effects in the first place - after all, Plan 9 does without them. There's only one floppy drive, yes? No concurrent users of serial ports? The counter that comes to mind is sound devices supporting multiple opens, but I think esound and friends are a better solution to that problem. What I'd like to see: - An interface for registering an array of related devices (almost always two: raw and ctl) and their legacy device numbers with a single userspace callout that does whatever /dev/ creation needs to be done. Thus, naming and permissions live in user space. No "device node is also a directory" weirdness which is overkill in the vast majority of cases. No kernel names or permissions leaking into userspace. - An unregister_devices that does the same, giving userspace a chance to persist permissions, etc. - A userspace program that keeps a mapping of kernel names to /dev/ names, permissions, etc. - An autofs hook that does the reverse mapping for running with modules (possibly calling modprobe directly) Possible future extension: - Allow exporting proc as a large collection of devices. Manage /proc in userspace on a tmpfs. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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: maestro ported to 2.4 PCI API
Marcus Meissner <[EMAIL PROTECTED]> ecrit :
[...]
> if( request_region(iobase, 256, card_names[card_type]) == NULL )
> {
> printk(KERN_WARNING "maestro: can't allocate 256 bytes I/O at
>0x%4.4x\n", iobase);
> - return 0;
> - }
> -
> - /* this was tripping up some machines */
> - if(pcidev->irq == 0) {
> - printk(KERN_WARNING "maestro: pci subsystem reports irq 0, this might
>not be correct.\n");
> + return -EBUSY;
> }
>
> /* just to be sure */
> @@ -3406,7 +3429,7 @@
> if(card == NULL)
> {
> printk(KERN_WARNING "maestro: out of memory\n");
> - return 0;
> + return -ENOMEM;
request_region is unbalanced in this return path.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
