Re: Problems with irda (irlap, ircomm)
On Sat, 10 Feb 2001, Fredrik Falk wrote: > Version: "Linux version 2.4.2-pre2 ([EMAIL PROTECTED]) (gcc version 2.96 Please update to pre3. There ware some irda-updated from Dag. > 2731 (Red Hat Linux 7.0)) #1 SMP Sat Feb 10 02:26:51 CET 2001" I hope it's the updated one. You might better ask on the IrDA-Mailinglist: http://www.pasta.cs.UiT.No/pipermail/linux-irda/ BYtE Philipp -- / / (_)__ __ __ Philipp Hahn / /__/ / _ \/ // /\ \/ / //_/_//_/\_,_/ /_/\_\ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.[01] and duron - unresolved symbol _mmx_memcpy
Hi everybody, Some time ago I tried 2.4.0 compiled with option for duron-processors, yesterday I tried 2.4.1; both give problems on insmod/modprobe with some modules, eg. tulip. The offending function is _mmx_memcpy, which can be found in the System.map (but, opposed to other functions, with an upper "T" instead of "t"). /proc/cpuinfo says that I have mmx, 3dnow and so on, but there seems to be a problem getting _mmx_memcpy it into the bzlilo-target. I saw that CONFIG_X86_HAS_3DNOW is set in include/config/x86/use/3dnow.h, so I thought that the #defines should be ok. So, is this already solved (couldn't find it on linux24.sourceforge.net), is it known? should I do some more investigation? Regards, Phil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial device with very large buffer
On Fri, 9 Feb 2001, Pavel Machek wrote: > > > I also propose to increase the size of flip buffer to 640 bytes (so the > > > flipping won't occur every time in the middle of the full buffer), however > > > I understand that it's a rather drastic change for such a simple goal, and > > > not everyone will agree that it's worth the trouble: > > > > Going to a 1K flip buffer would make sense IMHO for high speed devices too > > Actually bigger flipbufs are needed for highspeed serials and > irda. Tytso received patch to make flipbuf size settable by the > driver. (Setting it to 1K is not easy, you need to change allocation > mechanism of buffers.) The need for changes in allocation mechanism was the reason why I have limited the buffer increase to 640 bytes. If changes already exist, and there is no some hidden overhead associated with them, I am all for it. Still it's not a replacement for the change in serial driver that I have posted -- assumption that hardware is slower than we are, that it has limited buffer in the way, and that it's ok to discard all the data beyond our buffer's size is, to say least, silly. -- Alex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] inter_module_* backport to 2.2.18
The inter_module_* feature of 2.4 is neat ... so neat that tpctl-2.0
actually requires it. I figured it would be easier to backport the
feature rather than to make tpctl get along without it. The backport
was quite clean. Perhaps you'll want to include it in 2.2.19
Index: include/linux/module.h
--- include/linux/module.h 2000/09/13 15:32:25 1.2
+++ include/linux/module.h 2001/02/12 06:28:27
@@ -9,4 +9,5 @@
#include
+#include
#ifdef __GENKSYMS__
@@ -148,4 +149,38 @@ static inline unsigned long get_module_s
extern unsigned long get_module_symbol(char *, char *);
#endif
+
+/* Generic inter module communication.
+ *
+ * NOTE: This interface is intended for small amounts of data that are
+ * passed between two objects and either or both of the objects
+ * might be compiled as modules. Do not over use this interface.
+ *
+ * If more than two objects need to communicate then you probably
+ * need a specific interface instead of abusing this generic
+ * interface. If both objects are *always* built into the kernel
+ * then a global extern variable is good enough, you do not need
+ * this interface.
+ *
+ * Keith Owens <[EMAIL PROTECTED]> 28 Oct 2000.
+ */
+
+#ifdef __KERNEL__
+#define HAVE_INTER_MODULE
+extern void inter_module_register(const char *, struct module *, const void *);
+extern void inter_module_unregister(const char *);
+extern const void *inter_module_get(const char *);
+extern const void *inter_module_get_request(const char *, const char *);
+extern void inter_module_put(const char *);
+
+struct inter_module_entry {
+ struct list_head list;
+ const char *im_name;
+ struct module *owner;
+ const void *userdata;
+};
+
+extern int try_inc_mod_count(struct module *mod);
+#endif /* __KERNEL__ */
+
#if defined(MODULE) && !defined(__GENKSYMS__)
Index: kernel/ksyms.c
--- kernel/ksyms.c 2001/01/22 22:40:58 1.5.4.11
+++ kernel/ksyms.c 2001/02/12 06:28:29
@@ -94,4 +94,11 @@ EXPORT_SYMBOL(get_module_symbol);
EXPORT_SYMBOL(get_options);
+EXPORT_SYMBOL(inter_module_register);
+EXPORT_SYMBOL(inter_module_unregister);
+EXPORT_SYMBOL(inter_module_get);
+EXPORT_SYMBOL(inter_module_get_request);
+EXPORT_SYMBOL(inter_module_put);
+EXPORT_SYMBOL(try_inc_mod_count);
+
/* process memory management */
EXPORT_SYMBOL(do_mmap);
Index: kernel/module.c
--- kernel/module.c 2000/09/28 08:20:09 1.1.14.1
+++ kernel/module.c 2001/02/12 06:28:32
@@ -2,7 +2,10 @@
#include
#include
+#include
#include
+#include
#include
#include
+#include
#include
#include
@@ -52,4 +55,171 @@ static struct module kernel_module =
struct module *module_list = &kernel_module;
+#endif /* CONFIG_MODULES */
+
+/* inter_module functions are always available, even when the kernel is
+ * compiled without modules. Consumers of inter_module_xxx routines
+ * will always work, even when both are built into the kernel, this
+ * approach removes lots of #ifdefs in mainline code.
+ */
+
+static struct list_head ime_list = LIST_HEAD_INIT(ime_list);
+static spinlock_t ime_lock = SPIN_LOCK_UNLOCKED;
+static int kmalloc_failed;
+
+/**
+ * inter_module_register - register a new set of inter module data.
+ * @im_name: an arbitrary string to identify the data, must be unique
+ * @owner: module that is registering the data, always use THIS_MODULE
+ * @userdata: pointer to arbitrary userdata to be registered
+ *
+ * Description: Check that the im_name has not already been registered,
+ * complain if it has. For new data, add it to the inter_module_entry
+ * list.
+ */
+void inter_module_register(const char *im_name, struct module *owner, const void
+*userdata)
+{
+ struct list_head *tmp;
+ struct inter_module_entry *ime, *ime_new;
+
+ if (!(ime_new = kmalloc(sizeof(*ime), GFP_KERNEL))) {
+ /* Overloaded kernel, not fatal */
+ printk(KERN_ERR
+ "Aiee, inter_module_register: cannot kmalloc entry for '%s'\n",
+ im_name);
+ kmalloc_failed = 1;
+ return;
+ }
+ memset(ime_new, 0, sizeof(*ime_new));
+ ime_new->im_name = im_name;
+ ime_new->owner = owner;
+ ime_new->userdata = userdata;
+
+ spin_lock(&ime_lock);
+ list_for_each(tmp, &ime_list) {
+ ime = list_entry(tmp, struct inter_module_entry, list);
+ if (strcmp(ime->im_name, im_name) == 0) {
+ spin_unlock(&ime_lock);
+ kfree(ime_new);
+ /* Program logic error, fatal */
+ printk(KERN_ERR "inter_module_register: duplicate im_name
+'%s'", im_name);
+ BUG();
+ }
+ }
+ list_add(&(ime_new->list), &ime_list);
+ spin_unlock(&ime_lock);
+}
+
+/**
+ * inter_module_unregister - unregister a set of inter module data.
+ * @im_name: an arbitrary string to identify
sysinfo.sharedram not accounted for on i386 ?
On i386, sysinfo.sharedram is not accounted for, leading /proc/meminfo to always report MemShared as 0. Is this the intended behavior? Brian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: eepro100.c, kernel 2.4.1
Ion, On Thu, Feb 08, 2001 at 03:26:51AM -0800, Ion Badulescu wrote: > On Thu, 8 Feb 2001 20:15:39 +0900, Augustin Vidovic <[EMAIL PROTECTED]> wrote: > > >> eth0: Sending a multicast list set command from a timer routine." > >> > >> If you find such messages, the work-around really did something. Otherwise, > >> it's the placebo effect... > > > > Now, I do not get _any_ message in the logs, which means that the network > > cards activity is closer to normality than before the patch. > > So your patch did not do you any good. Case closed, as far as the work-around > is concerned. I've just checked: "Sending a multicast list set command" is printed only on high debug levels, so Augustin might not see them. If "Receiver lock-up workaround activated" message is printed, then the workaround is really activated. I doubt that the real reason is that RX bug, but periodic multicast list set commands may certainly affect the behavior. Augustin, could you send the output of `lspci' and `eepro100-diag -ee', please? (The latter may be taken from ftp://scyld.com/pub/diag/) Best regards Andrey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Athlon-SMP final
Hi Alan,
The polishing is done. Versus 2.4.1 again.
Summary:
struct task_struct{...} moved to a new file, linux/task_struct.h.
struct sigpending{...} moved to a new file, linux/sigpending.h.
remove line linux/capability.c:17 #include (blessed by Andrew
Morgan)
adjust header inclusions in CONFIG_X386_USE_3DNOW section of
asm-i386/string.h.
Changes from the first version of the patch:
revert creation of linux/mm_struct.h (needless)
improve comments in the new files
remove #ifdef guards around dummy declarations (suggested by Manfred
Spraul)
remove dead version of kernel_cap_t support (also Manfred)
remove redundant #include's (Niels Kristian Bech Jensen)
The new task_struct.h may be useful to others. If linux/sched.h is included
just to permit dereference of some 'struct task_struct * tsk',
linux/task_struct.h is a lightweight alternative.
Thanks again to Niels Kristian Bech Jensen, Andrew Morgan, and Manfred
Spraul.
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
k7-smp-inlined2.patch.gz
Problem: Floppy drive[?] hang
[This sortof follows the format of the report form in REPORTING-BUGS] 1. I've found a consistent set of circumstances which will hang 2.4.x kernels on my system. 2. If the system is put under load to the point where it swaps heavily (swapping appears to be pre-requisite, based on a little messing about), and then given commands to use the floppy drive (mount, ls -- anything which necessitates reading/writing to the floppy), it will hang with no message (it does not OOPS, or at least it can not to the root console) I've done this several times, with different disks and kernels, with and without X. 3. Hang, floppy, vm, swap 4. 2.4.0, 2.4.1, compiled on egcs gcc 2.91.66 7. My system is a K6 (well behaved to date, w/o bug, afaik) on an Acer mb; ALi M5229 IDE, ALi M15nn bridges... Unfortunately, I can't give the precise mb at the moment... However, if necessary, I can find out (system was bought as an IBM desktop, therefore the documentation is totally useless and in order to find anything out about hardware I either have to cunningly read the boot logs/ISA probing & interpret or read the green-on-green writing on the mb)... I can't think of any other relevant details, but I would be happy to respond to additional queries for information. 7.2 Relevant /proc/cpuinfo : processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 6 model name : AMD-K6tm w/ multimedia extensions fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 mmx [the rest of the bug reporting form seems excessive...] I hope this will be helpful... I'll be reading the mailing list, so if you would like to ask for info, blame my hardware, or insult my style (it's late in my timezone!), feel free. Best wishes, C. D. Thompson-Walsh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Duplicate posts coming from reiserfs-list?
My duplicate folder contains numerous messages from linux-kernel cc'd to reiserfs-list. I am not on reiserfs-list to my knowledge, so it looks like there is another loop somewhere.. -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2001, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- So, if anybody wants to have free hardware sent to them, don't call me, but instead write your own operating system. It has worked every time for me. Linus Torvalds - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
* Re: [patch] 2.4.0, 2.4.0-ac12: APIC lock-ups
Maciej's io-apic patch fixed the long-standing problems with my ne2k-pci card (since at least 2.4.0-test10, and absent in 2.2.17). Ne2k-pci card (D-Link, exact model # would require a reboot and card pull) Dual 366 Celeron / Abit BP6 / 128MB (Problem showed up at both 366/550) Eth0 has over 3 million interrupts, and no loss of connection. 2.4.0 (not .1) Thanks! Robert Cicconetti - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink
Hans Reiser writes: > Alan Cox wrote: >> [Ablert Cahalan] >>> In an __init function, have some code that will trigger the bug. >>> This can be used to disable Reiserfs if the compiler was bad. >>> Then the admin gets a printk() and the Reiserfs mount fails. >> >> Thats actually quite doable. I'll see about dropping the test >> into -ac that way. > > NO!! It should NOT fail at mount time, it should fail > at compile time. Detection at compile time is not reliable. Just last week, on a plain x86 box with a good gcc, I was compiling with a compiler called "/usr/local/bin/powerpc-linux-gcc". Guess what that does. My compiler was not in the RPM database. My compiler could not produce executables that would run on the build system, so build-time tests wouldn't work. Compiler version information is fairly useless, since x86-specific bugs don't matter at all. Maybe I even patched my compiler. Complaints about the local compiler are useful, but not sufficient. They only protect the menuconfig program, the mkdep program... As above, actual bug tests are better than trying to interpret what the compiler reports for a version. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1: Abnormal interrupt from RTL8139
Christian Ullrich wrote: > I'm getting some of these messages in syslog: > Feb 6 07:38:35 christian kernel: eth0: Abnormal interrupt, status 0010. > Feb 6 07:38:35 christian kernel: eth0: Abnormal interrupt, status 0010. > Feb 6 07:38:35 christian kernel: eth0: Abnormal interrupt, status 0020. > Feb 7 17:32:53 christian kernel: eth0: Abnormal interrupt, status 0041. [...] > I have not observed any effects related to these messages. Those messages are logged at the debugging level... if they bother you, don't log kern.debug... Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: devfs: "cd" device not showing up initially. [Fwd: Scan past lun 7 in
>
>
> > I consider the possibility of module loading. Both SCSI CD and
> > SCSI generic (sg) are modules now.
> > I checked /etc/devfs/devfs.conf (experimental Debian package
> > puts the config file here! ) has the following line:
> >
> >LOOKUP .* MODLOAD
> >
> > So the module autoloading ought to work. ("generic" exists
> > somehow from the start.)
>
> Chiaki,
> The upper level scsi drivers (sd, sr, st, osst and sg) register
> and unregister device names with devfs. After the mid level
> recognizes a new scsi device it calls the detect() function
> in the builtin upper level drivers and those that are currently
> loaded as modules. That is your "problem", sr_mod.o is not
> loaded until you do something like "ls -l /dev/sr0" (due to
> that LOOKUP rule in /etc/devfsd.conf). The lsmod command will
> show which modules are loaded (in your case look for sr_mod).
>
> There is no "push" mechanism in the scsi mid level to load
> the sr_mod.o module when it sees a device with SCSI type
> CDROM. Devfs (specifically devfsd) supplies various "pull"
> mechanisms (e.g. LOOKUP) to load that module.
>
Doug,
Thank you for enlightening me on the subtle
interaction of module loading and devfs.
One thing that confused me was that "generic" was
present On my system, I use the module version of
scsi generic driver.
Am I right then assuming that SCSI subsystem
somehow supports the loading of "sg" driver module
automagically (as opposed to mod_sr.o )?
Otherwise I can't explain why "generic" was already
present when I ran "ls", but "cd" wasn't.
(During the boot I see the string "sg" just prior to the
loading of tmscsim (DC390) driver module. The NCR driver
is built-in and recognized earlier. Aha, could it be that
"sg" is used for the initial probing of
device types and such?)
Maybe I am missing something here regarding module
loading very much.
Also, my setting may be quite Debian GNU/Linux
specific.
Anyway, I looked again very carefully at the devfs README file
under
/usr/src/linux/Documenation/filesystems/devfs
and found it a litte out of date.
- Richard Booch has a document
dated Oct 16, 2000 at the URL site mentioned in the
README file.
The one under /usr/src/linux/Documentation/filesystems/devfs
is dated 3-JUL-2000.
So at least, we might want to upgrade the document
to the latest available from the original author.
- Yet, even the one at the URL site doesn't
reflect the name changes that took place last year.
SCSI device names and others are not quite up to date and
don't agree with what we see on the real system.
(I am assuming that this is generally true and
not Debian-specific.)
Attached is my first cut to update the of the document.
I would appreciate it if the README document is updated
to reflect the current implemntation.
I would be glad to help by typing the first rough draft
initially according to the suggestions.
Happy Hacking,
Chiaki Ishikawa
*** /usr/src/linux/Documentation/filesystems/devfs/README Thu Nov 30 03:11:38
2000
--- README.devfsMon Feb 12 11:15:29 2001
***
*** 444,447
--- 444,460
openings.
+ [In the current implementation as of Feb 2001,
+ all the existing CD-ROM drives
+ appear under /dev/cdroms as cdrom0, cdrom1, ..., etc.
+ with appropriate symlinks pointing to the real CD device as in the following
+ snippet.
+
+ lr-xr-xr-x1 root root 34 Jan 1 1970 cdrom0 ->
+../scsi/host1/bus0/target5/lun1/cd
+ lr-xr-xr-x1 root root 34 Jan 1 1970 cdrom1 ->
+../scsi/host1/bus0/target6/lun0/cd
+ lr-xr-xr-x1 root root 34 Jan 1 1970 cdrom2 ->
+../scsi/host1/bus0/target6/lun1/cd
+
+ There is no /dev/sr. ]
+
+
-
***
*** 1035,1039
cd
-
The SCSI generic driver creates:
--- 1048,1051
***
*** 1132,1135
--- 1144,1161
+ [The current implemenation as of Feb 2001 uses the following scheme?
+
+ All the discs including IDE are put under
+ /dev/discs/
+ disc0, disc1, disc2, ...
+
+ All the entries are symlinks to the real device names under /dev/ide,
+ /dev/scsi, etc..
+ eg.
+ disc0 -> ../ide/host0/bus0/target0/lun0
+ disc1 -> ../scsi/host0/bus0/target4/lun0
+ disc2 -> ../scsi/host1/bus0/target5/lun0
+ ]
+
SCSI Tapes
***
*** 1148,1151
--- 1174,1181
+ [The current implemenation as of Feb 2001 uses the following scheme?
+ Insert the current usage . ]
+
+
SCSI CD-ROMs
***
*** 1156,1161
--- 1186,1226
/dev/sr/c1b2t3u4
+ [The above should be completely rewritten. ]
+ The current implemenation as of Feb 2001 uses the following scheme?
+
+ All the CD-ROMs including the SCSI CD-ROMs are put under
+ /d
Re: WOL failure after shutdown
Sorry, I wrote that in a hurry. Its a 3Com PCI 3c905C Tornado. I can successfully use wakeonlan if I power off the machine immeadiatly after turning it on. Using the shutdown command, which it will when I need it to power back up, it will not work. Im using a wakeonlan cable to my motherboard as well, not using wake through PCI bus. Kernel is 2.4.1 I appologize for not providing all required the specs in the original message. -- James Mark Hahn wrote: >> wakeonlan packets to my other servers to start them back up. Wakeonlan >> works if i were to hit the power before Linux starts, so I know I have >> it configured properly, and I also have wakeonlan turned on in the BIOS. >> However, when I do shutdown -h, it will turn the power off, but >> wakeonlan does not work. Ive tried enabling ACPI and tinkering with >> options in the BIOS, but i cant power up with WOL after issuing shutdown -h. > > > so when can you powerup with WOL? WOL requires that the driver leave the > card in a particular state; obviously, you should mention which NIC. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Slowing down CDROM drives
On Sun, 11 Feb 2001 16:20:47 -0200, Rogerio Brito <[EMAIL PROTECTED]> wrote: >> >ioctl(cd_fd, CDROM_SELECT_SPEED, speed); Yes: pass 0 as the speed, in the ioctl() above. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Feb 11 2001, Andi Kleen wrote: > The reiserfs nfs problem in standard 2.4 is very simple -- it'll > barf as soon as you run out of file handle/inode cache. Any workload > that accesses enough files in parallel can trigger it. I'm just trying to evaluate if I should use reiserfs here or not: is this phenomenon that you describe above happening independently of whether I choose the knfsd or userspace nfsd? From your message, I got the impression that it would happen with knfsd only, but I'm just checking before I make a wrong decision. Thanks from a humble (and ignorant) network admin, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.1: Abnormal interrupt from RTL8139
I'm getting some of these messages in syslog: Feb 6 07:38:35 christian kernel: eth0: Abnormal interrupt, status 0010. Feb 6 07:38:35 christian kernel: eth0: Abnormal interrupt, status 0010. Feb 6 07:38:35 christian kernel: eth0: Abnormal interrupt, status 0020. Feb 7 17:32:53 christian kernel: eth0: Abnormal interrupt, status 0041. Feb 7 17:55:22 christian kernel: eth0: Abnormal interrupt, status 0041. Feb 7 17:59:04 christian kernel: eth0: Abnormal interrupt, status 0040. Feb 7 19:39:47 christian kernel: eth0: Abnormal interrupt, status 0010. Feb 7 19:39:47 christian kernel: eth0: Abnormal interrupt, status 0010. Kernel is 2.4.1, eth0 is an rtl8139. MB is an ABIT KT7, with VIA chipset. I have not observed any effects related to these messages. I'm including the output of Linus's dump_pirq script, if it is of any use: Interrupt routing table found at address 0xfddd0: Version 1.0, size 0x00b0 Interrupt router is device 00:07.0 PCI exclusive interrupt mask: 0x8e00 [9,10,11,15] Compatible router: vendor 0x1106 device 0x0596 Device 00:11.0 (slot 1): INTA: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:0f.0 (slot 2): INTA: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:0d.0 (slot 3): SCSI storage controller INTA: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:0b.0 (slot 4): Multimedia audio controller INTA: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:09.0 (slot 5): Ethernet controller INTA: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:08.0 (slot 6): INTA: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:13.0 (slot 7): INTA: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:01.0 (slot 0): PCI bridge INTA: link 0x01, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTB: link 0x02, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTC: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Device 00:07.0 (slot 0): ISA bridge INTC: link 0x03, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] INTD: link 0x05, irq mask 0xdeb8 [3,4,5,7,9,10,11,12,14,15] Interrupt router at 00:07.0: VIA 82C686 PCI-to-ISA bridge PIRQA (link 0x01): irq 10 PIRQB (link 0x02): irq 15 PIRQC (link 0x03): irq 11 PIRQD (link 0x05): irq 9 -- Christian UllrichRegistrierter Linux-User #125183 "Sie können nach R'ed'mond fliegen -- aber Sie werden sterben" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
AMD PCNET: Nevermind
I thought I checked this, but pcnet32 got turned off. Sorry. Andy Carlson |\ _,,,---,,_ [EMAIL PROTECTED]ZZZzz /,`.-'`'-. ;-;;,_ BJC Health System |,4- ) )-,_. ,\ ( `'-' St. Louis, Missouri '---''(_/--' `-'\_) Cat Pics: http://andyc.dyndns.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/rtc not working on ASUS A7V133
On Mon, Feb 12, 2001 at 01:27:55AM +0100, Jan Niehusmann wrote: > If my ASUS A7V133-based computer got started by the bios automatic > startup timer, /dev/rtc doesn't work properly. /proc/drivers/rtc > shows sane values, but IRQ 8 is not triggered causing programms like > 'hwclock' to hang. > > I assume this is not a kernel bug but a BIOS problem, but it would be > nice if a kernel workaround was possible. Does anybody have an > idea what I could try to reenable the interrupts? I suppose you could give hwclock --directisa ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] 2.4.1-ac10 warning cleanup
Another installment in the never ending battle to keep the kernel build
free from warnings.
diff -urp 2.4.1-ac10.orig/arch/i386/kernel/traps.c 2.4.1-ac10/arch/i386/kernel/traps.c
--- 2.4.1-ac10.orig/arch/i386/kernel/traps.cMon Feb 12 11:57:01 2001
+++ 2.4.1-ac10/arch/i386/kernel/traps.c Mon Feb 12 11:14:59 2001
@@ -127,7 +127,7 @@ void show_trace(unsigned long * stack)
void show_trace_task(struct task_struct *tsk)
{
- show_trace(tsk->thread.esp);
+ show_trace((unsigned long *)(tsk->thread.esp));
}
void show_stack(unsigned long * esp)
diff -urp 2.4.1-ac10.orig/drivers/net/ne.c 2.4.1-ac10/drivers/net/ne.c
--- 2.4.1-ac10.orig/drivers/net/ne.cMon Feb 12 11:57:35 2001
+++ 2.4.1-ac10/drivers/net/ne.c Mon Feb 12 11:39:26 2001
@@ -87,7 +87,7 @@ isapnp_clone_list[] __initdata = {
{0}
};
-MODULE_DEVICE_TABLE(isapnp, isapnp_clone_list);
+MODULE_DEVICE_TABLE(isapnp, (struct isapnp_device_id *)isapnp_clone_list);
#ifdef SUPPORT_NE_BAD_CLONES
/* A list of bad clones that we none-the-less recognize. */
diff -urp 2.4.1-ac10.orig/drivers/usb/serial/usbserial.c
2.4.1-ac10/drivers/usb/serial/usbserial.c
--- 2.4.1-ac10.orig/drivers/usb/serial/usbserial.c Mon Feb 12 11:57:53 2001
+++ 2.4.1-ac10/drivers/usb/serial/usbserial.c Mon Feb 12 11:41:10 2001
@@ -298,10 +298,10 @@ static int generic_write_room(struct
static int generic_chars_in_buffer(struct usb_serial_port *port);
static void generic_read_bulk_callback (struct urb *urb);
static void generic_write_bulk_callback(struct urb *urb);
-static void generic_shutdown (struct usb_serial *serial);
#ifdef CONFIG_USB_SERIAL_GENERIC
+static void generic_shutdown (struct usb_serial *serial);
static __u16 vendor = 0x05f9;
static __u16 product = 0x;
MODULE_PARM(vendor, "i");
@@ -968,6 +968,7 @@ static void generic_write_bulk_callback
}
+#ifdef CONFIG_USB_SERIAL_GENERIC
static void generic_shutdown (struct usb_serial *serial)
{
int i;
@@ -981,6 +982,7 @@ static void generic_shutdown (struct usb
}
}
}
+#endif
static void port_softint(void *private)
diff -urp 2.4.1-ac10.orig/fs/buffer.c 2.4.1-ac10/fs/buffer.c
--- 2.4.1-ac10.orig/fs/buffer.c Mon Feb 12 11:57:57 2001
+++ 2.4.1-ac10/fs/buffer.c Mon Feb 12 11:13:58 2001
@@ -1035,7 +1035,6 @@ repeat:
int balance_dirty_state(kdev_t dev)
{
unsigned long dirty, tot, hard_dirty_limit, soft_dirty_limit;
- int shortage;
dirty = size_buffers_type[BUF_DIRTY] >> PAGE_SHIFT;
tot = nr_free_buffer_pages();
diff -urp 2.4.1-ac10.orig/fs/partitions/msdos.c 2.4.1-ac10/fs/partitions/msdos.c
--- 2.4.1-ac10.orig/fs/partitions/msdos.c Mon Feb 12 11:58:00 2001
+++ 2.4.1-ac10/fs/partitions/msdos.cMon Feb 12 11:13:11 2001
@@ -70,8 +70,11 @@ static inline int is_extended_partition(
/*
* partition_name() formats the short partition name into the supplied
* buffer, and returns a pointer to that buffer.
+ * Used by several partition types which makes conditional inclusion messy,
+ * use __attribute__ ((unused)) instead.
*/
-static char *partition_name (struct gendisk *hd, int minor, char *buf)
+static char __attribute__ ((unused))
+ *partition_name (struct gendisk *hd, int minor, char *buf)
{
#ifdef CONFIG_DEVFS_FS
sprintf(buf, "p%d", (minor & ((1 << hd->minor_shift) - 1)));
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Sunday, February 11, 2001 10:00:11 AM +0300 Hans Reiser <[EMAIL PROTECTED]> wrote: > Daniel Stone wrote: >> >> On 11 Feb 2001 02:02:00 +1300, Chris Wedgwood wrote: >> > On Thu, Feb 08, 2001 at 05:34:44PM +1100, Daniel Stone wrote: >> > >> > I run Reiser on all but /boot, and it seems to enjoy corrupting my >> > mbox'es randomly. >> > >> > what kind of corruption are you seeing? >> >> Zeroed bytes. > > This sounds like the same bug as the syslog bug, please try to help Chris > reproduce it. > > zam, if Chris can't reproduce it by Monday, please give it a try. > I had a bunch of scripts running over the weekend to try and reproduce this, but the results were ruined when a major storm killed the power (no, still haven't gotten around to configuring my UPS to shut things down ;-). So, I'll try again. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS with 2.4.1-ac8
On Sun, 11 Feb 2001, Kurt Roeckx wrote: > I suddenly started to get those oopses. It didn't seem to cause > any problems tho. > Feb 11 15:04:01 Q kernel: Call Trace: [cached_lookup+14/80] > [path_walk+1337/1944] [getname+91/152] [__user_walk+58/84] > [sys_newstat+21/108] > [system_call+51/64] This looks similar to an Oops posted by BaRT a couple of days ago. Out of curiosity, are you using ISDN, too? The oops doesn't seem to be related to the ISDN code AFAICS, but on the other hand you never know ;) --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Getting user input from the kernel?
Sorry if this is a stupid question. Is it possible to get user input from within the kernel? I am trying to develop simple text-based user interface for a user to perform some security critical actions, i.e. logging in. Basically, I am trying to implement a security manager that will be invoked via the magic key sequence. For all you security gurus this is a trusted path. Once the user has invoked my kernel code, I believe I can use printk to provide output to the user. However, there is no equivalent scank. How can I get user input from the kernel? Can this be done, or should I use the magic key sequence to launch a user mode process that will implement the security manager I have in mind? Also does it make a difference whether I use kernel 2.2 or 2.4? Thanks Jerome - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
AMD PCNET under VMWare with kernel 2.4.2pre3 and 2.4.1-ac10
I installed a fresh Slackware 7.1 with kernel 2.2.16 to do some testing with the 2.4 kernel series, all this under VMWare. Everything was fine, until I installed the new kernel (yes, I installed the stuff required in the CHANGES file). I cannot get 2.4.2pre3 or 2.4.1-ac10 to recognize the AMD PCNET adapter. Anyone having similar problems? Andy Carlson |\ _,,,---,,_ [EMAIL PROTECTED]ZZZzz /,`.-'`'-. ;-;;,_ BJC Health System |,4- ) )-,_. ,\ ( `'-' St. Louis, Missouri '---''(_/--' `-'\_) Cat Pics: http://andyc.dyndns.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
/dev/rtc not working on ASUS A7V133
If my ASUS A7V133-based computer got started by the bios automatic startup timer, /dev/rtc doesn't work properly. /proc/drivers/rtc shows sane values, but IRQ 8 is not triggered causing programms like 'hwclock' to hang. I assume this is not a kernel bug but a BIOS problem, but it would be nice if a kernel workaround was possible. Does anybody have an idea what I could try to reenable the interrupts? Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ext2: block > big ?
What does a message like 'ext2: block > big' indicate? This was kernel 2.2.18aa2. The machine was completely unresponsive when I got there. There were a bunch of block>big messages on the screen, but no oops. In my grogginess, I didn't have the sense to copy down the whole message, but it did also mention the device (8,9?). The major 8 scsi devices in use are three partitions of one disk -- two 15GB and one 50GB. Brian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-ac10 compile error
On Sun, 11 Feb 2001 17:34:04 -0500 (EST), Frank Davis <[EMAIL PROTECTED]> wrote: >Hello, >I received the following while compiling 2.4.1-ac10: >... >make[3]: *** No rule to make target '/usr/src/linux/drivers/pci/devlist.h', needed by >names.o'. Stop >make[3]: Leaving directory '/usr/src/linux/drivers/pci' >make[2]: *** [first_rule] Error 2 None of the 2.4.1-ac patches hit drivers/pci/Makefile. You have corrupted your source somewhere. Building from 2.4.1-pristine + patch-2.4.1-ac10.bz2 gives this in drivers/pci/Makefile. names.o: names.c devlist.h classlist.h devlist.h classlist.h: pci.ids gen-devlist ./gen-devlist http://www.tux.org/lkml/
WOL failure after shutdown
Hello, In the event of a power outtage, my servers all shutdown -h when the backup UPS gets low, and I have them configured to start back up with a router (that uses an AT mobo, so it will start automatically) to send wakeonlan packets to my other servers to start them back up. Wakeonlan works if i were to hit the power before Linux starts, so I know I have it configured properly, and I also have wakeonlan turned on in the BIOS. However, when I do shutdown -h, it will turn the power off, but wakeonlan does not work. Ive tried enabling ACPI and tinkering with options in the BIOS, but i cant power up with WOL after issuing shutdown -h. Im using an Abit KT7 motherboard, which uses the Via Apollo KT133 chipset. Any ideas/suggestions will be greatly appreciated. -- James Brents [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1: DMA gets disabled due to irq timeout
Hi, From: Igor Nekrestyanov ([EMAIL PROTECTED]) >I was trying 2.4.1 kernel but under some IO load (bonnie++) Me too, same messages... >DMA gets disabled with following messages: hda: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout func only: 14 my dmesg: ide: Assuming 33MHz system bus speed for PIO modes ALI15X3: IDE controller on PCI bus 00 dev 80 ALI15X3: chipset revision 195 ALI15X3: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x6050-0x6057, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x6058-0x605f, BIOS settings: hdc:DMA, hdd:pio hda: IBM-DJSA-210, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 11733120 sectors (6007 MB) w/384KiB Cache, CHS=730/255/63, UDMA(33) an other chipset but the same problem... There are more ide_dma_timeout problems known with other chipsets. It seems to be an chipset independent problem, it exits also in 2.4.0, (see http://boudicca.tux.org/hypermail/linux-kernel/2001week02/1429.html) and in 2.4.1-ac9. Are any fixes known? p.s. Please cc: me explicitly, because i am not on the list. thanks Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Hot swap CPU support for 2.4.1
In message <[EMAIL PROTECTED]> you write:
> This is not quite right:
>
> @@ -1643,7 +1643,7 @@
> printk(KERN_NOTICE "apm: disabled on user
> request.\n");
> return -ENODEV;
> }
> - if ((smp_num_cpus > 1) && !power_off) {
> + if ((num_online_cpus() > 1) && !power_off) {
> printk(KERN_NOTICE "apm: disabled - APM is not SMP
>
> I do not think it is safe to call APM when there is just CPU #5
> running. smp_num_cpus in this context means "if we ever had more than
> boot cpu".
Um, it's not safe to call APM in SMP full stop: we try anyway.
However, this code changes nothing since it's only run at boot.
Cheers,
Rusty.
--
Premature optmztion is rt of all evl. --DK
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.1-ac10 compile error
Hello, I received the following while compiling 2.4.1-ac10: ... make[3]: *** No rule to make target '/usr/src/linux/drivers/pci/devlist.h', needed by names.o'. Stop make[3]: Leaving directory '/usr/src/linux/drivers/pci' make[2]: *** [first_rule] Error 2 ... I haven't looked into it, but the addition was between 2.4.1-ac9 and 2.4.1-ac10. 2.4.2-pre3 didn't have this problem. Regards, Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Major Clock Drift
Alan Cox wrote: > > > Hmm, I can make it loose 30 seconds in 12 seconds. Just cat > > /etc/termcap. Vesafb does this kind of stuff. [Yes, 3 times slower > > clock]. > > Why are interrupts being disabled for vesafb scrolling anyway ? Console writes happen under spin_lock_irq(console_lock). The only reason for this which I can see: the kernel can call printk() from interrupt context. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Slowing down CDROM drives (was: Re: ATAPI CDRW which doesn'twork)
Sorry. it was late when I answered that. (Either that or no ocffe, not certain which.) On Sun, 11 Feb 2001, Jens Axboe wrote: > On Sun, Feb 11 2001, Alan Olsen wrote: > > > It's no news that vendors only implement what they want to. New > > > cd-r/w and dvd drives are not required to implement this command, > > > so it may not work there either. > > > > Take a look at the code for cdparanoia or one of the other MP3 ripping > > programms. Slowing down the drive is a standard feature for that type of > > program. (Reduces errors when pulling audio tracks off the disc.) > > One would think that you have taken a look at the cdparanoia > source before posting something like this. Guess what it does to > control speed? Reread my message, you totally missed the point. > > -- > Jens Axboe > > [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
online gambling goes MLM
Fortunes are being made online everyday! Now is your chance to become involved with one of the most explosive Internet industries...Internet Gaming! But wait there is much more...LIVE Webcast Lotto and Bingo, International Sports Betting, and Virtual Stock Trading. We are PLAYING GAMES, HAVING FUN AND MAKING MONEY! How are we making money? We do it with the most RED HOT compensation plan ever seen in the industry...our NO-FLUSH Binary with incredible matching bonuses.Anyone can do this! You could be earning everytime someone you introduce plays a game. This is a Worldwide opportunity and it is EXPLOSIVE! Check it out at: http://ujgf.pokeadot.com To be removed send an email to: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Alan Cox wrote: > > > LADDIS is the industry standard benchmark for NFS. It crashes for ReiserFS and > > NFS. We can't afford to buy it, as it is proprietary software. Once Nikita has > > finished testing his changes, we will ask someone to test it for us though. > > > > Do you know if the connectathon test suites show the problem? Not the slightest idea. Is the connectathon test suite something that stresses the FS heavily? If so, we can always add it to our stable, whether or not it stresses this particular bug. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Slowing down CDROM drives (was: Re: ATAPI CDRW which doesn't work)
On Sun, Feb 11 2001, Alan Olsen wrote: > > It's no news that vendors only implement what they want to. New > > cd-r/w and dvd drives are not required to implement this command, > > so it may not work there either. > > Take a look at the code for cdparanoia or one of the other MP3 ripping > programms. Slowing down the drive is a standard feature for that type of > program. (Reduces errors when pulling audio tracks off the disc.) One would think that you have taken a look at the cdparanoia source before posting something like this. Guess what it does to control speed? Reread my message, you totally missed the point. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.1ac10
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 2.4.1-ac10 o Merge with Linus 2.4.2pre3 o More net driver clean up(Jeff Garzik) o Further maxiradio fix (Francois Romieu) o Lock reclaiming fixes (MCL) o Update ver_linux(Steven Cole) o Add support for the Socket LP-E CF+ ethernet(Nicolas Pitre) o Fix microtek scanner abort handling (Oliver Neukum) o Fix very dumb bug in my dma.c changes that (me) Linus noticed o Clean up AGP alloc/destroy a little (me) | Again a Linus request o Remove dead 8129 config help(Dave Jones) o Clean up extra unneeded check in setup.c(Dave Jones) o Improve mkdep, remove acpi special case (Keith Owens) o Fix bogus dead comment in fs.h (Jens Axboe) o Clean up config.in syntax errors(Christoph Hellwig) o Offer Duron in CPU option list for clarity (Terje Rosten) o New binutils need --oformat, old ones handle it (Andreas Jaeger) o Move bitops include in fs.h inside __KERNEL__ (Herbert Xu) o Fix misspellings of weird (Felix Odenkirchen) o Fix typos of 'valid' while we are at it (Luuk van der Duim) 2.4.1-ac9 o Merge with Linus 2.4.2pre2 o Highmem bounce fixes(Ingo Molnar) o Fix cosa driver kfree (Jan Kasprzak) o Clean up pdoc202xx driver sleeps(Vojtech Pavlik) o Final bits of NFS file handle changes (Trond Myklebust) o Fix usbnet driver (David Brownell) o ATM includes fixes (Werner Almesberger) o Remove unneeded vm_enough_memory check (Werner Almesberger) o Fix free_dma prototype case (Bill Nottingham) o Fix build bugs from pci_match_device fix(me) o HP5300 USB scanner driver (Oliver Neukum, John Fremlin, Jeremy Hall) o DSP_SETFRAGMENT fixes for ymfpci(Pavel Roskin) o Fix codafs error returns(Rob Radez) o Fix 48 misspellings of interrupt(André Dahlqvist) o Fix 20 misspellings of successful (André Dahlqvist) o Fix 11 misspellings of suppress (André Dahlqvist) o Fix 46 misspellings of address (André Dahlqvist) o Fix 26 misspellings of receive (André Dahlqvist) o Fix 7 misspellings of acquire (André Dahlqvist) o Fix 4 misspellings of unneccessary (André Dahlqvist) o Fix 13 misspellings of until(André Dahlqvist) 2.4.1-ac8 o Fix irlap speed changes and kfrees (Jean Tourrilhes) o Further NTFS updates(Anton Altaparmakov, Yuri Per, Rob Radez) o Fix buglets in config.in for aic7xxx (Andrzej Krzysztofowicz) o Cleanup irda QoS code (Jean Tourrilhes) o Fix mca documentations (Rob Radez) o Fix irlan device attach problems(Dag Brattli) o Fix irda dongle crash case (Dag Brattli) o Change Kaweth firmware loading, add DU-E10 (Eric Sandeen) o pci_enable cleanups for networking (Jeff Garzik) o Fix rcpci45 probing (Jeff Garzik) o Use SET_MODULE_OWNER() in lanstreamer (Jeff Garzik) o Use pcmcia defines as per seperate pcmcia net (Jeff Garzik) o Fix people calling netif_start_queue from a (Jeff Garzik) timeout o Remove 8129 driver (use 8139too)(Jeff Garzik) o Remove dead malloc.h from net drivers (Jeff Garzik) o Update eata driver to 6.04 (Dario Ballabio) o Add DE320 support to ne2.c (Alfred Arnold) o Kernel hacking doc updates (John Levon) o Fix CPU detection offsets in head.S (Mikael Pettersson) o Fix apic init/cpu detect problems (Mikael Pettersson) 2.4.1-ac7 o Rebalance the 2.4.1 VM (Rik van Riel) | This should make things feel a lot faster especially | on small boxes .. feedback to Rik o Silence osf syscall error printk(Ivan Kokshaysky) o Don't trust ARC irq routing on ruffian (Ivan Kokshaysky) o Report the right module on 3c59x for pcmcia (Arj
Re: 2.4.2-pre3 compile error in 6pack.c
Alan Cox wrote:
>
> > Do you really prefer if drivers contain a
> >
> > static inline void* safe_kmalloc(size, flags)
> > {
> > if(size > LIMIT)
> > return NULL;
> > return kmalloc(size, flags);
> > }
>
> It isnt that simple. Look at af_unix.c for example. It needs to know the
> maximum safe request size to set values up and is prepared to accept
> smaller values if that fails
>
Ok, I just downloaded -ac9.
Hmm.
What about removing -16 instead of increasing it to 64?
The slab allocator is perfect for power of 2 allocations!
The slab descriptors are stored outside in seperate buffers.
And why KMALLOC_SIZE/2?
"Keep 2 messages in ..."?
Btw, sock_alloc_send_skb() (net/core.c) still uses the wrong allocation
mode for "size":
GFP_BUFFER both sleeps and uses the atomic queue.
skb = alloc_skb(size, sk->allocation & (~__GFP_WAIT));
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19pre9
Was there an anouncement for pre9? Did I miss it? Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: SO_LINGER + shutdown() does not block?
On Sun, Feb 11, 2001 at 09:05:07PM +, Chris Evans wrote: > > On Sun, 11 Feb 2001, Andi Kleen wrote: > > > On Sun, Feb 11, 2001 at 08:41:04PM +, Chris Evans wrote: > > > > > > [cc: Andi] > > > > Missing context.. > > [...] > > > What do you exactly think is wrong? > > man socket(7) says that setting SO_LINGER on a socket will make shutdown() > and close() block. That's incorrect; only close() blocks. Ok, fixed. Thanks. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: SO_LINGER + shutdown() does not block?
On Sun, 11 Feb 2001, Andi Kleen wrote: > On Sun, Feb 11, 2001 at 08:41:04PM +, Chris Evans wrote: > > > > [cc: Andi] > > Missing context.. [...] > What do you exactly think is wrong? man socket(7) says that setting SO_LINGER on a socket will make shutdown() and close() block. That's incorrect; only close() blocks. Sorry for the missing context. Cheers Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: small patch for unsigned char breakage in rtl8129 driver
Alan Cox wrote: > > > - char phys[4]; /* MII device >addresses. */ > > + signed char phys[4];/* MII device addresses. */ > > 8129 is deprecated for the current 8139too driver which is the only stable > driver for it. Does 8139too (from current -ac) work on ARM ? I've gotten at least one report that it does Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: SO_LINGER + shutdown() does not block?
On Sun, Feb 11, 2001 at 08:41:04PM +, Chris Evans wrote: > > [cc: Andi] Missing context.. > > On Sun, 11 Feb 2001 [EMAIL PROTECTED] wrote: > > > Hello! > > > > > I'm not seeing shutdown(2) block on a TCP socket. This is Linux kernel > > > 2.2.16 (RH7.0). Is this a kernel bug, a documentation bug, > > > > Man page is wrong. > > Yes, man socket(7) seems to be wrong. What do you exactly think is wrong? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre3 compile error in 6pack.c
> Do you really prefer if drivers contain a
>
> static inline void* safe_kmalloc(size, flags)
> {
> if(size > LIMIT)
> return NULL;
> return kmalloc(size, flags);
> }
It isnt that simple. Look at af_unix.c for example. It needs to know the
maximum safe request size to set values up and is prepared to accept
smaller values if that fails
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: SO_LINGER + shutdown() does not block?
[cc: Andi] On Sun, 11 Feb 2001 [EMAIL PROTECTED] wrote: > Hello! > > > I'm not seeing shutdown(2) block on a TCP socket. This is Linux kernel > > 2.2.16 (RH7.0). Is this a kernel bug, a documentation bug, > > Man page is wrong. Yes, man socket(7) seems to be wrong. I don't have access to a genuine BSD at the moment, but from man pages: - HP/UX specifically states that SO_LINGER has no effect on shutdown() - Solaris SO_LINGER only mentions that close() is affected. - Likewise FreeBSD Cheers Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] framework for fpu usage in kernel
> What if a drm module wants to use the fpu and then uses memcpy() after > modifying the ftp registers? Interesting question. Right now the answer is dont do that. Point noted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre3 compile error in 6pack.c
Alan Cox wrote:
>
> > > Would it be costly/reasonable to have kmalloc -not- panic if given a
> > > too-large size? Principle of Least Surprises says it should return NULL
> > > at the very least.
> >
> > It's on purpose; to find the erroneous drivers.
>
> Unfortunately Linus forgot to provide a way to check if a kmalloc is too
> large so the drivers cannot work around it. Dave put an incredibly ugly
> constant assumption in af_unix for this and no doubt more will follow.
>
> So -ac added the constant
>
What about removing the BUG?
I means all drivers should be aware that kmalloc() > 16 kB fail quite
often.
kmalloc() over 128 kB always fail.
Do you really prefer if drivers contain a
static inline void* safe_kmalloc(size, flags)
{
if(size > LIMIT)
return NULL;
return kmalloc(size, flags);
}
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre3 compile error in 6pack.c
> > printk a message and fail the call. Don't panic. > > Perhaps add a compile time warning, similar to __bad_udelay(); > The BUG is a bad idea. They are all dynamic allocations - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: race in autofs / nfs
Olaf Hering wrote: > > Hi, > > there is a race in 2.4.1 and 2.4.2-pre3 in autofs/nfs. > When the cwd is on the nfs mounted server (== busy) and you try to > reboot the shutdown hangs in "rcautofs stop". I can reproduce it everytime. > Sounds like an NFS bug in umount. -=hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] framework for fpu usage in kernel
Alan Cox wrote:
>
> > memcopy is a really generic function, and calling it saves the current
> > fpu state into thread.i387.f{,x}save. IMHO that's wrong, memcopy must
> > save into a local buffer like raid5 checksumming.
>
> The mmx copy is only done in task context. There are a whole variety
> of _horrible_ problems doing it in interrupt space so based on the
> considerable number of problems with prior attempts to get it right on
> IRQ and copyuser cases I didnt bother
>
Even task context is dangerous:
What if a drm module wants to use the fpu and then uses memcpy() after
modifying the ftp registers?
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: small patch for unsigned char breakage in rtl8129 driver
> - char phys[4]; /* MII device >addresses. */ > + signed char phys[4];/* MII device addresses. */ 8129 is deprecated for the current 8139too driver which is the only stable driver for it. Does 8139too (from current -ac) work on ARM ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre3 compile error in 6pack.c
> > Would it be costly/reasonable to have kmalloc -not- panic if given a > > too-large size? Principle of Least Surprises says it should return NULL > > at the very least. > > It's on purpose; to find the erroneous drivers. Unfortunately Linus forgot to provide a way to check if a kmalloc is too large so the drivers cannot work around it. Dave put an incredibly ugly constant assumption in af_unix for this and no doubt more will follow. So -ac added the constant Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre3 compile error in 6pack.c
Jeff Garzik wrote: > > > printk a message and fail the call. Don't panic. > Perhaps add a compile time warning, similar to __bad_udelay(); The BUG is a bad idea. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] framework for fpu usage in kernel
> memcopy is a really generic function, and calling it saves the current
> fpu state into thread.i387.f{,x}save. IMHO that's wrong, memcopy must
> save into a local buffer like raid5 checksumming.
The mmx copy is only done in task context. There are a whole variety
of _horrible_ problems doing it in interrupt space so based on the
considerable number of problems with prior attempts to get it right on
IRQ and copyuser cases I didnt bother
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: SO_LINGER + shutdown() does not block?
Hello! > I'm not seeing shutdown(2) block on a TCP socket. This is Linux kernel > 2.2.16 (RH7.0). Is this a kernel bug, a documentation bug, Man page is wrong. What's about kernel... Hmm, actually, it is worth to test genuine bsd. Such feature could be useful. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Re[2]: Where are you going with 2.4.x?
> Alan> driver. Also did you build the DAC960 support with gcc 2.96-x x<74 ? > My system compiler is: >gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) > Shoud I upgrade it to gcc 2.95.x or 2.96.x? No that one is fine. I have a known problem with DAC960 and cvs gcc or gcc 2.96.x x<74 where struct sizes change and it doesnt work. > On the next crash I'll try write down all traces. > BTW, is there some way to log it somewhere to file? On a crash we don't log it to a file. The problem is that you cannot be sure of the state of the system so your logging might itself crash or do more harm. The important bit is the EIP value and the call trace. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
race in autofs / nfs
Hi, there is a race in 2.4.1 and 2.4.2-pre3 in autofs/nfs. When the cwd is on the nfs mounted server (== busy) and you try to reboot the shutdown hangs in "rcautofs stop". I can reproduce it everytime. I attach a screen log and a decoded sysrq output. It is not related to that killproc, it hangs right now in automount <-> kupdate (with kernel 2.4.1): kupdate600 -1 ? c307a000 0 current automoun 152531480 503680 54 u0176a368 df3e6000 1 current there is a spinlock message: _spin_lock(c021f6e4) CPU#1 NIP c01b8220 holder: cpu 1 pc E126BF28 c021f6e4 is not in the System.map, but c01b8220 is c01b817c T memparse c01b8200 T atomic_dec_and_lock c01b9a5c t cleanup_proc_rtas The attached log is kernel 2.4.2-pre3. killproc 1701 1030738 16491808 106 u0178d5c8 c7de6000 0 current automoun 1705 1036120 16577920 54 u0176a368 c7b46000 1 current _spin_lock(c022279c) CPU#1 NIP c01b7c5c holder: cpu 1 pc E126BF28 SysRq: Emergency Sync _spin_lock(c022279c) CPU#0 NIP c005d920 holder: cpu 1 pc E126BF28 _spin_lock(c022279c) CPU#1 NIP c01b7c5c holder: cpu 1 pc E126BF28 c01b7c5c is again atomic_dec_and_lock and c005d920 is d_lookup. The system is a 2way RS/6000, 2gig ram. Linux cantaloupe 2.4.1-SMP #1 SMP Sun Feb 11 13:02:05 GMT 2001 ppc unknown Kernel modules 2.4.1 Gnu C 2.95.2 Gnu Make 3.79.1 Binutils 2.10.0.33 Linux C Libraryx1 root root 1499361 Feb 9 02:50 /lib/libc.so.6 Dynamic linker ldd (GNU libc) 2.2 Procps 2.0.7 Mount 2.10q Net-tools 1.57 Kbd1.02 Sh-utils 2.0 Modules Loaded nfsd autofs4 ipv6 Any ideas what could be wrong? Gruss Olaf -- $ man clone BUGS Main feature not yet implemented... screenlog.0.crash.gz blah.txt.gz
Re: 2.4.2-pre3 compile error in 6pack.c
David Weinehall wrote: > > On Sun, Feb 11, 2001 at 02:59:13PM -0500, Jeff Garzik wrote: > > Alan Cox wrote: > > > > > > > 2.4.2-pre3 doesn't compile with 6pack as a module; I had to disable it; > > > > now it compiles (and so far, works fine). > > > > > > It has a slight dependancy on -ac right now. > > > > > > KMALLOC_MAXSIZE is the alloc size limit - 131072. It checks this as kmalloc > > > now panics if called with an oversize request > > > > Would it be costly/reasonable to have kmalloc -not- panic if given a > > too-large size? Principle of Least Surprises says it should return NULL > > at the very least. > > It's on purpose; to find the erroneous drivers. Oh good grief. You will never find all such drivers. Dynamic memory allocation is by its definition dynamic. Alloc size is often selected at runtime based on a variety of factors. printk a message and fail the call. Don't panic. We have a system in place to notify calls when kmalloc fails -- return value. Use that, it's what its there for... Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
small patch for unsigned char breakage in rtl8129 driver
--- linux/drivers/net/rtl8129.c Sat Nov 4 16:42:22 2000
+++ linux/drivers/net/rtl8129.c Sat Nov 4 16:48:21 2000
@@ -271,7 +271,7 @@ struct rtl8129_private {
unsigned char *tx_bufs; /* Tx bounce buffer region. */
dma_addr_t rx_ring_dma;
dma_addr_t tx_bufs_dma;
- char phys[4]; /* MII device
addresses. */
+ signed char phys[4];/* MII device addresses. */
char twistie, twist_cnt;/* Twister tune state. */
unsigned int tx_full:1; /* The Tx queue is full. */
unsigned int full_duplex:1; /* Full-duplex operation
requested. */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.1, slhc as a module
The makefile in drivers/net goes like this: obj-$(CONFIG_SLIP) += slip.o ifeq ($(CONFIG_SLIP),y) obj-$(CONFIG_SLIP_COMPRESSED) += slhc.o else ifeq ($(CONFIG_SLIP),m) obj-$(CONFIG_SLIP_COMPRESSED) += slhc.o endif endif CONFIG_SLIP_COMPRESSED is a `bool' value. The way the makefile is written, selecting compression will always build slhc.o into the kernel, even if SLIP is a module. This doesn't seem like the way it ought to work. p. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Raw devices bound to RAID arrays ?
Hi, On Sun, Feb 11, 2001 at 06:29:12PM +0200, Petru Paler wrote: > > Is it possible to bind a raw device to a software RAID 1 array ? Yes. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Slowing down CDROM drives (was: Re: ATAPI CDRW which doesn'twork)
On Sun, 11 Feb 2001, Jens Axboe wrote: > On Sat, Feb 10 2001, Pavel Machek wrote: > > > ioctl(cd_fd, CDROM_SELECT_SPEED, speed); > > > > Does this actually work? I helped my friend with partly broken cdrom > > (worked only at low speeds) and it did not have much effect. It did > > not make my cdrom quiet, either, AFAI can remember. > > It's no news that vendors only implement what they want to. New > cd-r/w and dvd drives are not required to implement this command, > so it may not work there either. Take a look at the code for cdparanoia or one of the other MP3 ripping programms. Slowing down the drive is a standard feature for that type of program. (Reduces errors when pulling audio tracks off the disc.) [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre3 compile error in 6pack.c
On Sun, Feb 11, 2001 at 02:59:13PM -0500, Jeff Garzik wrote: > Alan Cox wrote: > > > > > 2.4.2-pre3 doesn't compile with 6pack as a module; I had to disable it; > > > now it compiles (and so far, works fine). > > > > It has a slight dependancy on -ac right now. > > > > KMALLOC_MAXSIZE is the alloc size limit - 131072. It checks this as kmalloc > > now panics if called with an oversize request > > Would it be costly/reasonable to have kmalloc -not- panic if given a > too-large size? Principle of Least Surprises says it should return NULL > at the very least. It's on purpose; to find the erroneous drivers. /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
Re: linux-logo.h
On 11 Feb 2001 19:14:58 +, Ryan Hairyes wrote: > Hello All, > > Could anyone tell me about linux_logo.h. I want to put my > own picture in there. What format is the picture written in? > Any any idea on how I could change it? Also, could the > picture be any bigger than 80x80, I would like for it to take > up the whole screen. > > Thanks in advance. Search for a program called fblogo. Sorry, I don't have a link handy, but it's widely avaliable. Thanks, Brad Douglas [EMAIL PROTECTED] http://www.linux-fbdev.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre3 compile error in 6pack.c
Alan Cox wrote: > > > 2.4.2-pre3 doesn't compile with 6pack as a module; I had to disable it; > > now it compiles (and so far, works fine). > > It has a slight dependancy on -ac right now. > > KMALLOC_MAXSIZE is the alloc size limit - 131072. It checks this as kmalloc > now panics if called with an oversize request Would it be costly/reasonable to have kmalloc -not- panic if given a too-large size? Principle of Least Surprises says it should return NULL at the very least. Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Alan Cox <[EMAIL PROTECTED]> writes: > > LADDIS is the industry standard benchmark for NFS. It crashes for ReiserFS and > > NFS. We can't afford to buy it, as it is proprietary software. Once Nikita has > > finished testing his changes, we will ask someone to test it for us though. > > > > Do you know if the connectathon test suites show the problem? The reiserfs nfs problem in standard 2.4 is very simple -- it'll barf as soon as you run out of file handle/inode cache. Any workload that accesses enough files in parallel can trigger it. Fixes do exist, but require bigger changes in nfsd. Basically you need to hand out an 64bit inode in the nfs filehandle, and pass the upper 32bits to the low level file system for efficient lookup (actually is all not too difficult to implement, just requires very uncodefreezefriendly changes to nfsd) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
mail loop
On Sun, 11 Feb 2001, Ben Ford wrote: > Roger Larsson wrote: > > > OK, you had to... > > > > I have not seen any emails from linux-kernel for some days. > > Even tried to resubscribe - Majordomo succeeded in sending me the Confirmation > > > > But nothing... > > > > I must be getting all yours then!! Seriously, something's broke, I am getting > duplicates of *every* *freaking* lkml message!! > > -b That would be because we have a mail loop at techconsult.de ... Received: from sys04.firma.ks ([213.252.152.243]) by mail2.cunet.de (8.11.2/8.11.2) with ESMTP id f1BHII811768; Sun, 11 Feb 2001 18:18:19 +0100 Received: from router.techconsult.de (router [192.168.1.4]) by sys04.firma.ks with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1WFYLRCL; Sun, 11 Feb 2001 18:38:23 +0100 -- 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] Please read the FAQ at http://www.tux.org/lkml/
[RFC] framework for fpu usage in kernel
Currently there are 2 fpu users in the kernel:
raid5 checksumming and 3dnow memcpy/memset.
raid5 checksumming is not problematic, but _mmx_memcpy() has unexpected
side effects if someone else is also using the fpu:
memcopy is a really generic function, and calling it saves the current
fpu state into thread.i387.f{,x}save. IMHO that's wrong, memcopy must
save into a local buffer like raid5 checksumming.
I've attached a proposal that supports arbitrary combinations of fpu
users in kernel space.
* kernel threads can use the fpu freely. Nothing new.
* 2 sets of functions for fpu usage in "normal" threads:
- kfpu_acquire(), kfpu_try_acquire() + release functions.
- kfpu_full_begin(), kfpu_mmx_begin(), kfpu_nosave_begin(),
kfpu_try_begin() + _end() functions.
The first set is only possible from normal process context. The caller
can sleep between _acquire() and _release().
The second set can be called from arbitrary context, but the caller must
not sleep between _begin() and _end().
The _try() functions check if the fpu is unused, and fail if the fpu is
currently in use. That way the memcpy()/memset() functions can avoid fpu
context saves/restores and it saves stack space.
Nesting is partially possible: _begin() within _acquire is possible,
_acquire() within _begin() will BUG.
[_acquire()/_release() have similar restrictions as down() and up(),
_begin()/_end() have similar restrictions as spinlocks]
The patch itself is alpha quality: only the sse functions are tested, it
boots when compiled for Pentium III, the raid5 checksum _benchmark_
still works and distributed.net still cracks rc5.
I haven't yet checked that the exception handlers are still called
properly.
What do you think?
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
// SUBLEVEL = 1
// EXTRAVERSION =
diff -urN 2.4/include/asm-i386/i387.h build-2.4/include/asm-i386/i387.h
--- 2.4/include/asm-i386/i387.h Fri Feb 2 15:20:36 2001
+++ build-2.4/include/asm-i386/i387.h Sun Feb 11 19:40:45 2001
@@ -16,6 +16,7 @@
#include
#include
+#include
extern void init_fpu(void);
/*
* FPU lazy state save handling...
@@ -23,9 +24,7 @@
extern void save_init_fpu( struct task_struct *tsk );
extern void restore_fpu( struct task_struct *tsk );
-extern void kernel_fpu_begin(void);
-#define kernel_fpu_end() stts()
-
+#include
#define unlazy_fpu( tsk ) do { \
if ( tsk->flags & PF_USEDFPU ) \
@@ -36,7 +35,7 @@
if ( tsk->flags & PF_USEDFPU ) { \
asm volatile("fwait"); \
tsk->flags &= ~PF_USEDFPU; \
- stts(); \
+ kfpu_leave(); \
} \
} while (0)
diff -urN 2.4/include/asm-i386/kfpu.h build-2.4/include/asm-i386/kfpu.h
--- 2.4/include/asm-i386/kfpu.h Thu Jan 1 01:00:00 1970
+++ build-2.4/include/asm-i386/kfpu.h Sun Feb 11 19:59:51 2001
@@ -0,0 +1,83 @@
+#ifndef _ASM_KFPU_H
+#define _ASM_KFPU_H
+
+/*
+ * FPU support for kernel threads
+ *
+ * currently limited to MMX, SSE and SSE2.
+ * x87 and fpu emulation are not supported.
+ */
+
+/**/
+/*
+ * Enable full fpu access.
+ * Only for kernel threads.
+ */
+void kfpu_start(void);
+
+
+/**/
+/*
+ * Get full fpu access.
+ *
+ * Only permitted from process context.
+ * Caller must check that the FPU is present before calling.
+ */
+struct kfpubuf_acquire {
+ unsigned long saved;
+ unsigned char buffer[512+16];
+} kfpubuf_acquire;
+
+void kfpu_acquire(struct kfpubuf_acquire *buf);
+void kfpu_release(struct kfpubuf_acquire *buf);
+
+/* returns 1 if it got fpu access, 0 otherwise */
+int kfpu_try_acquire(void);
+void kfpu_try_release(void);
+
+
+/**/
+/*
+ * Get short term fpu access.
+ *
+ * The functions can be called from any context (process,
+ * softirq, interrupt)
+ * Caller must check that the FPU is present before calling.
+ * The caller must not sleep between _begin() and _end()
+ */
+struct kfpubuf_full {
+ unsigned char buffer[512];
+};
+
+struct kfpubuf_mmx {
+ unsigned char buffer[108];
+};
+
+void kfpu_full_begin(struct kfpubuf_full *buf);
+void kfpu_mmx_begin(struct kfpubuf_mmx *buf);
+/*
+ * ret val 0: caller doesn't need to save clobbered regs
+ * ret val !0: the caller must save & restore any clobbered
+ * fpu registers.
+ * This function DOES NOT reinitialize the fpu!
+ */
+int kfpu_nosave_begin(void);
+
+void kfpu_full_end(struct kfpubuf_full *buf);
+void kfpu_mmx_end(struct kfpubuf_mmx *buf);
+void kfpu_nosave_end(void);
+
+/* returns 1 if it got fpu access */
+int kfpu_try_begin(void);
+void kfpu_try_end(void);
+
+/**/
+
+/* internal function, called by math_state_restore() */
+void kfpu_enter(void);
+/* internal function, called by save_init_fpu() */
+void kfpu_leave(void);
+/* internal function, called by cpu_init() */
+void kfpu_initialize(void);
+
+#endif
diff -urN 2.4/include/asm-i386/page.h buil
BUG: SO_LINGER + shutdown() does not block?
Hi, >From socket(7): SO_LINGER ... When enabled, a close(2) or shutdown(2) will not return until all queued messages for the socket have been successfully sent or the linger timeout has been reached. I'm not seeing shutdown(2) block on a TCP socket. This is Linux kernel 2.2.16 (RH7.0). Is this a kernel bug, a documentation bug, or does it all work fine and it's a Chris bug? Cheers Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.1-ac7
On Sun, 11 Feb 2001, Rik van Riel wrote: > On Sun, 11 Feb 2001, Mike Galbraith wrote: > > On Sun, 11 Feb 2001, Mike Galbraith wrote: > > > > > Something else I see while watching it run: MUCH more swapout than > > > swapin. Does that mean we're sending pages to swap only to find out > > > that we never need them again? > > > > (numbers might be more descriptive) > > > > user : 0:07:21.70 54.3% page in : 142613 > > nice : 0:00:00.00 0.0% page out: 155454 > > system: 0:03:40.63 27.1% swap in :56334 > > idle : 0:02:30.50 18.5% swap out: 149872 > > uptime: 0:13:32.83 context : 519726 > > Indeed, in this case we send a lot more pages to swap > than we read back in from swap, this means that the > data is still sitting in swap space and was never needed > again. But it looks and feels (box is I/O hyper-saturated) like it wrote it all to disk. (btw, ac5 does more disk read.. ie the reduced cache size of earlier kernels under heavy pressure does have it's price with this workload.. quite visible in agregates. looks to be much cheaper than swap though.. for this workload) -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Slowing down CDROM drives (was: Re: ATAPI CDRW which doesn't work)
On Feb 10 2001, Pavel Machek wrote: > Hi! > > > ioctl(cd_fd, CDROM_SELECT_SPEED, speed); > > Does this actually work? I helped my friend with partly broken cdrom > (worked only at low speeds) and it did not have much effect. It did > not make my cdrom quiet, either, AFAI can remember. Well, I wrote a little program that just makes this call that Jens told me about and it worked perfectly with my hardware -- using my CD-ROM drive at speed 1, 2 or 4, it works quietly and I can listen to MP3s at volumes that I couldn't earlier. OTOH, it seems that a paradox is happening: this very same drive has some problems (not always reproducible) reading some CD-RW discs when it operates at very slow speeds. In this case, the best that I can do is to let the drive accelerate as much as it wants and then it works ok. BTW, Jens, what is the way to set the drive back to its maximum speed, without limits? Where could I read more about the subject (that is, this and other ioctl's) without annoying you? I'm a moderately competent C programmer (only moderately), but I know *nothing* about the kernel. []s, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
linux-logo.h
Hello All, Could anyone tell me about linux_logo.h. I want to put my own picture in there. What format is the picture written in? Any any idea on how I could change it? Also, could the picture be any bigger than 80x80, I would like for it to take up the whole screen. Thanks in advance. Ryan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Where are you going with 2.4.x?
On Sun, Feb 11, 2001 at 08:01:48PM +0200, Andriy Korud wrote: > Alan> What is the oops data before the kernel panic. I need that to debug the > Alan> driver. Also did you build the DAC960 support with gcc 2.96-x x<74 ? > My system compiler is: >gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) > Shoud I upgrade it to gcc 2.95.x or 2.96.x? > > And since my last post 2.4.1-ac8 crashed again with: > kswapd: Cannot dereference NULL pointer. > > On the next crash I'll try write down all traces. > BTW, is there some way to log it somewhere to file? Considering this is an enterprise-server, you should have a serial-console to it; this will allow you to log all error-messages. Alternatively (not as nice, though), is to connect a printer to the parallel-port and use the parallelconsole option. Then there's always the LKCD-patches, by SGI, if I'm not all wrong. /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
2.2.x: TCP lockups with tcp_timestamps
TCP connections between two machines (both running Linux 2.2.x) are
freezing. If /proc/sys/net/ipv4/tcp_timestamps is set to 0, the
problem disappears.
Machine (IP address 1.2.3.4) is running kernel 2.2.13 and dials in
over an annoyingly high-latency PPP link via ordinary modems.
Machine (IP address 5.6.7.8) connects via a cable modem and is running
RH6.2 and kernel 2.2.14.
The problem is reproducible. I've pasted a tcpdump trace, taken
from the 1.2.3.4 machine, below. Also have the trace of the other
end if needed. The application in this case is vpnd, but the problem
also seems to appear when using ssh and www, etc.
Note that things get stuck at seq # 16528... By adding some printk's was
able to determine that the following code in tcp_input.c is triggered, on
the 5.6.7.8 machine...
* RFC1323: H1. Apply PAWS check first.
*/
if (tcp_fast_parse_options(sk, th, tp)) {
if (tp->saw_tstamp) {
if (tcp_paws_discard(tp, th, len)) {
This gets hit --->>>tcp_statistics.TcpInErrs++;
Since there's an easy workaround, it apparently makes no difference to
me if it's ever fixed. However, I'd be happy to supply information or
help in any way needed.
Max
[beginning part redacted, please notify if more info needed]
[also have trace of other end if needed]
20:29:34.730716 1.2.3.4.379 > 5.6.7.8.1053: P 16364:16468(104) ack 65097 win 31856
(DF)
20:29:35.115762 5.6.7.8.1053 > 1.2.3.4.379: . 65097:65097(0) ack 16468 win 32120
(DF)
20:29:35.155767 5.6.7.8.1053 > 1.2.3.4.379: P 65097:65157(60) ack 16468 win 32120
(DF)
20:29:35.155818 5.6.7.8.1053 > 1.2.3.4.379: P 65157:65211(54) ack 16468 win 32120
(DF)
20:29:35.175778 1.2.3.4.379 > 5.6.7.8.1053: . 16468:16468(0) ack 65211 win 31856
(DF)
20:29:35.179648 1.2.3.4.379 > 5.6.7.8.1053: P 16468:16528(60) ack 65211 win 31856
(DF)
20:29:35.535768 5.6.7.8.1053 > 1.2.3.4.379: P 65211:66288(1077) ack 16468 win 32120
(DF)
20:29:35.925800 1.2.3.4.379 > 5.6.7.8.1053: . 16528:16528(0) ack 66288 win 31856
(DF)
20:29:35.929720 1.2.3.4.379 > 5.6.7.8.1053: P 16528:16588(60) ack 66288 win 31856
(DF)
20:29:35.995781 5.6.7.8.1053 > 1.2.3.4.379: . 66288:66288(0) ack 16528 win 32120
(DF)
20:29:36.305771 5.6.7.8.1053 > 1.2.3.4.379: . 66288:66288(0) ack 16528 win 32120
(DF)
20:29:36.695769 5.6.7.8.1053 > 1.2.3.4.379: P 66288:67415(1127) ack 16528 win 32120
(DF)
20:29:36.702543 1.2.3.4.379 > 5.6.7.8.1053: P 16588:16648(60) ack 67415 win 31856
(DF)
20:29:36.923237 1.2.3.4.379 > 5.6.7.8.1053: P 16648:16752(104) ack 67415 win 31856
(DF)
20:29:37.215797 5.6.7.8.1053 > 1.2.3.4.379: . 67415:67415(0) ack 16528 win 32120
(DF)
20:29:37.225784 5.6.7.8.1053 > 1.2.3.4.379: . 67415:67415(0) ack 16528 win 32120
(DF)
20:29:37.225872 1.2.3.4.379 > 5.6.7.8.1053: P 16528:16648(120) ack 67415 win 31856
(DF)
20:29:37.830074 1.2.3.4.379 > 5.6.7.8.1053: P 16752:16856(104) ack 67415 win 31856
(DF)
20:29:37.835833 5.6.7.8.1053 > 1.2.3.4.379: . 67415:67415(0) ack 16528 win 32120
(DF)
20:29:38.105797 5.6.7.8.1053 > 1.2.3.4.379: . 67415:67415(0) ack 16528 win 32120
(DF)
20:29:38.635785 5.6.7.8.1053 > 1.2.3.4.379: P 66288:67415(1127) ack 16528 win 32120
(DF)
20:29:38.635869 1.2.3.4.379 > 5.6.7.8.1053: . 16856:16856(0) ack 67415 win 31856
(DF)
20:29:39.295770 5.6.7.8.1053 > 1.2.3.4.379: P 67415:68542(1127) ack 16528 win 32120
(DF)
20:29:39.302532 1.2.3.4.379 > 5.6.7.8.1053: P 16856:16916(60) ack 68542 win 31856
(DF)
20:29:39.515796 5.6.7.8.1053 > 1.2.3.4.379: . 68542:68542(0) ack 16528 win 32120
(DF)
20:29:39.650291 1.2.3.4.379 > 5.6.7.8.1053: P 16916:17020(104) ack 68542 win 31856
(DF)
20:29:40.325784 5.6.7.8.1053 > 1.2.3.4.379: . 68542:68542(0) ack 16528 win 32120
(DF)
20:29:41.545775 5.6.7.8.1053 > 1.2.3.4.379: P 67415:68542(1127) ack 16528 win 32120
(DF)
20:29:41.545865 1.2.3.4.379 > 5.6.7.8.1053: . 17020:17020(0) ack 68542 win 31856
(DF)
20:29:43.290905 1.2.3.4.379 > 5.6.7.8.1053: P 17020:17124(104) ack 68542 win 31856
(DF)
20:29:43.525801 5.6.7.8.1053 > 1.2.3.4.379: . 68542:68542(0) ack 16528 win 32120
(DF)
20:29:44.065769 5.6.7.8.1053 > 1.2.3.4.379: P 68542:69669(1127) ack 16528 win 32120
(DF)
20:29:44.072538 1.2.3.4.379 > 5.6.7.8.1053: P 17124:17184(60) ack 69669 win 31856
(DF)
20:29:44.285753 5.6.7.8.1053 > 1.2.3.4.379: . 69669:69669(0) ack 16528 win 32120
(DF)
20:29:46.005767 5.6.7.8.1053 > 1.2.3.4.379: P 68542:69669(1127) ack 16528 win 32120
(DF)
20:29:46.005851 1.2.3.4.379 > 5.6.7.8.1053: . 17184:17184(0) ack 69669 win 31856
(DF)
20:29:50.572142 1.2.3.4.379 > 5.6.7.8.1053: P 17184:17288(104) ack 69669 win 31856
(DF)
20:29:50.915801 5.6.7.8.1053 > 1.2.3.4.379: . 69669:69669(0) ack 16528 win 32120
(DF)
20:29:53.895781 5.6.7.8.1053 > 1.2.3.4.379: P 69669:70796(1127) ack 16528 win 32120
(DF)
20:29:53.902581 1.2.3.4.379 > 5.6.7.8.1053: P 17288:17348(60) ack 70796 win 31856
(DF)
20:29:54.155798 5.6.7.8.1053 > 1.2.3.4.379: . 70796:70796(0) ac
Re[2]: Where are you going with 2.4.x?
Alan> What is the oops data before the kernel panic. I need that to debug the Alan> driver. Also did you build the DAC960 support with gcc 2.96-x x<74 ? My system compiler is: gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Shoud I upgrade it to gcc 2.95.x or 2.96.x? And since my last post 2.4.1-ac8 crashed again with: kswapd: Cannot dereference NULL pointer. On the next crash I'll try write down all traces. BTW, is there some way to log it somewhere to file? -- Best regards, Andriymailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [QUESTION]: IDE Driver support for S.M.A.R.T?
Alan Cox wrote: > > Does the current (E)IDE driver support SMART? > Yes My server disk reports: Vendor Specific SMART Attributes with Thresholds: Revision Number: 9 AttributeFlag Value Worst Threshold Raw Value ( 1)Raw Read Error Rate 0x0029 100 253 020 ( 3)Spin Up Time0x0027 078 078 020 0aff ( 4)Start Stop Count0x0032 100 100 008 0014 ( 5)Reallocated Sector Ct 0x0033 100 100 020 ( 7)Seek Error Rate 0x000b 100 100 023 ( 9)Power On Hours 0x0012 084 084 001 2ae7 ( 11)Unknown Attribute 0x0013 100 100 020 ( 12)Power Cycle Count 0x0032 100 100 008 0014 ( 13)Unknown Attribute 0x000b 100 100 023 (199)UDMA CRC Error Count0x001a 200 200 000 (198)Offline Uncorrectable 0x0010 100 253 000 (uptime of the machine is 81 hours longer than power on hours of the disk. Seems that there is a small discrepancy... Hmm. Just checked: The disk looses one hour every week) I think that "Power on hours value = 084" means that the disk thinks that it's seen about 1/6th of it's lifetime. The number seems to drop by one about once every month. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aironet4500_card (2.4.1-ac8), The PCI BIOS has not enabled thisdevice!
Sorry, no time to test, neither I have cisco cards. However, general notes: 1. Aironet did (cisco may do) weird tricks on bus. 2. insmod driver -> leds go out, that may be normal. ifconfig up should bring leds on. 3. People who fail with both drivers (Bens and mine), have had weird BIOS or BIOS settings in most of cases. IO conflict with bios configuration port (ICL 486 ), old PCI BIOS (Intel Pentium 200Mhz board) , etc. elmer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Where are you going with 2.4.x?
> I've installed 2.4.x there. Just immedualtely I've noticed performance > improve, responce time improve. That is good news > BUT: All kernels prior to 2.1.4-ac8 hangs during first few hours of > work on heavy disk (Mylex) activity. Ok Im glad to know we have made some progress there > 2.1.4-ac8 was the first kernel which was able to work nore then 24 > hours. But on 26'th our of work it crashed with: > >Kernel panic: Aiee:, killing interrupt handler! >In interrupt handler - not syncing What is the oops data before the kernel panic. I need that to debug the driver. Also did you build the DAC960 support with gcc 2.96-x x<74 ? > Can I know your thoughts about target market of 2.4.x kernel? I assume > that the goal is to make it feature-rich multimedia desktop system? And a rock solid server and anything else people want it to be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Power off 2.4.xx and ACPI / APM
Leo Laursen wrote: > I artikel <[EMAIL PROTECTED]>, skrev "Jean-luc Coulon" > <[EMAIL PROTECTED]>: > > >> Does this ACPI problem occur with 2.4.2-pre3? (patch available from > >> ftp://ftp.fr.kernel.org/pub/linux/kernel/testing/) > >> > > > > Yep! The same problem with all the 2.4.x and 2.4.x-prey. > > > > CONFIG_APM=m > > I am not on the list, but follows the discassion via news > > I believe the APM module is unloaded before it can shutdown > so CONFIG_APM=y might work (works for me ) > Leo Bingo ! At least, "power off" works with APM "Y" ... this does not solve the ACPI /and AX25 related problem. With 2.2x, you have not the choice : APM is "Y/N", it is not possible to install it as a module. Thank you, best regards Jean-Luc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre3 compile error in 6pack.c
> 2.4.2-pre3 doesn't compile with 6pack as a module; I had to disable it; > now it compiles (and so far, works fine). It has a slight dependancy on -ac right now. KMALLOC_MAXSIZE is the alloc size limit - 131072. It checks this as kmalloc now panics if called with an oversize request - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
> LADDIS is the industry standard benchmark for NFS. It crashes for ReiserFS and > NFS. We can't afford to buy it, as it is proprietary software. Once Nikita has > finished testing his changes, we will ask someone to test it for us though. > Do you know if the connectathon test suites show the problem? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hard lockup (no oops) on vanilla 2.4.2-pre3 with /dev/dsp
> hrm. it misbehaved on ac9 now. i'll try a different soundcard and see > what happens. is es1370 known to be relatively stable? i have one of > those lying about somewhere. The es1370 hasnt changed much but the VM code had a little (and testing ac9 tests who different sets of behaviour). If you have ACPI enabled then disable it next test - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Major Clock Drift
> Hmm, I can make it loose 30 seconds in 12 seconds. Just cat > /etc/termcap. Vesafb does this kind of stuff. [Yes, 3 times slower > clock]. Why are interrupts being disabled for vesafb scrolling anyway ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[OT] International CERT Conference 2001 Call
I apologize in advance but felt that this Call for Presentations may be of interest to the list members. To keep it short: CERT Conference 2001 CALL FOR PARTICIPATION August 6 - 10, 2001 International CERT Conference on Computer Security and Information Assurance Opportunities to participate include: 1. Workshops (full or half-day) 2. Short Courses (2 hours) 3. Presentations (50 minutes) 4. Papers/Posters 5. Panels Due Date: All proposals must be submitted by April 1, 2001. Final decisions will be made by May 1, 2001. Please direct questions to [EMAIL PROTECTED] Please feel free to ask me any questions as well. The full CFP is available at the CertConf website: http://www.certconf.org/cfp2001.pdf If you would like it in text format please let me know offline and I will be glad to send you one. Thanks for your help! -- Matthew G. Marsh, Chief Scientist NEbraskaCERT P.O. Box 825 Bellevue NE 68005-0825 Phone: (402) 827-1198 Email: [EMAIL PROTECTED] WWW: http://www.nebraskacert.org -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Slowing down CDROM drives (was: Re: ATAPI CDRW which doesn't work)
On Sat, Feb 10 2001, Pavel Machek wrote: > > ioctl(cd_fd, CDROM_SELECT_SPEED, speed); > > Does this actually work? I helped my friend with partly broken cdrom > (worked only at low speeds) and it did not have much effect. It did > not make my cdrom quiet, either, AFAI can remember. It's no news that vendors only implement what they want to. New cd-r/w and dvd drives are not required to implement this command, so it may not work there either. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Raw devices bound to RAID arrays ?
Hello, Is it possible to bind a raw device to a software RAID 1 array ? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problem with adding starfire driver to kernel 2.2.18
> Basically, it appears that it detects the same card more than once. In > the case of the below dmesg output - the machine has 1 tulip based card, > and 1 Adaptec Quartet64. The eth[5-8] are bogus. The Don Becker drivers have had this bug for ages and ages now, long after it has been reported it has not been fixed. I think you'll have to hack on that yourself - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Athlon-SMP compiles & runs. inline fns honored.
> Ouch. What about un-inlining in_interrupt() for all SMP cases? Reduces > code size just a bit, and function calls aren't very expensive on SMP > machines IMHO... (and as a side effect solves this problem...) Call, conditional branch, call is pretty expensive and thats what most in_interrupt and small constant memcpy/memset paths are - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Where are you going with 2.4.x?
Hello all, I'd like to post here me experience of using new Linux kernels both at home and on enterprise server. At home I'm using new branch since 2.3.x - it works really fine for home work, multimedia, etc. Nice work, thanks. But on our enterprise server It's something awful. Server hardware is: PIII 500Mhz, Intel 440GX, 512 ECC RAM, 2xAdaptec 7xxx + Mylex AccelRAID 250 disk subsystem. Server software is 2 instances of Oracle 8i (8.1.6 and 8.1.7). No kernel modules, no inet services, only Oracle. On 2.2.x this run more or less stable (it usually crash or hang once per month, but it's acceptable). I've installed 2.4.x there. Just immedualtely I've noticed performance improve, responce time improve. BUT: All kernels prior to 2.1.4-ac8 hangs during first few hours of work on heavy disk (Mylex) activity. 2.1.4-ac8 was the first kernel which was able to work nore then 24 hours. But on 26'th our of work it crashed with: Kernel panic: Aiee:, killing interrupt handler! In interrupt handler - not syncing So, again I've downgraded kernel to 2.2.18 again :( Can I know your thoughts about target market of 2.4.x kernel? I assume that the goal is to make it feature-rich multimedia desktop system? Personally I now look how to run Oracle under FreeBSD which is much more stable on the same hardware at high load (corporate Squid). -- Best regards, Andriy mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [QUESTION]: IDE Driver support for S.M.A.R.T?
> Does the current (E)IDE driver support SMART? Yes > Will Linux report any S.M.A.R.T errors or warnings to the system log? If you run SMART logging apps yes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
> run reiserfs on several servers, workstations, and a notebook. I have > current kernels and have watched carefully for corruption. I haven't > seen any evidence of corruption on any of them including my notebook > which has a bad battery and bad power connection so it tends to > instantly die. > > Alan, is there a particular trigger to this? The 2.4.1 stuff is a specific low level block I/O pattern. Its fixed in 2.4.2pre2/2.4.1ac-something - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.1-ac7
On Sun, 11 Feb 2001, Mike Galbraith wrote: > On Sun, 11 Feb 2001, Mike Galbraith wrote: > > > Something else I see while watching it run: MUCH more swapout than > > swapin. Does that mean we're sending pages to swap only to find out > > that we never need them again? > > (numbers might be more descriptive) > > user : 0:07:21.70 54.3% page in : 142613 > nice : 0:00:00.00 0.0% page out: 155454 > system: 0:03:40.63 27.1% swap in :56334 > idle : 0:02:30.50 18.5% swap out: 149872 > uptime: 0:13:32.83 context : 519726 Indeed, in this case we send a lot more pages to swap than we read back in from swap, this means that the data is still sitting in swap space and was never needed again. regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.1-ac7
On Sun, 11 Feb 2001 [EMAIL PROTECTED] wrote: > On Sat, 10 Feb 2001, Mike Galbraith wrote: > > > > > o Rebalance the 2.4.1 VM (Rik van Riel) > > This change makes my box swap madly under load. It appears to be > > keeping more cache around than is really needed, and therefore > > having to resort to swap instead. The result is MUCH more I/O than > > previous kernels while doing the same exact job. > > I concur this, > It appeared, that rather than free the cached buffers and reuse > the memory, it preferred to hit swap space. Streaming I/O > performance seems to have taken a hit lately. OK, so we're back to the old VM magic number game again ;( In short, we have to be more agressive towards unmapped cache pages than towards mapped pages in processes, except that this horribly breaks down when somebody does streaming IO using mmap while somebody else is at the same time re-using data from cached files (say, .h files)... Now the question is ... WHY do we need to change this behaviour and HOW exactly should it be changed ? I don't really feel comfortable just tweaking stuff until we get a half-dozen benchmarks right, I think we need to understand what is happening and change things accordingly. It's fine with me to put some temporary thing in place to get at least -ac5 behaviour back, but I don't think we should have this as a long-term thing. regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
OOPS with 2.4.1-ac8
I suddenly started to get those oopses. It didn't seem to cause any problems tho. I hope this result from ksymoops are usefull. Kurt ksymoops 2.3.7 on i586 2.4.1-ac8. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.1-ac8/ (default) -m /System.map (specified) Error (regular_file): read_ksyms stat /proc/ksyms failed No modules in ksyms, skipping objects No ksyms, skipping lsmod Feb 11 15:04:01 Q kernel: c013d4a6 Feb 11 15:04:01 Q kernel: Oops: Feb 11 15:04:01 Q kernel: CPU:0 Feb 11 15:04:01 Q kernel: EIP:0010:[d_lookup+98/252] Feb 11 15:04:01 Q kernel: EFLAGS: 00010213 Feb 11 15:04:01 Q kernel: eax: c3fe8dc8 ebx: ffe8 ecx: 001a edx: 00704020 Feb 11 15:04:01 Q kernel: esi: edi: c3fca320 ebp: esp: c1437f04 Feb 11 15:04:01 Q kernel: ds: 0018 es: 0018 ss: 0018 Feb 11 15:04:01 Q kernel: Process sh (pid: 13077, stackpage=c1437000) Feb 11 15:04:01 Q kernel: Stack: c1437f68 c3fca320 c1437fa4 c3fe8dc8 c2957005 00704020 0005 Feb 11 15:04:01 Q kernel:c01359f2 c3fca320 c1437f68 c1437f68 c0136161 c3fca320 c1437f68 Feb 11 15:04:01 Q kernel:c2957000 c1437fa4 080b91c4 c2957000 080b91c4 c013581b 0009 Feb 11 15:04:01 Q kernel: Call Trace: [cached_lookup+14/80] [path_walk+1337/1944] [getname+91/152] [__user_walk+58/84] [sys_newstat+21/108] [system_call+51/64] Feb 11 15:04:01 Q kernel: Code: 8b 6d 00 8b 54 24 18 39 53 48 75 76 8b 44 24 24 39 43 0c 75 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 8b 6d 00 mov0x0(%ebp),%ebp Code; 0003 Before first symbol 3: 8b 54 24 18 mov0x18(%esp,1),%edx Code; 0007 Before first symbol 7: 39 53 48 cmp%edx,0x48(%ebx) Code; 000a Before first symbol a: 75 76 jne82 <_EIP+0x82> 0082 Before first symbol Code; 000c Before first symbol c: 8b 44 24 24 mov0x24(%esp,1),%eax Code; 0010 Before first symbol 10: 39 43 0c cmp%eax,0xc(%ebx) Code; 0013 Before first symbol 13: 75 00 jne15 <_EIP+0x15> 0015 Before first symbol Feb 11 15:05:01 Q kernel: c013d4a6 Feb 11 15:05:01 Q kernel: Oops: Feb 11 15:05:01 Q kernel: CPU:0 Feb 11 15:05:01 Q kernel: EIP:0010:[d_lookup+98/252] Feb 11 15:05:01 Q kernel: EFLAGS: 00010213 Feb 11 15:05:01 Q kernel: eax: c3fe8dc8 ebx: ffe8 ecx: 001a edx: 00704020 Feb 11 15:05:01 Q kernel: esi: edi: c3fca320 ebp: esp: c1437f04 Feb 11 15:05:01 Q kernel: ds: 0018 es: 0018 ss: 0018 Feb 11 15:05:01 Q kernel: Process sh (pid: 13079, stackpage=c1437000) Feb 11 15:05:01 Q kernel: Stack: c1437f68 c3fca320 c1437fa4 c3fe8dc8 c2c41005 00704020 0005 Feb 11 15:05:01 Q kernel:c01359f2 c3fca320 c1437f68 c1437f68 c0136161 c3fca320 c1437f68 Feb 11 15:05:01 Q kernel:c2c41000 c1437fa4 080b91c4 c2c41000 080b91c4 c013581b 0009 Feb 11 15:05:01 Q kernel: Call Trace: [cached_lookup+14/80] [path_walk+1337/1944] [getname+91/152] [__user_walk+58/84] [sys_newstat+21/108] [system_call+51/64] Feb 11 15:05:01 Q kernel: Code: 8b 6d 00 8b 54 24 18 39 53 48 75 76 8b 44 24 24 39 43 0c 75 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 8b 6d 00 mov0x0(%ebp),%ebp Code; 0003 Before first symbol 3: 8b 54 24 18 mov0x18(%esp,1),%edx Code; 0007 Before first symbol 7: 39 53 48 cmp%edx,0x48(%ebx) Code; 000a Before first symbol a: 75 76 jne82 <_EIP+0x82> 0082 Before first symbol Code; 000c Before first symbol c: 8b 44 24 24 mov0x24(%esp,1),%eax Code; 0010 Before first symbol 10: 39 43 0c cmp%eax,0xc(%ebx) Code; 0013 Before first symbol 13: 75 00 jne15 <_EIP+0x15> 0015 Before first symbol Feb 11 15:06:01 Q kernel: c013d4a6 Feb 11 15:06:01 Q kernel: Oops: Feb 11 15:06:01 Q kernel: CPU:0 Feb 11 15:06:01 Q kernel: EIP:0010:[d_lookup+98/252] Feb 11 15:06:01 Q kernel: EFLAGS: 00010213 Feb 11 15:06:01 Q kernel: eax: c3fe8dc8 ebx: ffe8 ecx: 001a edx: 00704020 Feb 11 15:06:01 Q kernel: esi: edi: c3fca320 ebp: esp: c1437f04 Feb 11 15:06:01 Q kernel: ds: 0018 es: 0018 ss: 0018 Feb 11 15:06:01 Q kernel: Process sh (pid: 13081, stackpage=c1437000) Feb 11 15:06:01 Q kernel: Stack: c1437f68 c3fca320 c1437fa4 c3fe8dc8 c1603005 00704020 0005 Feb 11 15:06:01 Q kernel:c01359f2 c3fca320 c1437f68 c1437f68 c0136161 c3fca320 c1437f68 Feb 11 15:
Re: PROBLEM: RAMDISK larger than 778000 KB halts system
On Sat, 10 Feb 2001, Pavel Machek wrote: > > [1.] One line summary of the problem: > > Running badblocks on a ramdisk larger than 778000 KB halts > > system > > Is it really bug? That is simply a matter of definition. If the system does as you expect, then you will probably not regard it as a bug. I, however, am not in the habit of having Linux halt on me with no explanation. So the system did something that I did not expect. So in my opinion this _is_ a bug. > You have 778000 KB of low ram, right? (That's the way himem patches > work, IIRC). dmesg says: Linux version 2.4.1 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Linux-Mandrake 7.3)) #11 Fri Feb 9 21:29:16 CET 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0001 @ (reserved) BIOS-e820: 3fef @ 0010 (usable) BIOS-e820: d000 @ 3fff3000 (ACPI data) BIOS-e820: 3000 @ 3fff (ACPI NVS) 127MB HIGHMEM available. On node 0 totalpages: 262128 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 32752 pages. ... Memory: 1028484k/1048512k available (1253k kernel code, 19640k reserved, 470k data, 212k init, 131008k highmem) Dentry-cache hash table entries: 131072 (order: 8, 1048576 bytes) Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes) Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) I will expect that low ram can be calculated as: 1028484-131008=897476 > You have used all of it. You've run out of memory. > > It might be pretty non-trivial to fix this. I am surprised if RAMdisks cannot utilize the himem. Where can I read about what other restrictions exist on himem? But if this is correct, then it would be a friendly gesture to tell the user that he has hit a limit. E.g. by prohibiting usage of so much so the system halts or at least logging why the system halted. /Ole - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RAID1 read balancing
Hello, For a RAID1 array built of two disks on two separate SCSI controllers, are the reads balanced between the two controllers (for higher speed) ? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Animated framebuffer logo for 2.4.1
Mike A. Harris wrote: > On Thu, 8 Feb 2001, Pavel Machek wrote: >> wondering when linux boot gets so long that mpeg2 player gets >> integrated into kernel. > > ;o) > > I doubt strongly that that is technically possible. In fact I'm > sure it is not. Why not ? Just preload the movie with the kernel, and you can start playing as soon as framebuffer, timers, and interrupts are available. Of course, if the word gets out that you're writing such a patch, the people from the village may come with torches ... ;-) - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hard lockup (no oops) on vanilla 2.4.2-pre3 with /dev/dsp
On Sun, Feb 11, 2001 at 01:19:02PM +1100, john slee wrote: > On Sat, Feb 10, 2001 at 07:33:53PM +, Alan Cox wrote: > > Does 2.4.1-ac9 behave ? > > yep, works fine. let me amend this slightly: works fine when not using xfree86 with pci s3virge. guess it wasnt the kernel at fault after all. :-) 2.4.2-pre3 behaves also, haven't bothered trying anything else yet. note that commenting out the bits of XF86Config relevant to the s3 was sufficient, didn't need to physically remove the card. it is still odd, since there aren't any resource conflicts (that i am aware of) thanks, j. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
eepro100 + 2.2.18 + laptop problems
I have a minipci card in my laptop. It's purpose in life is to be a modem and ethernet card, with the ethernet side being an eepro100. lspci -vv gives me the following: 00:0d.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 09) Subsystem: Intel Corporation: Unknown device 2411 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html Feb 11 22:30:18 theirongiant kernel: eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin <[EMAIL PROTECTED]> and others Feb 11 22:30:18 theirongiant kernel: eepro100.c: VA Linux custom, Dragan Stancevic <[EMAIL PROTECTED]> 2000/11/15 Feb 11 22:30:18 theirongiant kernel: eth0: Intel PCI EtherExpress Pro100 82557, 00:10:A4:0E:7F:EC, IRQ 10. Feb 11 22:30:18 theirongiant kernel: Board assembly 000695-001, Physical connectors present: RJ45 Feb 11 22:30:18 theirongiant kernel: Primary interface chip i82555 PHY #1. Feb 11 22:30:18 theirongiant kernel: General self-test: passed. Feb 11 22:30:18 theirongiant kernel: Serial sub-system self-test: passed. Feb 11 22:30:18 theirongiant kernel: Internal registers self-test: passed. Feb 11 22:30:18 theirongiant kernel: ROM checksum self-test: passed (0xdbd8681d). Feb 11 22:30:18 theirongiant kernel: Receiver lock-up workaround activated. Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)! Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)! Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0xff90) timedout with(0xff90)! Feb 11 22:30:31 theirongiant last message repeated 12 times Feb 11 22:30:31 theirongiant kernel: eth0: 0 multicast blocks dropped. Feb 11 22:30:34 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)! Feb 11 22:30:34 theirongiant kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)! Feb 11 22:30:34 theirongiant kernel: eepro100: cmd_wait for(0xff90) timedout with(0xff90)! Feb 11 22:30:49 theirongiant last message repeated 12 times Feb 11 22:30:49 theirongiant kernel: eth0: 0 multicast blocks dropped. Feb 11 22:30:52 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)! Feb 11 22:30:52 theirongiant kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)! Feb 11 22:30:52 theirongiant kernel: eepro100: cmd_wait for(0xff90) timedout with(0xff90)! Feb 11 22:30:56 theirongiant last message repeated 7 times Feb 11 22:30:56 theirongiant kernel: eth0: 0 multicast blocks dropped. The only way to get it out of this, without a reboot is to drop eth0 and then bring it back up, but, like this time, that doesn't always work and it takes a few goes at it. The driver itself is compiled as a module and the interface is dropped and the module unloaded when the laptop is being suspended and then the module is loaded back in and the interface brought back up. This is because the driver doesn't realise that the card has been turned off and it needs reinitialisation (which is what the reloading of the module does I presume). This also happened with 2.2.19pre7 and 2.2.18preX. I don't know if it happens with 2.4.x as I haven't used it long enough. The ps/2 driver seems broken (at least in 2.4.0) which is another issue I have to take up in a seperate email. Anyhow, can anyone help? If you need more info just holler. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Sound drivers pci_enable_device clean_up
[EMAIL PROTECTED] <[EMAIL PROTECTED]> écrit :
[...]
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/sound/es1370.c
>linux-dj/drivers/sound/es1370.c
> --- linux/drivers/sound/es1370.c Sat Feb 10 02:49:52 2001
> +++ linux-dj/drivers/sound/es1370.c Sat Feb 10 03:05:52 2001
> @@ -117,6 +117,7 @@
> * Tim Janik's BSE (Bedevilled Sound Engine) found this
> *07.02.2000 0.33 Use pci_alloc_consistent and pci_register_driver
> *21.11.2000 0.34 Initialize dma buffers in poll, otherwise poll may return
>a bogus mask
> + *09.02.2001 0.35 pci_enable_device before reading irq/resources
><[EMAIL PROTECTED]>
> *
> * some important things missing in Ensoniq documentation:
> *
> @@ -2544,14 +2545,21 @@
> spin_lock_init(&s->lock);
> s->magic = ES1370_MAGIC;
> s->dev = pcidev;
> +
> + i = pci_enable_device(pcidev);
> + if (i) {
> + kfree(s);
> + return i;
> + }
> +
Here ac9 says:
[...]
2526 if (pcidev->irq == 0)
2527 return -1;
We will never go through the tests in pcibios_enable_irq.
[...]
2631 err_region:
2632 kfree(s);
2633 return -1;
No need to add it one more time.
--- linux-2.4.1-ac9.orig/drivers/sound/es1370.c Sat Feb 10 07:11:28 2001
+++ linux-2.4.1-ac9/drivers/sound/es1370.c Sun Feb 11 08:58:08 2001
@@ -2521,6 +2521,8 @@
mm_segment_t fs;
int i, val;
+ if (pci_enable_device(pcidev))
+ return -1;
if (!RSRCISIOREGION(pcidev, 0))
return -1;
if (pcidev->irq == 0)
@@ -2550,8 +2552,6 @@
printk(KERN_ERR "es1370: io ports %#lx-%#lx in use\n", s->io,
s->io+ES1370_EXTENT-1);
goto err_region;
}
- if (pci_enable_device(pcidev))
- goto err_irq;
if (request_irq(s->irq, es1370_interrupt, SA_SHIRQ, "es1370", s)) {
printk(KERN_ERR "es1370: irq %u in use\n", s->irq);
goto err_irq;
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/sound/es1371.c
>linux-dj/drivers/sound/es1371.c
> --- linux/drivers/sound/es1371.c Sat Feb 10 02:49:52 2001
> +++ linux-dj/drivers/sound/es1371.c Sat Feb 10 03:05:52 2001
[...]
Same remarks.
--- linux-2.4.1-ac9.orig/drivers/sound/es1371.c Sat Feb 10 07:11:28 2001
+++ linux-2.4.1-ac9/drivers/sound/es1371.c Sun Feb 11 09:02:59 2001
@@ -2733,6 +2733,8 @@
signed long tmo2;
unsigned int cssr;
+ if (pci_enable_device(pcidev))
+ return -1;
if (!RSRCISIOREGION(pcidev, 0))
return -1;
if (pcidev->irq == 0)
@@ -2771,8 +2773,6 @@
printk(KERN_ERR PFX "io ports %#lx-%#lx in use\n", s->io,
s->io+ES1371_EXTENT-1);
goto err_region;
}
- if (pci_enable_device(pcidev))
- goto err_irq;
if (request_irq(s->irq, es1371_interrupt, SA_SHIRQ, "es1371", s)) {
printk(KERN_ERR PFX "irq %u in use\n", s->irq);
goto err_irq;
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/sound/esssolo1.c
>linux-dj/drivers/sound/esssolo1.c
> --- linux/drivers/sound/esssolo1.cSat Feb 10 02:49:52 2001
> +++ linux-dj/drivers/sound/esssolo1.c Sat Feb 10 03:05:52 2001
[...]
Same remarks.
--- linux-2.4.1-ac9.orig/drivers/sound/esssolo1.c Sat Feb 10 07:11:28 2001
+++ linux-2.4.1-ac9/drivers/sound/esssolo1.cSun Feb 11 09:04:58 2001
@@ -2246,6 +2246,8 @@
struct pm_dev *pmdev;
dma_addr_t dma_mask;
+ if (pci_enable_device(pcidev))
+ return -1;
if (!RSRCISIOREGION(pcidev, 0) ||
!RSRCISIOREGION(pcidev, 1) ||
!RSRCISIOREGION(pcidev, 2) ||
@@ -2302,8 +2304,6 @@
printk(KERN_ERR "solo1: irq %u in use\n", s->irq);
goto err_irq;
}
- if (pci_enable_device(pcidev))
- goto err_irq;
printk(KERN_INFO "solo1: joystick port at %#lx\n", s->gpbase+1);
/* register devices */
if ((s->dev_audio = register_sound_dsp(&solo1_audio_fops, -1)) < 0)
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
