Re: test11-pre6 still very broken
On Fri, Nov 17, 2000 at 11:25:50PM -0800, Ben Ford wrote: > Here is lspci output from the laptop in question. Is this not UHCI? Yes it is. Just a bit funny if you think about it, but with Intel and Via putting the UHCI core into their chipsets I guess it makes sense. One note for the archives, if you are presented a choice between a OHCI or a UHCI controller, go for the OHCI. It has a "cleaner" interface, handles more of the logic in the silicon, and due to this provides faster transfers. In it's defense, the UHCI design was the first one, and OHCI capitalized on that by fixing some of its weaknesses. Hopefully the same thing will not happen for USB 2.0, and everyone will like EHCI. greg k-h (who has UHCI in all of his machines except one.) -- greg@(kroah|wirex).com http://immunix.org/~greg - 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 timeout errors - 2.2.18pre20
Hello, On Thu, Nov 16, 2000 at 09:28:44AM -0500, Admin Mailing Lists wrote: > Was running 2.2.15pre18 with no eepro problems. > Upgraded to 2.2.18pre20 and started experiencing transmit timed out errors > a day into the boot. eth0 was unresponsive in/out. down/uping the > interface had no effect. System was not under any big network load. > See attached text file for related kernel messages. > System is Intel PR440FX mobo, SMP, glibc 2.1.3, gcc 2.95.2 The problem isn't in the kernel version. The bug just shows not with 100% frequency. Investigations are in progress. Best regards Andrey V. Savochkin - 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: Freeze on FPU exception with Athlon
Linus Torvalds wrote: > > I sure as hell hope this isn't an Athlon issue. Can other people try > the test-program and see if we have a pattern (ie "it happens only on > Athlons", or "Linus is on drugs and it happens for everybody else"). I've tried both variants (fesetenv and inline-asm) with glibc-2.1.3, 2.4.0-test11pre7 and an AMD Thunderbird. Neither does freeze, but both yield: Floating point exception (core dumped) -Udo. - 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: EXPORT_NO_SYMBOLS vs. (null) ?
On Sat, 18 Nov 2000 00:15:35 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote: >What is the difference between a module that exports no symbols and >includes EXPORT_NO_SYMBOLS reference, and such a module that lacks >EXPORT_NO_SYMBOLS? When modules were first introduced, all symbols were automatically exported. For kernel 2.0 compatibility, a module without EXPORT_NO_SYMBOLS actually exports everything. There are flags on insmod to override this default. modutils 2.5 will remove this backwards compatibility, no module will export symbols unless they are explicitly exported. If you are feeling brave, add insmod_opt=-x to your modules.conf and see what breaks in 2.4. - 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: test11-pre6 still very broken
Here is lspci output from the laptop in question. Is this not UHCI? [ben@Juanita ben]$ /sbin/lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 03) 00:09.0 Communication controller: Lucent Microelectronics 56k WinModem (rev 01) 00:0a.0 CardBus bridge: Texas Instruments: Unknown device ac50 (rev 01) 00:11.0 Multimedia audio controller: ESS Technology ES1969 Solo-1 Audiodrive (rev 02) 00:12.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage P/M Mobility AGP 2x (rev 64) The machine hangs on warm reboot almost every time. On cold boot, it never has the problem. -b Greg KH wrote: > On Fri, Nov 17, 2000 at 09:27:19PM -0800, David Ford wrote: > > > > The second issue is usb. I now have two machines that lockup on boot in USB. > > One is the above workstation, the second is a Compaq laptop. Unfortunately > > I have no way of unplugging the USB hardware inside the laptop :P > > Can't you not compile in the UHCI driver? Actually, it seems odd that a > Compaq laptop would have a uhci driver, as Compaq was one of the OHCI > creators... > > greg k-h > > -- > greg@(kroah|wirex).com > http://immunix.org/~greg > - > 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/ S/MIME Cryptographic Signature
ide.2.2.17.all.20001116.patch
Fixes osb4 ServerWorks ATA-33 TaskfileNative. Only because I needed this for Ute-Linux Distro, did I feel obligated to push and do a backport to 2.2.17 Additionally DiskPerf-1.0 is available. DO NOT ENABLE WRITE MODE OF TESTS DESTRUCTIVE TESTS!! IT IS CONFIGURED FOR READONLY TEST! This package is brought to you by the following: ATIPA Linux Solutions Linux ATA Development Timpanogas Research Group Use at your own RISK if modified! Regards, Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development - 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: test11-pre6 still very broken
On Fri, Nov 17, 2000 at 09:27:19PM -0800, David Ford wrote: > > The second issue is usb. I now have two machines that lockup on boot in USB. > One is the above workstation, the second is a Compaq laptop. Unfortunately > I have no way of unplugging the USB hardware inside the laptop :P Can't you not compile in the UHCI driver? Actually, it seems odd that a Compaq laptop would have a uhci driver, as Compaq was one of the OHCI creators... greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - 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/
Please send Changelog info and patch notices for the test and -pre releases.
Dear Linus, I haven't seen any announcements of recent test and test-pre releases. Can you begin sending those again, please? Best wishes, Miles - 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: sound and scsi pci MODULE_DEVICE_TABLE entries? (primary for Alan Cox)
"Adam J. Richter" wrote: > Hello Alan, > > Jeff Garzik tells me that you, with some help from some other > kernel developers, are hacking on the sound drivers right now. I > would like to add PCI MODULE_DEVICE_TABLE entries to three of > the four PCI sound drivers: cmpci, cs46xx and nm256_audio. > (I have already sent a similar patch to Zach Brown for maestro, > although that was a port to the new PCI interface.) This will > enable depmod to record the PCI ID's that they care about in > /lib/modules//modules.pcimap, which, in turn, will > enable more automated module loading based on hardware configuration. I responded to Adam in private, but wanted to speak up in public too: these changes sound ok with me. The patches change no code logic, they export the supported PCI ids to userspace, and make the transition to the new PCI API a tiny bit easier. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - 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/
sound and scsi pci MODULE_DEVICE_TABLE entries? (primary for Alan Cox)
I tried sending this to Alan Cox, but his mailer complained that we are connected via AboveNet, which blocks ORBS (which is true, and which I have complained about to our ISP many times). It is primary intended for Alan, but anyone else who wants to chime in is welcome to. Adam -- Hello Alan, Jeff Garzik tells me that you, with some help from some other kernel developers, are hacking on the sound drivers right now. I would like to add PCI MODULE_DEVICE_TABLE entries to three of the four PCI sound drivers: cmpci, cs46xx and nm256_audio. (I have already sent a similar patch to Zach Brown for maestro, although that was a port to the new PCI interface.) This will enable depmod to record the PCI ID's that they care about in /lib/modules//modules.pcimap, which, in turn, will enable more automated module loading based on hardware configuration. Would this submission be duplicative of what you are working on? If not, can I submit them to you or is there someone more appropriate for me to submit changes to right now (e.g., each driver's author, someone else)? Since there are only four PCI sound drivers right now, I would like to be able to fix the whole category. Also, do you know if there is someone shepherding the drivers/scsi patches? That is a more important category for automated loading, since it may be needed in booting. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - 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] potential death in disassociate_ctty()
In article <[EMAIL PROTECTED]>, Andrew Morton <[EMAIL PROTECTED]> wrote: > >Also, somewhere on the path from kernel 2.2 to 2.4 the call to >do_notify_parent() was moved inside the tasklist lock. Why was this? Ehh.. Because that is also what protects our "parent" pointer. Linus - 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: test11-pre6 still very broken
> > The mysterious lockups in test11-pre5 continue in test11-pre6. It is very > > difficult because the lockups appear to be kdb-specific (and kdb itself [...] > It could be that -test5 and -test6 break some assumption kdb makes. > It has been eminently stable here. Whether or not the assumptions are made, the last testN series of kernels have introduced two serious issues IMO. The first is the mysterious deadlocks and no way to figure them out. With kdb the machine won't hang. Without it, it deadlocks within 36 hours. The second issue is usb. I now have two machines that lockup on boot in USB. One is the above workstation, the second is a Compaq laptop. Unfortunately I have no way of unplugging the USB hardware inside the laptop :P -d begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
EXPORT_NO_SYMBOLS vs. (null) ?
What is the difference between a module that exports no symbols and includes EXPORT_NO_SYMBOLS reference, and such a module that lacks EXPORT_NO_SYMBOLS? Alan once upbraided me for assuming they were the same :) -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - 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: isofs broken (2.2 and 2.4)
On Sat, 18 Nov 2000, Keith Owens wrote: > On Fri, 17 Nov 2000 17:21:53 -0800 (PST), > Linus Torvalds <[EMAIL PROTECTED]> wrote: > >There's a test11-pre7 there now, and I'd really ask people to check out > >the isofs changes because slight worry about those is what held me up from > >just calling it test11 outright. > > > >It's almost guaranteed to be better than what we had before, but anyway.. > > > > Linus > > namei.c: In function `isofs_find_entry': > namei.c:130: warning: passing arg 2 of `get_joliet_filename' from incompatible >pointer type > namei.c:130: warning: passing arg 3 of `get_joliet_filename' from incompatible >pointer type Thanks. The second and third arguments were switched around to match all the other filename conversion stuff, and because I don't have joliet enabled I didn't notice this. Just switch them around where the warning occurs, and you should be golden. Linus - 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: test11-pre6 still very broken
On Fri, 17 Nov 2000 20:00:49 + (GMT), Tigran Aivazian <[EMAIL PROTECTED]> wrote: >The mysterious lockups in test11-pre5 continue in test11-pre6. It is very >difficult because the lockups appear to be kdb-specific (and kdb itself >goes mad) but when there is no kdb there is very little useful information >one can extract from a dead system... ftp://oss.sgi.com/projects/kdb/download/ix86/kdb-v1.6-2.4.0-test11-pre7.gz Assorted bug fixes from my work in progress tree, including one that fixes a race between user space use of debug and kdb, ltrace trips this. Some people have reported keyboard lockups after leaving kdb. I have not been able to reproduce this problem, let me know if you still see it. - 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: isofs broken (2.2 and 2.4)
On Fri, 17 Nov 2000 17:21:53 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]> wrote: >There's a test11-pre7 there now, and I'd really ask people to check out >the isofs changes because slight worry about those is what held me up from >just calling it test11 outright. > >It's almost guaranteed to be better than what we had before, but anyway.. > > Linus namei.c: In function `isofs_find_entry': namei.c:130: warning: passing arg 2 of `get_joliet_filename' from incompatible pointer type namei.c:130: warning: passing arg 3 of `get_joliet_filename' from incompatible pointer type - 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.2.18pre21: DRM update
This is an update from the main DRM tree, but with cosmetic changes
removed and only meat left. This patch is already in VA's shipping
kernel, so you know we really trust it. :-,
BTW, this patch is not fluff: It includes bug fixes. But it's pretty
big, so if you want to wait until 2.2.19 I'll understand
Index: drivers/char/Makefile
--- drivers/char/Makefile.prev
+++ drivers/char/Makefile Fri Nov 17 13:30:04 2000
@@ -12,5 +12,5 @@
SUB_DIRS :=
MOD_SUB_DIRS := $(SUB_DIRS)
-ALL_SUB_DIRS := $(SUB_DIRS) rio ftape joystick drm agp
+ALL_SUB_DIRS := $(SUB_DIRS) rio ftape joystick
#
@@ -395,4 +395,16 @@
endif
+ifeq ($(CONFIG_DRM),y)
+O_OBJS += drm/drm.o
+ALL_SUB_DIRS += drm
+MOD_SUB_DIRS += drm
+SUB_DIRS += drm
+else
+ ifeq ($(CONFIG_DRM),m)
+ ALL_SUB_DIRS += drm
+ MOD_SUB_DIRS += drm
+ endif
+endif
+
ifeq ($(CONFIG_INTEL_RNG),y)
O_OBJS += i810_rng.o
@@ -650,16 +662,4 @@
OX_OBJS += h8.o
endif
-
-
-ifeq ($(CONFIG_DRM),y)
-SUB_DIRS += drm
-O_OBJS += drm/drm.o
-MOD_SUB_DIRS += drm
-else
- ifeq ($(CONFIG_DRM),m)
- MOD_SUB_DIRS += drm
- endif
-endif
-
ifeq ($(L_I2C),y)
Index: drivers/char/drm/drmP.h
--- drivers/char/drm/drmP.h.prev
+++ drivers/char/drm/drmP.h Fri Nov 17 13:30:04 2000
@@ -34,4 +34,9 @@
#ifdef __KERNEL__
+#ifdef __alpha__
+/* add include of current.h so that "current" is defined
+ * before static inline funcs in wait.h. 4/21/2000 S + B */
+#include
+#endif /* __alpha__ */
#include
#include
@@ -47,8 +52,11 @@
#include
#include /* For (un)lock_kernel */
+#include
+#ifdef __alpha__
+#include /* For pte_wrprotect */
+#endif
#include
#include
#include
-#include
#ifdef CONFIG_MTRR
#include
@@ -133,8 +141,86 @@
#endif
+ /* module_init/module_exit added in 2.3.13 */
+#ifndef module_init
+#define module_init(x) int init_module(void) { return x(); }
+#endif
+#ifndef module_exit
+#define module_exit(x) void cleanup_module(void) { x(); }
+#endif
+
+ /* virt_to_page added in 2.4.0-test6 */
+#if LINUX_VERSION_CODE < 0x020400
+#define virt_to_page(kaddr) (mem_map + MAP_NR(kaddr))
+#endif
+
/* Generic cmpxchg added in 2.3.x */
#ifndef __HAVE_ARCH_CMPXCHG
/* Include this here so that driver can be
used with older kernels. */
+#if defined(__alpha__)
+static __inline__ unsigned long
+__cmpxchg_u32(volatile int *m, int old, int new)
+{
+ unsigned long prev, cmp;
+
+ __asm__ __volatile__(
+ "1: ldl_l %0,%2\n"
+ " cmpeq %0,%3,%1\n"
+ " beq %1,2f\n"
+ " mov %4,%1\n"
+ " stl_c %1,%2\n"
+ " beq %1,3f\n"
+ "2: mb\n"
+ ".subsection 2\n"
+ "3: br 1b\n"
+ ".previous"
+ : "="(prev), "="(cmp), "=m"(*m)
+ : "r"((long) old), "r"(new), "m"(*m));
+
+ return prev;
+}
+
+static __inline__ unsigned long
+__cmpxchg_u64(volatile long *m, unsigned long old, unsigned long new)
+{
+ unsigned long prev, cmp;
+
+ __asm__ __volatile__(
+ "1: ldq_l %0,%2\n"
+ " cmpeq %0,%3,%1\n"
+ " beq %1,2f\n"
+ " mov %4,%1\n"
+ " stq_c %1,%2\n"
+ " beq %1,3f\n"
+ "2: mb\n"
+ ".subsection 2\n"
+ "3: br 1b\n"
+ ".previous"
+ : "="(prev), "="(cmp), "=m"(*m)
+ : "r"((long) old), "r"(new), "m"(*m));
+
+ return prev;
+}
+
+static __inline__ unsigned long
+__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+ switch (size) {
+ case 4:
+ return __cmpxchg_u32(ptr, old, new);
+ case 8:
+ return __cmpxchg_u64(ptr, old, new);
+ }
+ return old;
+}
+#define cmpxchg(ptr,o,n)\
+ ({\
+ __typeof__(*(ptr)) _o_ = (o); \
+ __typeof__(*(ptr)) _n_ = (n); \
+ (__typeof__(*(ptr))) __cmpxchg((ptr), (unsigned long)_o_, \
+ (unsigned long)_n_, sizeof(*(ptr))); \
+ })
+
+#elif __i386__
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
unsigned long new, int size)
@@ -167,4 +253,5 @@
((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o), \
(unsigned long)(n),sizeof(*(ptr
+#endif /* i386 & alpha */
#endif
@@ -316,4 +403,5 @@
int high_mark; /* High water mark */
atomic_t wfh; /* If waiting for high mark */
+ spinlock_tlock;
} drm_freelist_t;
@@ -344,4 +432,5 @@
struct drm_file *prev;
struct drm_device *dev;
+
Re: Freeze on FPU exception with Athlon
In article <[EMAIL PROTECTED]>,
=?iso-8859-1?q?Markus=20Schoder?= <[EMAIL PROTECTED]> wrote:
>The following small program (linked against glibc 2.1.3) reliably
>freezes my system (Athlon Thunderbird CPU) with at least kernels
>2.4.0-test10 and 2.4.0-test11-pre5. Even the SysRq keys do not work
>after the freeze.
>
>Older kernels (e.g. 2.3.40) seem to work. Any Ideas?
It certainly doesn't happen for me on any of the machines I work with,
but it wouldn't compile as-is for me, so I exchanged the FPU setting
with a simpler
asm("fldcw %0": :"m" (0));
which should do the equivalent (ie unmask divide by zero errors). Does
that make a difference for you?
Can you try to figure out where it started happening? Ie try test9 and
back too, to figure out what might be bringing it on...
I sure as hell hope this isn't an Athlon issue. Can other people try
the test-program and see if we have a pattern (ie "it happens only on
Athlons", or "Linus is on drugs and it happens for everybody else").
Thanks,
Linus
-
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] potential death in disassociate_ctty()
The call to disassociate_ctty() in exit_notify() is very dangerous. If
disassociate_ctty() calls schedule() then either:
- a parent process who is spinning in fork.c:release() will stop
spinning and will proceed to deallocate the child process's kernel
stack. This will probably have adverse effects when it is rewoken.
- Or, if disassociate_ctty() sets current->state to TASK_RUNNING and
the timing is right, the exitting child will no longer be in state
TASK_ZOMBIE and will continue to run. It hits the fake_volatile goto
in do_exit() and has another go at zombifying itself.
Not sure what happens next, but you end up with every process
sleeping and your machine freezes halfway through your initscripts.
Basically, we mustn't sleep in disassociate_ctty(). But this function
does all sorts of things, inclusing calling the open and close methods
of tty drivers and ldisc drivers. They _do_ call functions which can
sleep.
I think it's safer to not call disassociate_ctty() when we're in state
TASK_ZOMBIE. This patch moves the parent notification and the task
state change to _after_ the call to disassociate_ctty(). As an added
bonus, it's a little more efficient: the later we wake the parent, the
less time the parent has to spend spinning on current->has_cpu.
I'm not particularly confident about this one. What are the effects of
moving the call to do_notify_parent()? None, I think - if it mattered
we'd be racy anyway.
Also, somewhere on the path from kernel 2.2 to 2.4 the call to
do_notify_parent() was moved inside the tasklist lock. Why was this?
It seems unnecessary. This patch backs out that change, perhaps
wrongly...
--- linux-2.4.0-test11-pre7/kernel/exit.c Sat Nov 18 13:55:32 2000
+++ linux-akpm/kernel/exit.cSat Nov 18 14:37:39 2000
@@ -382,7 +382,6 @@
*/
write_lock_irq(_lock);
- do_notify_parent(current, current->exit_signal);
while (current->p_cptr != NULL) {
p = current->p_cptr;
current->p_cptr = p->p_osptr;
@@ -418,6 +417,10 @@
if (current->leader)
disassociate_ctty(1);
+
+ /* From now on, we must not sleep */
+ set_current_state(TASK_ZOMBIE);
+ do_notify_parent(current, current->exit_signal);
}
NORET_TYPE void do_exit(long code)
@@ -444,7 +447,6 @@
__exit_fs(tsk);
exit_sighand(tsk);
exit_thread();
- tsk->state = TASK_ZOMBIE;
tsk->exit_code = code;
exit_notify();
put_exec_domain(tsk->exec_domain);
-
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] semaphore optimisation
This patch modestly improves the scalability and straight-line
performance of x86 semaphores by removing the semaphore_lock and using
the per-semaphore lock instead. If removes several spinlock operations
and allows concurrent operations on separate semaphores.
No bugs were harmed in the preparation of this patch. It's just me
fartarsing aound.
--- linux-2.4.0-test11-pre7/include/linux/sched.h Sat Nov 18 13:55:32 2000
+++ linux-akpm/include/linux/sched.hSat Nov 18 14:42:26 2000
@@ -535,6 +535,7 @@
#define CURRENT_TIME (xtime.tv_sec)
extern void FASTCALL(__wake_up(wait_queue_head_t *q, unsigned int mode, unsigned int
wq_mode));
+extern void FASTCALL(wake_up(wait_queue_head_t *q, unsigned int mode, unsigned
+int wq_mode));
extern void FASTCALL(__wake_up_sync(wait_queue_head_t *q, unsigned int mode, unsigned
int wq_mode));
extern void FASTCALL(sleep_on(wait_queue_head_t *q));
extern long FASTCALL(sleep_on_timeout(wait_queue_head_t *q,
--- linux-2.4.0-test11-pre7/include/linux/wait.hSat Nov 18 13:55:32 2000
+++ linux-akpm/include/linux/wait.h Sat Nov 18 14:42:26 2000
@@ -72,6 +72,7 @@
# define wq_read_unlock_irqrestore read_unlock_irqrestore
# define wq_read_unlock read_unlock
# define wq_write_lock_irq write_lock_irq
+# define wq_write_unlock_irq write_unlock_irq
# define wq_write_lock_irqsave write_lock_irqsave
# define wq_write_unlock_irqrestore write_unlock_irqrestore
# define wq_write_unlock write_unlock
@@ -84,6 +85,7 @@
# define wq_read_unlock spin_unlock
# define wq_read_unlock_irqrestore spin_unlock_irqrestore
# define wq_write_lock_irq spin_lock_irq
+# define wq_write_unlock_irq spin_unlock_irq
# define wq_write_lock_irqsave spin_lock_irqsave
# define wq_write_unlock_irqrestore spin_unlock_irqrestore
# define wq_write_unlock spin_unlock
--- linux-2.4.0-test11-pre7/arch/i386/kernel/semaphore.cSat Nov 18 13:55:28
2000
+++ linux-akpm/arch/i386/kernel/semaphore.c Sat Nov 18 14:42:26 2000
@@ -53,16 +53,15 @@
wake_up(>wait);
}
-static spinlock_t semaphore_lock = SPIN_LOCK_UNLOCKED;
-
void __down(struct semaphore * sem)
{
struct task_struct *tsk = current;
DECLARE_WAITQUEUE(wait, tsk);
- tsk->state = TASK_UNINTERRUPTIBLE;
- add_wait_queue_exclusive(>wait, );
- spin_lock_irq(_lock);
+ tsk->state = TASK_UNINTERRUPTIBLE;
+ wq_write_lock_irq(>wait.lock);
+ wait.flags = WQ_FLAG_EXCLUSIVE;
+ __add_wait_queue_tail(>wait, );
sem->sleepers++;
for (;;) {
int sleepers = sem->sleepers;
@@ -76,14 +75,14 @@
break;
}
sem->sleepers = 1; /* us - see -1 above */
- spin_unlock_irq(_lock);
+ wq_write_unlock_irq(>wait.lock);
schedule();
tsk->state = TASK_UNINTERRUPTIBLE;
- spin_lock_irq(_lock);
+ wq_write_lock_irq(>wait.lock);
}
- spin_unlock_irq(_lock);
- remove_wait_queue(>wait, );
+ __remove_wait_queue(>wait, );
+ wq_write_unlock_irq(>wait.lock);
tsk->state = TASK_RUNNING;
wake_up(>wait);
}
@@ -93,10 +92,11 @@
int retval = 0;
struct task_struct *tsk = current;
DECLARE_WAITQUEUE(wait, tsk);
- tsk->state = TASK_INTERRUPTIBLE;
- add_wait_queue_exclusive(>wait, );
- spin_lock_irq(_lock);
+ tsk->state = TASK_INTERRUPTIBLE;
+ wq_write_lock_irq(>wait.lock);
+ wait.flags = WQ_FLAG_EXCLUSIVE;
+ __add_wait_queue_tail(>wait, );
sem->sleepers ++;
for (;;) {
int sleepers = sem->sleepers;
@@ -126,15 +126,15 @@
break;
}
sem->sleepers = 1; /* us - see -1 above */
- spin_unlock_irq(_lock);
+ wq_write_unlock_irq(>wait.lock);
schedule();
tsk->state = TASK_INTERRUPTIBLE;
- spin_lock_irq(_lock);
+ wq_write_lock_irq(>wait.lock);
}
- spin_unlock_irq(_lock);
+ __remove_wait_queue(>wait, );
+ wq_write_unlock_irq(>wait.lock);
tsk->state = TASK_RUNNING;
- remove_wait_queue(>wait, );
wake_up(>wait);
return retval;
}
@@ -152,7 +152,7 @@
int sleepers;
unsigned long flags;
- spin_lock_irqsave(_lock, flags);
+ wq_write_lock_irqsave(>wait.lock, flags);
sleepers = sem->sleepers + 1;
sem->sleepers = 0;
@@ -161,9 +161,9 @@
* playing, because we own the spinlock.
*/
if (!atomic_add_negative(sleepers, >count))
- wake_up(>wait);
+ wake_up(>wait, TASK_UNINTERRUPTIBLE | TASK_INTERRUPTIBLE,
+WQ_FLAG_EXCLUSIVE);
- spin_unlock_irqrestore(_lock, flags);
+ wq_write_unlock_irqrestore(>wait.lock, flags);
return 1;
}
--- linux-2.4.0-test11-pre7/kernel/sched.c Sat Nov
[patch] Remove tq_scheduler
This patch removes tq_scheduler from the kernel. All uses of
tq_scheduler are migrated over to use schedule_task().
Notes:
- In two places: drivers/block/paride/pseudo.h and
drivers/net/wan/sdlamain.c we are re-adding tasks to tq_scheduler
within the callback. That means that these functions are being
called _every_ time the machine calls schedule().
It may be a limited case for paride, but sdlamain.c appears to be
doing this wicked thing all the time.
Now, if you do this with the current schedule_task() your machine
will hang up. So schedule_task() has been changed to support this
practice. If we see that the task queue has waiters on it we still
call schedule(), but we do it in state TASK_RUNNING.
- The patch adds to context.c a new API function
run_schedule_tasks() which immediately runs the queued tasks. Must
only be called from process context. serial.c needs this in its
shutdown routines.
- If anyone sleeps in a callback, then all other users of
schedule_task() also sleep. But there's nothing new here. Kinda
makes one wonder why schedule_task exists. But what-hey, it's neat.
- Note the careful massaging of module reference counts.
Yes my friends, much usage of task queues in modules is racy wrt
module removal. This patch fixes some of them.
The approach taken here is to increment the module refcount when we
enqueue a task and to decrement it in the handler:
mainline()
{
...
MOD_INC_USE_COUNT;
if (schedule_task(some_wq) == 0)
MOD_DEC_USE_COUNT;
}
handler()
{
...
MOD_DEC_USE_COUNT;
/* Wheee! Tiny race here */
return;
}
Note that queue_task and schedule_task have been enhanced to return
a success indicator. If this is non-zero you know that your task
will be run. If it returns zero then your tq_struct was already
queued and you lose.
The patch against test11-pre7 (1043 lines) is at
http://www.uow.edu.au/~andrewm/linux/tq_scheduler.patch
It affects the following files:
include/linux/tqueue.h
include/linux/sched.h
include/linux/compatmac.h
arch/ppc/8xx_io/uart.c
arch/ppc/8xx_io/fec.c
arch/ppc/8260_io/uart.c
drivers/net/wan/sdlamain.c
drivers/block/paride/pseudo.h
drivers/char/tty_io.c
drivers/char/esp.c
drivers/char/istallion.c
drivers/char/riscom8.c
drivers/char/serial.c
drivers/char/README.epca
drivers/char/specialix.c
drivers/char/epca.c
drivers/char/isicom.c
drivers/char/moxa.c
drivers/char/mxser.c
drivers/char/stallion.c
drivers/scsi/megaraid.c
drivers/scsi/qla1280.c
drivers/isdn/avmb1/b1capi.c
drivers/isdn/avmb1/kcapi.c
drivers/sbus/char/sab82532.c
drivers/sbus/char/aurora.c
drivers/ide/ide.c
drivers/usb/serial/keyspan_pda.c
drivers/usb/serial/digi_acceleport.c
drivers/i2o/i2o_lan.c
fs/smbfs/sock.c
kernel/sched.c
kernel/ksyms.c
kernel/timer.c
kernel/context.c
-
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/
IGNORE Previous! [patch] Removal of oops->printk deadlocks
[ Sorry - the last one was bogus test11-pre4 stuff ]
Linus,
this patch removes the final things which can cause oopses and other
sad events to deadlock without providing diagnostics.
I've changed it a little since Ingo provided comments - the
poke_blanked_console() changes have been simplified.
- If four places: oops, die(), NMI-oops and BUG() we call
bust_spinlocks(1) to set `oops_in_progress' to tell the printk and
console systems that they should not acquire any locks.
- After the message has gone out we call bust_spinlocks(0) to turn
off oops_in_progress and to do a 'printk(" \b");'. This allows
printk() to wake up klogd and allows the vgacon driver to turn the
screen back on.
- The NMI oopser has been enhanced so you can optionally get the NMI
oops traces for all the CPUs. You boot your kernel with the option:
nmi_watchdog=1,verbose
This is for those fun situations where your machine wedges after an
NMI oops.
- This is pretty specific to x86/vgacon, but everything is in place
for other architectures.
--- linux-2.4.0-test11-pre7/include/linux/kernel.h Sat Nov 18 13:55:32 2000
+++ linux-akpm/include/linux/kernel.h Sat Nov 18 14:44:08 2000
@@ -66,6 +66,7 @@
asmlinkage int printk(const char * fmt, ...)
__attribute__ ((format (printf, 1, 2)));
+extern int oops_in_progress;
#if DEBUG
#define pr_debug(fmt,arg...) \
--- linux-2.4.0-test11-pre7/include/asm-i386/page.h Sat Nov 4 16:22:49 2000
+++ linux-akpm/include/asm-i386/page.h Sat Nov 18 14:44:08 2000
@@ -88,8 +88,9 @@
* Tell the user there is some problem. Beep too, so we can
* see^H^H^Hhear bugs in early bootup as well!
*/
+extern void do_BUG(const char *file, int line);
#define BUG() do { \
- printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
+ do_BUG(__FILE__, __LINE__); \
__asm__ __volatile__(".byte 0x0f,0x0b"); \
} while (0)
--- linux-2.4.0-test11-pre7/kernel/printk.c Sat Nov 4 16:22:49 2000
+++ linux-akpm/kernel/printk.c Sat Nov 18 14:44:08 2000
@@ -51,6 +51,7 @@
static unsigned long logged_chars;
struct console_cmdline console_cmdline[MAX_CMDLINECONSOLES];
static int preferred_console = -1;
+int oops_in_progress;
/*
* Setup a list of consoles. Called from init/main.c
@@ -260,6 +261,8 @@
static signed char msg_level = -1;
long flags;
+ if (oops_in_progress)
+ spin_lock_init(_lock);
spin_lock_irqsave(_lock, flags);
va_start(args, fmt);
i = vsprintf(buf + 3, fmt, args); /* hopefully i < sizeof(buf)-4 */
@@ -308,7 +311,8 @@
msg_level = -1;
}
spin_unlock_irqrestore(_lock, flags);
- wake_up_interruptible(_wait);
+ if (!oops_in_progress)
+ wake_up_interruptible(_wait);
return i;
}
--- linux-2.4.0-test11-pre7/arch/i386/mm/fault.cSat Nov 18 13:55:28 2000
+++ linux-akpm/arch/i386/mm/fault.c Sat Nov 18 14:44:08 2000
@@ -24,6 +24,7 @@
#include
extern void die(const char *,struct pt_regs *,long);
+extern int console_loglevel;
/*
* Ugly, ugly, but the goto's result in better assembly..
@@ -77,17 +78,40 @@
return 0;
}
-extern spinlock_t console_lock, timerlist_lock;
+#ifdef CONFIG_SMP
+extern unsigned volatile int global_irq_lock;
+#endif
/*
* Unlock any spinlocks which will prevent us from getting the
- * message out (timerlist_lock is aquired through the
- * console unblank code)
+ * message out and tell the printk/console paths that an emergency
+ * message is coming through
*/
-void bust_spinlocks(void)
+void bust_spinlocks(int yes)
{
- spin_lock_init(_lock);
- spin_lock_init(_lock);
+ if (yes) {
+ oops_in_progress = 1;
+#ifdef CONFIG_SMP
+ global_irq_lock = 0;/* Many serial drivers do __global_cli() */
+#endif
+ } else {
+ int loglevel_save = console_loglevel;
+ oops_in_progress = 0;
+ /*
+* OK, the message is on the console. Now we call printk()
+* without oops_in_progress set so that printk will give klogd
+* a poke. Hold onto your hats...
+*/
+ console_loglevel = 15; /* NMI oopser may have shut the
+console up */
+ printk(" \b");
+ console_loglevel = loglevel_save;
+ }
+}
+
+void do_BUG(const char *file, int line)
+{
+ bust_spinlocks(1);
+ printk("kernel BUG at %s:%d!\n", file, line);
}
asmlinkage void do_invalid_op(struct pt_regs *, unsigned long);
@@ -264,8 +288,7 @@
* terminate things with extreme prejudice.
*/
- bust_spinlocks();
-
+ bust_spinlocks(1);
if (address < PAGE_SIZE)
printk(KERN_ALERT "Unable to handle kernel NULL pointer dereference");
else
@@ -283,6 +306,7 @@
printk(KERN_ALERT "*pte = %08lx\n", page);
}
die("Oops", regs,
[patch] remove oops->printk deadlock
Linus,
patch removes the last deadlock opportunity in the x86 oops and
NMI oopser path, namely the call to wake_up_interruptible()
within printk itself. (Apart from vga_lock, which isn't
worth the fuss).
bust_spinlocks() disappears again in favour of a global integer
`oops_in_progress'.
I've only reviewed the vt_console device talking to vgacon. Other
console devices almost certainly have deadlock opportunities. They're
easy to fix:
+ if (oops_in_progress)
+ spin_lock_init(_lock); /* Sorry, George */
spin_lock(_lock);
Other SMP-capable architectures may simply set and clear
oops_in_progress at the appropriate times.
poke_blanked_console() can come back if we want. Just don't
call it if oops_in_progress is true.
--- linux-2.4.0-test11-pre4/include/linux/kernel.h Sun Oct 15 01:27:46 2000
+++ linux-akpm/include/linux/kernel.h Mon Nov 13 19:44:58 2000
@@ -62,6 +62,7 @@
asmlinkage int printk(const char * fmt, ...)
__attribute__ ((format (printf, 1, 2)));
+extern int oops_in_progress;
#if DEBUG
#define pr_debug(fmt,arg...) \
--- linux-2.4.0-test11-pre4/kernel/printk.c Sat Nov 4 16:22:49 2000
+++ linux-akpm/kernel/printk.c Mon Nov 13 19:58:36 2000
@@ -51,6 +51,7 @@
static unsigned long logged_chars;
struct console_cmdline console_cmdline[MAX_CMDLINECONSOLES];
static int preferred_console = -1;
+int oops_in_progress;
/*
* Setup a list of consoles. Called from init/main.c
@@ -260,6 +261,8 @@
static signed char msg_level = -1;
long flags;
+ if (oops_in_progress)
+ spin_lock_init(_lock);
spin_lock_irqsave(_lock, flags);
va_start(args, fmt);
i = vsprintf(buf + 3, fmt, args); /* hopefully i < sizeof(buf)-4 */
@@ -308,7 +311,8 @@
msg_level = -1;
}
spin_unlock_irqrestore(_lock, flags);
- wake_up_interruptible(_wait);
+ if (!oops_in_progress)
+ wake_up_interruptible(_wait);
return i;
}
--- linux-2.4.0-test11-pre4/arch/i386/mm/fault.cMon Nov 13 18:23:49 2000
+++ linux-akpm/arch/i386/mm/fault.c Mon Nov 13 19:44:58 2000
@@ -77,19 +77,6 @@
return 0;
}
-extern spinlock_t console_lock, timerlist_lock;
-
-/*
- * Unlock any spinlocks which will prevent us from getting the
- * message out (timerlist_lock is aquired through the
- * console unblank code)
- */
-void bust_spinlocks(void)
-{
- spin_lock_init(_lock);
- spin_lock_init(_lock);
-}
-
asmlinkage void do_invalid_op(struct pt_regs *, unsigned long);
extern unsigned long idt;
@@ -264,8 +251,7 @@
* terminate things with extreme prejudice.
*/
- bust_spinlocks();
-
+ oops_in_progress = 1;
if (address < PAGE_SIZE)
printk(KERN_ALERT "Unable to handle kernel NULL pointer dereference");
else
@@ -283,6 +269,7 @@
printk(KERN_ALERT "*pte = %08lx\n", page);
}
die("Oops", regs, error_code);
+ oops_in_progress = 0;
do_exit(SIGKILL);
/*
--- linux-2.4.0-test11-pre4/arch/i386/kernel/traps.cMon Nov 13 18:23:49 2000
+++ linux-akpm/arch/i386/kernel/traps.c Mon Nov 13 19:44:58 2000
@@ -63,7 +63,6 @@
struct desc_struct idt_table[256] __attribute__((__section__(".data.idt"))) = { {0,
0}, };
extern int console_loglevel;
-extern void bust_spinlocks(void);
static inline void console_silent(void)
{
@@ -437,12 +436,13 @@
* We are in trouble anyway, lets at least try
* to get a message out.
*/
- bust_spinlocks();
+ oops_in_progress = 1;
printk("NMI Watchdog detected LOCKUP on CPU%d, registers:\n",
cpu);
show_registers(regs);
printk("console shuts up ...\n");
console_silent();
spin_unlock(_print_lock);
+ oops_in_progress = 0;
do_exit(SIGSEGV);
}
} else {
-
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] SMP race in exit()
Linus,
There is an SMP race on process exit.
The exitting process sets TASK_ZOMBIE and calles schedule(). The next
task to run clears the exitting tasks's task_struct.has_cpu in
__schedule_tail. At this point in time the parent, which may be
spinning in fork.c:release() is free to go ahead and reap the child's
stack pages. But __schedule_tail continues to play with the exitting
process's task_struct. There is a window here where __schedule_tail is
reading and writing potentially free memory.
The fix is easy: make the parent synchronise on the exitting child's
alloc_lock, not the runqueue lock.
--- linux-2.4.0-test11-pre7/kernel/exit.c Sat Nov 18 13:55:32 2000
+++ linux-akpm/kernel/exit.cSat Nov 18 14:35:25 2000
@@ -22,7 +22,7 @@
int getrusage(struct task_struct *, int, struct rusage *);
-static void release(struct task_struct * p)
+static void release_task(struct task_struct * p)
{
if (p != current) {
#ifdef CONFIG_SMP
@@ -31,15 +31,15 @@
* runqueue (active on some other CPU still)
*/
for (;;) {
- spin_lock_irq(_lock);
+ task_lock(p);
if (!p->has_cpu)
break;
- spin_unlock_irq(_lock);
+ task_unlock(p);
do {
barrier();
} while (p->has_cpu);
}
- spin_unlock_irq(_lock);
+ task_unlock(p);
#endif
atomic_dec(>user->processes);
free_uid(p->user);
@@ -550,7 +550,7 @@
do_notify_parent(p, SIGCHLD);
write_unlock_irq(_lock);
} else
- release(p);
+ release_task(p);
goto end_wait4;
default:
continue;
--- linux-2.4.0-test11-pre7/kernel/sched.c Sat Nov 18 13:55:32 2000
+++ linux-akpm/kernel/sched.c Sat Nov 18 14:36:29 2000
@@ -197,7 +197,7 @@
/*
* This is ugly, but reschedule_idle() is very timing-critical.
- * We `are called with the runqueue spinlock held and we must
+ * We are called with the runqueue spinlock held and we must
* not claim the tasklist_lock.
*/
static FASTCALL(void reschedule_idle(struct task_struct * p));
@@ -452,7 +452,7 @@
goto needs_resched;
out_unlock:
- task_unlock(prev);
+ task_unlock(prev); /* Synchronise here with release_task() if prev is
+TASK_ZOMBIE */
return;
/*
-
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: Freeze on FPU exception with Athlon
In article <[EMAIL PROTECTED]>, =?iso-8859-1?q?Markus=20Schoder?= <[EMAIL PROTECTED]> wrote: >The following small program (linked against glibc 2.1.3) reliably >freezes my system (Athlon Thunderbird CPU) with at least kernels >2.4.0-test10 and 2.4.0-test11-pre5. Even the SysRq keys do not work >after the freeze. Are you sure sysrq doesn't work? Many distributions will disable the kernel printing to the console, or move it to console 7 or similar. It would be really good to get the EIP trace of RightAlt+ScrollLock pressed a few times if you can try to see if you can use klogd to enable proper printk's. >Older kernels (e.g. 2.3.40) seem to work. Any Ideas? The FP exception handling has certainly changed, but the changes should all have affected mainly just PIII kernels with XMM support enabled. An Athlon system should have been pretty unaffected. But I'll take a look if I see something obvious. One thing to try: if interrupts really don't work for you (and if SysRq doesn't work, that may be the case), please test out a kernel that simply ignores irq13 by just commenting out the line setup_irq(13, ); in arch/i386/kernel/i8259.c. Does that make any difference? (irq13 shouldn't be used any more, it's horrible legacy crap, but we do want to support even horrible legacy systems). Linus - 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: test11-pre7 compile failure
In article <[EMAIL PROTECTED]>, J Sloan <[EMAIL PROTECTED]> wrote: > >looks like the md fixes broke something - > >In file included from /usr/src/linux/include/linux/pagemap.h:17, > from /usr/src/linux/include/linux/locks.h:9, > from /usr/src/linux/include/linux/raid/md.h:37, > from init/main.c:25: >/usr/src/linux/include/linux/highmem.h: In function `bh_kmap': >/usr/src/linux/include/linux/highmem.h:23: structure has no member named >`p_page' The "p_page" should be a "b_page". Duh. Linus - 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: Missing ACKs with Linux 2.2/2.4?
In article <[EMAIL PROTECTED]> you wrote: > Sorry, ignoring some values of timestamp is simply impossible. > It is PAWS. One packet is more than enough to kill you. 8) Hmm... Isnt this only important for the first SYN with a Zero Timestamp which is not very critical for PAWS? Greetings Bernd - 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: Missing ACKs with Linux 2.2/2.4?
In article <[EMAIL PROTECTED]> you wrote: > Timestamp is not a random number, so that probability of PAWS failure > does not depend on restricting it at all. The only thing which can help > to reduce probability is dropping all tpacket with ts_val==0 > or shutting down your machine while time of your peers passes through zero. 8) But Timestamps are not increased by one every packet, so the likelyhood that a wraparound a) happens and b) happens while a packet is send is realy small. Greetings Bernd - 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: Advanced Linux Kernel/Enterprise Linux Kernel
In article <[EMAIL PROTECTED]> you wrote: > But also scalability: 2TB is a problem for me in some cases, 32bit just don't > cut it all the time - but I need to circumvent the storage problem even on a > 32bit system. And adding disks to the system while running is desireable. Why do you run 32bit Systems in the First Place? This can solve a lot of flaky PC Hardware Issues, too... (also it does not help in Hotplug PCI and CPU). Greetings Bernd - 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/
Errors in aa2
Hi everyone. When compiling Andreas aa2 patch I got: /usr/bin/kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O4 -fomit-frame-pointer -fno-strict-aliasing -D__SMP__ -pipe -fno-strength-reduce -march=i686 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o time.o time.c time.c: In function `do_gettimeofday': time.c:727: fixed or forbidden register 0 (ax) was spilled for class AREG. This may be due to a compiler bug or to impossible asm statements or clauses. The only difference is the inclusion of timeval_normalize. If I get time.c from 2.2.18-pre21 compiles fine. But I don't see any strange asm round there... -- Juan Antonio Magallon Lacarta #> cd /pub mailto:[EMAIL PROTECTED] #> more beer - 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: sunhme.c patch for new PCI interface (UNTESTED)
I wrote:
>[...] the cost of incorrectly
>using __initdata when __devinitdata was correct is that the user's
>KERNEL WILL CRASH when the notebook is inserted or removed from such a
>docking station, even when the kernel is built with CONFIG_HOTPLUG.
My statement above, without some missing qualification, is wrong.
I should have qualified this statement more carefully. (I'm sure the
flames are already in the mail about this.) The kernel will crash in
any case if the relevant driver does not support hot plugging.and the
notebook is being removed with the PCI driver still loaded.
For drivers that do not support hot plugging, we could use
__initdata instead of __devinitdata, since they will crash in any
case. However, violating the instructions in Documentation/pci.txt
("The ID table array should be marked __devinitdata") in this way
will provoke a slew of driver bugs as the over one hundred remaining
PCI drivers are converted to the new PCI interface and some authors
overlook the need to change the MODULE_DEVICE_TABLE storage class.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
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: VGA PCI IO port reservations
Followup to: <[EMAIL PROTECTED]> By author:Olivier Galibert <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > What guarantees you that: > 1- No device will respond 0x for an address it decodes > 2- No device will crap up on you simply because you've read one > particular address > > If any of these if true for any device out there (I think I have one > in my computer that does the 1/ part in some cases), your code is > unsafe. > It is. There are plenty of devices for which an arbitrary IN is an irrecoverable state transition. -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: [BUG] Inconsistent behaviour of rmdir
On 18 Nov 2000, Nix wrote: > Alexander Viro <[EMAIL PROTECTED]> writes: > > > If every way from foo to target goes through the source rename(source,target) > > _will_ make the graph disconnected. Checking that for generic DAG is a hell. > > Why do you say this? Algorithms for cycle detection are comparatively > computationally expensive, to be sure, but they are well understood. In s/computationally/& and IO/. If we are thinking about the same algorithm - good luck doing that if your data structures are on disk. Think of reference locality in that animal. Try to estimate the amount of IO and fun with seeks. It's nice when you have your data in-core, but when it's on-disk and you want reasonable locality of references for normal uses... - 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: sunhme.c patch for new PCI interface (UNTESTED)
>I am willing to consider adding __devxxx only when other __devxxx
>entries already exist.
>These conversions to _devxxx are too late in the freeze, and only have
>value for isolated cases --which you admit you don't even know exist--.
>Linus Rule 1: Don't overdesign.
Even ignoring CardBus, there apparently are docking
stations that have PCI busses, such as shown in
http://www.pangolin.com/LD2000/dock/gateway.htm ("Each supports hot
docking, so you can attach or detach your system without turning it
off"), and a web search turns up plenty of hits, at least for mobile
chipsets apparently designed for this. It looks like this is a
pretty standard capability.
Even if we were unsure, the more conservative approach would
be to use __devinitdata. The only cost of incorrectly using __devinitdata
instead of __initdata, would be to make the effected kernel module
use ~100 bytes more unswappable kernel memory when CONFIG_HOTPLUG is
defined and the module is loaded (28 bytes per entry, including a null
entry). On the other side that risk comparison, the cost of incorrectly
using __initdata when __devinitdata was correct is that the user's
KERNEL WILL CRASH when the notebook is inserted or removed from such a
docking station, even when the kernel is built with CONFIG_HOTPLUG.
Although I'm not into quoting any programmer like some religious
figure, I will say that I think you're misinterpreting the meaning of
an admonition like "Don't overdesign." We are not talking about designing
some new abstraction or making the code more complex, but rather
selecting rather a choice between two words, one of which is the more
conservatively crash resistant __devinitdata, the other of which would
save 28 bytes in CONFIG_HOTPLUG kernels only, and at the expense of
probably causing kernel crashes.
>Even if such cases do exist, and this
>is a need, it should be addressed some other way.
1. Why?
2. What other way did you have in mind?
By the way, although I do not have the PCI standard here, I do
see from _PCI System Architecture_, 4th edition, chapter 19,
"Configuration Registers", in the "Device ID Register" section that
devices "designed around the same third party core logic" are allowed
to have the same device ID (and they are even complaint to PCI 2.2 if
they have different Subsystem ID values). So, my approach also has
the minor advantage that if a vendor wants to ship a hot pluggable
version of their PCI card in the future with the same device ID
(a likely decision), then there may not need to coordinate a new
release of the Linux driver. (This is a really small benefit; the
kernel crashes that you want to change my existing patches to produce
is the big issue.)
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
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] Inconsistent behaviour of rmdir
Alexander Viro <[EMAIL PROTECTED]> writes:
> If every way from foo to target goes through the source rename(source,target)
> _will_ make the graph disconnected. Checking that for generic DAG is a hell.
Why do you say this? Algorithms for cycle detection are comparatively
computationally expensive, to be sure, but they are well understood. In
fact, this is only a limited case of cycle detection; unless I
misunderstand, it's a form of dominator detection, as seen, for
instance, in compilers. You're looking to see if the source dominates
the target, and if it does, you scream.
It needn't be hellish, *if* we can get a list of all a directory's
parents given that directory in reasonable time, and that depends on how
multiple-parents is implemented. Checking if the source dominates the
target (for paths from the root) wouldn't be anywhere near so bad
then. See below for an algorithm to try out --- well, for its name. I
have a good few references to relevant papers too (so too will anyone
with much to do with compiler hacking.)
> Moreover, if there is an oriented path from source to target rename(source,
> target) will create a loop. Again, good luck checking whether there is
> such a path.
Loops and what they do to things like ftw() --- and thus to the
expectations of userspace programs --- are I think the *real* reason why
no Unix has ever implemented this. There are probably a good few
programs that depend on ftw() and friends descending into all
directories that you asked them to, and then there's all those recursive
tree traversers in userspace that *don't* use ftw().
Certainly all cycles must be banned. Luckily the cycles aren't that
nasty to detect. You can detect cycles with the same algorithm you use
to detect the rename(source,target) case; if the source dominates the
target you can't have a link to the source in the target, as that would
make a cycle. (I may be missing some cases that make cycle detection
harder than this; it's late and I'm drunk and tired, and it's been years
since I paid much attention to anything much to do with cycle
detection.)
> If you think that loops are not a problem - fine, their presense
> will make checking the first condition (for every node foo there exists a
> path foo,p1,...,pn,target such that source doesn't belong to {p1,...,pn})
> _much_ funnier.
It's userspace that this kills; the kernel can be fixed, but fixing the
entirety of userspace isn't going to happen :)
> For trees both conditions turn into (source is not an ancestor of target)
> and that's easy to check. Try to do that for generic DAG. Solutions that
> cost O(graph size) are _not_ acceptable - graph is the whole directory
> structure.
There are well-understood algorithms for computing dominators that do
not cost that much. The Lengauer-Tarjan algorithm takes O(n ln n) time,
where n is the depth of the graph (== the depth of the deepest path to
get to the target). However it is rather heavy-duty for a kernel, and I
rather doubt that any kernels use it :)
The O(graph size) solutions are deeply crap ways of computing
dominators; they normally start by sweeping over the whole graph working
out who dominates who from the top down. Algorithms like that were
obsolete by the late seventies!
Lengauer-Tarjan works from the bottom up; as long as you can do that,
you're home free. (Well, not free; O(n ln n.) ;} )
Ancient paper reference (there are probably newer papers than this):
Lengauer, T., & Tarjan, R. E., _A fast algorithm for finding dominators
in a flow graph_, 1979, _Transactions on Programming Languages and
Systems_ 13(4): 451--490.
(Somewhere, I have a copy of this paper. Cthulhu alone knows where
though.)
(Disclaimer: I've never tried to use Lengauer-Tarjan in filesystem code;
it just seems likely to me that it or some variant of it would work
there, except of course that it is a somewhat overblown algorithm to
find in a kernel. :) )
--
`The phrase `causes storage to be reserved', doesn't mean that it causes
storage to be reserved. This is a fundamental misunderstanding of
Standardeze.' --- Mike Stump on the GCC list
-
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.2.18pre21
Peter Samuelson <[EMAIL PROTECTED]> writes: > Two easy "get out of jail free" cards. There are other, more complex > exploits. You have added one more. They all require root privileges. Unless I'm missing something, not all of them do. I haven't checked this or anything, but it seems to me that all you need is a cooperating process outside the jail, that opens some world-readable directory and sends it to the exploit process inside the jail, which fchdir()s to it. Of course you *do* need an AF_UNIX socket inside the jail for this, too, so it is probably a quite unlikely attack; but if, for instance, you reused an outside-the-jail uid *inside* the jail, and the jail had places writable by this user... bing, no root necessary. -- `The phrase `causes storage to be reserved', doesn't mean that it causes storage to be reserved. This is a fundamental misunderstanding of Standardeze.' --- Mike Stump on the GCC list - 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/
Freeze on FPU exception with Athlon
The following small program (linked against glibc
2.1.3) reliably
freezes my system (Athlon Thunderbird CPU) with at
least kernels
2.4.0-test10 and 2.4.0-test11-pre5. Even the SysRq
keys do not work
after the freeze.
Older kernels (e.g. 2.3.40) seem to work. Any Ideas?
---
#define _GNU_SOURCE
#include
#include
int
main(void)
{
double a;
fesetenv(FE_NOMASK_ENV);
a = 1.0 / 0.0;
sleep(10);
return a;
}
---
--
Markus
__
Do You Yahoo!?
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Gratis zum Millionär! - http://10millionenspiel.yahoo.de
-
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/
test11-pre7 compile failure
Just a quick heads-up - looks like the md fixes broke something - In file included from /usr/src/linux/include/linux/pagemap.h:17, from /usr/src/linux/include/linux/locks.h:9, from /usr/src/linux/include/linux/raid/md.h:37, from init/main.c:25: /usr/src/linux/include/linux/highmem.h: In function `bh_kmap': /usr/src/linux/include/linux/highmem.h:23: structure has no member named `p_page' In file included from /usr/src/linux/include/linux/raid/md.h:51, from init/main.c:25: /usr/src/linux/include/linux/raid/md_k.h: In function `pers_to_level': /usr/src/linux/include/linux/raid/md_k.h:39: warning: control reaches end of non-void function make: *** [init/main.o] Error 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: VFS Kernel Panic in 2.4.0-10(11)
On Fri, 17 Nov 2000, Jeff V. Merkey wrote: > > This is probably a configuration mismatch of some kind, but I just > finished building my 2.4.0 RPM skeletons and am installting them from > our latest CD burn, and I am seeing the following > problem when I upgrade our 2.2.17 kernel versions with 2.4.0-test10, > then reboot them under 2.4: > > request_module[block-major-3]: Root fs not mounted > VFS cannot open root device "301" or 03:01 > Please append a correct "root=" boot option > Kernel panic: VFS: Unable to mount root fs on 03:01. IDE built as module. Root on IDE disk. Apparently, no initrd in sight. Check your .config and either don't make IDE a module or enable initrd and make sure to put the modules into initrd image. - 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: VFS Kernel Panic in 2.4.0-10(11)
We dfound it. 2.2.X .configs are incompatible with 2.4.0 and the upgrade RPMs sucked them in. Since IDE is a unique CONFIG option, this will break. Jeff "Jeff V. Merkey" wrote: > > > This is probably a configuration mismatch of some kind, but I just > finished building my 2.4.0 RPM skeletons and am installting them from > our latest CD burn, and I am seeing the following > problem when I upgrade our 2.2.17 kernel versions with 2.4.0-test10, > then reboot them under 2.4: > > request_module[block-major-3]: Root fs not mounted > VFS cannot open root device "301" or 03:01 > Please append a correct "root=" boot option > Kernel panic: VFS: Unable to mount root fs on 03:01. > > The system was running Ute-Linux under 2.2.17 then was upgraded to > 2.4.0-10 (with IPVS and pre-11 patches). > The disk is a 20GB device with > > /dev/hda1Linux (/,/boot) at > 3,1 > /dev/hda2Extended (contains a swap partition /dev/hda5) at > 3,2 > /dev/hda3Linux (/usr) at > 3,3 > /dev/hda4Linux (/archive) at > 3,4 > /dev/hda5Swap Swap at > 3,5 > > Lilo is configured in linear mode. The device it's complaining about is > present > (03:01) and lilo does append a root=/dev/hda1 statement. > > Any ideas? > > Jeff > - > 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/ - 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: Advanced Linux Kernel/Enterprise Linux Kernel
Daniel Phillips <[EMAIL PROTECTED]> writes: > Actually, I was planning on doing on putting in a hack to do something > like that: calculate a checksum after every buffer data update and check > it after write completion, to make sure nothing scribbled in the buffer > in the interim. This would also pick up some bad memory problems. Be very careful that this just applies to metadata. For normal data this is a valid case. Weird but valid. Eric - 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: isofs broken (2.2 and 2.4)
There's a test11-pre7 there now, and I'd really ask people to check out the isofs changes because slight worry about those is what held me up from just calling it test11 outright. It's almost guaranteed to be better than what we had before, but anyway.. Linus - 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: VGA PCI IO port reservations
On Fri, Nov 17, 2000 at 03:27:28PM -0500, Richard B. Johnson wrote: > Then, you read the port as a WORD (16 bits). If nothing responds, > you get the value of 0x. If somebody is responding, you will > read something if it's enabled for writes by devices (reads by the CPU). What guarantees you that: 1- No device will respond 0x for an address it decodes 2- No device will crap up on you simply because you've read one particular address If any of these if true for any device out there (I think I have one in my computer that does the 1/ part in some cases), your code is unsafe. OG. - 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: Reproducable oops in 2.2.17 and 2.2.18pre21
On Fri, 17 Nov 2000 14:49:38 Rasmus Andersen wrote: > Hi. > > I get an oops reproducably with 2.2.17 and 2.2.18pre21 on a stock RH 6.2 > system. I cannot trigger it with the RH supplied kernel (2.2.14-5.0). > I also got it with 2.2.17pre10 which prompted me to upgrade the kernel. > I initially suspected bad RAM but have exchanged the RAM with memtest86'ed > RAM for no improvement. > > What I do: I try to back the system up with tar zcvf /var/backup.tar.gz > -X exclude /lib /sbin /var /bin /etc /boot /home /root /usr > (the exclude file contains the path of the file itself, i.e., > /var/ backup.tar.gz). > Exclude /dev and /proc also, /lost+found if you have it, and /mnt if you only want that drive. Perhaps things like /proc/kcore make trouble... -- Juan Antonio Magallon Lacarta #> cd /pub mailto:[EMAIL PROTECTED] #> more beer - 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/
VFS Kernel Panic in 2.4.0-10(11)
This is probably a configuration mismatch of some kind, but I just finished building my 2.4.0 RPM skeletons and am installting them from our latest CD burn, and I am seeing the following problem when I upgrade our 2.2.17 kernel versions with 2.4.0-test10, then reboot them under 2.4: request_module[block-major-3]: Root fs not mounted VFS cannot open root device "301" or 03:01 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 03:01. The system was running Ute-Linux under 2.2.17 then was upgraded to 2.4.0-10 (with IPVS and pre-11 patches). The disk is a 20GB device with /dev/hda1Linux (/,/boot) at 3,1 /dev/hda2Extended (contains a swap partition /dev/hda5) at 3,2 /dev/hda3Linux (/usr) at 3,3 /dev/hda4Linux (/archive) at 3,4 /dev/hda5Swap Swap at 3,5 Lilo is configured in linear mode. The device it's complaining about is present (03:01) and lilo does append a root=/dev/hda1 statement. Any ideas? Jeff - 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] semaphore fairness patch against test11-pre6
Hi Linus et al,
I've applied your semaphore fairness patch (slightly fixed) below. It
fixes my original bug report of vmstat, ps etc. stalls waiting for the
mmap_sem. I can now run my memory 'hog' processes and actually see
vmstat update every second even under heavy memory pressure. More
importantly, ps works so I can find the pid to kill. I'm no expert in
checking for races, but I went over all (I think) the 2 process cases as
well as I could and they seem to look ok to me, but what do I know. I
know someone else reported it didn't fix the problem, but perhaps that's
some other issue.
I ran many 'ps' (20?) in the background trying to simulate many process
contention, and everything still worked fine. I've run some other
stress tests too (dbench, my own I/O throughput test etc) and so far
all's well (famous last words).
If you can find the time to check this out more completely, I recommend
it, because it seems like a great improvement to be able to accurately
see vmstat numbers in times of system load. I hope the other side
effects are beneficial as well :-)
The change to the patch was that you had 'if (sleepers > 1)' when
obviously you meant 'if (sem->sleepers > 1)'...
Here's your patch again (also attached in case of mangling):
--- linux/arch/i386/kernel/semaphore.c 2000/11/16 19:58:26 1.3
+++ linux/arch/i386/kernel/semaphore.c 2000/11/17 23:12:48
@@ -64,6 +64,14 @@
spin_lock_irq(_lock);
sem->sleepers++;
+
+ /*
+* Are there other people waiting for this?
+* They get to go first.
+*/
+ if (sem->sleepers > 1)
+ goto inside;
+
for (;;) {
int sleepers = sem->sleepers;
@@ -76,6 +84,7 @@
break;
}
sem->sleepers = 1; /* us - see -1 above */
+inside:
spin_unlock_irq(_lock);
schedule();
Index: linux/arch/i386/kernel/semaphore.c
===
RCS file: /home/kernel/cvs_master/linux/arch/i386/kernel/semaphore.c,v
retrieving revision 1.3
diff -u -r1.3 semaphore.c
--- linux/arch/i386/kernel/semaphore.c 2000/11/16 19:58:26 1.3
+++ linux/arch/i386/kernel/semaphore.c 2000/11/17 23:12:48
@@ -64,6 +64,14 @@
spin_lock_irq(_lock);
sem->sleepers++;
+
+ /*
+* Are there other people waiting for this?
+* They get to go first.
+*/
+ if (sem->sleepers > 1)
+ goto inside;
+
for (;;) {
int sleepers = sem->sleepers;
@@ -76,6 +84,7 @@
break;
}
sem->sleepers = 1; /* us - see -1 above */
+inside:
spin_unlock_irq(_lock);
schedule();
Re: test11-pre6 still very broken
On Fri, 17 Nov 2000 20:00:49 + (GMT), Tigran Aivazian <[EMAIL PROTECTED]> wrote: >The mysterious lockups in test11-pre5 continue in test11-pre6. It is very >difficult because the lockups appear to be kdb-specific (and kdb itself >goes mad) but when there is no kdb there is very little useful information >one can extract from a dead system... Race in user space debug registers versus kdb. Only appears on SMP systems. Working on fix. - 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: isofs broken (2.2 and 2.4)
>> I take it you'll also do the third part? > Are you talking about isofs_lookup_grandparent()? No, about isofs_read_inode. Andries - 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/
lseek/llseek allows the negative offset
# gcc x.c
# ./a.out
lseek on -10: -10
write: File too large
Should kernel allow negative offsets for lseek/llseek?
--
H.J. Lu ([EMAIL PROTECTED])
---
#include
#include
#include
extern loff_t llseek (int fd, loff_t offset, int whence);
int
main ()
{
int fd = open ("/tmp/foo.out", O_CREAT | O_RDWR, 0600);
off_t res, pos;
loff_t lres, lpos;
char buffer [] = "negative offset";
if (fd < 0)
{
perror ("open");
return 1;
}
pos = -10;
res = lseek (fd, pos, SEEK_SET);
if (res == (off_t) -1L)
{
perror ("lseek");
close (fd);
return 1;
}
printf ("lseek on %ld: %ld\n", pos, res);
if (write (fd, buffer, sizeof (buffer)) != sizeof (buffer))
{
perror ("write");
close (fd);
return 1;
}
lpos = -10LL;
lres = llseek (fd, lpos, SEEK_SET);
if (lres == (loff_t) -1L)
{
perror ("llseek");
close (fd);
return 1;
}
printf ("llseek on %lld: %lld\n", lpos, lres);
if (write (fd, buffer, sizeof (buffer)) != sizeof (buffer))
{
perror ("write");
close (fd);
return 1;
}
close (fd);
return 0;
}
-
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: isofs broken (2.2 and 2.4)
Oh, and sorry - the last patch doesn't contain the (obvious) fixes to the header files to take some of the calling convention changes into account. Linus --- --- v2.4.0-test10/linux/include/linux/iso_fs.h Fri Sep 8 12:52:56 2000 +++ linux/include/linux/iso_fs.hFri Nov 17 15:52:03 2000 @@ -177,16 +177,17 @@ extern int parse_rock_ridge_inode(struct iso_directory_record *, struct inode *); extern int get_rock_ridge_filename(struct iso_directory_record *, char *, struct inode *); +extern int isofs_name_translate(struct iso_directory_record *, char *, struct inode +*); extern int find_rock_ridge_relocation(struct iso_directory_record *, struct inode *); -int get_joliet_filename(struct iso_directory_record *, struct inode *, unsigned char *); +int get_joliet_filename(struct iso_directory_record *, unsigned char *, struct inode +*); int get_acorn_filename(struct iso_directory_record *, char *, struct inode *); extern struct dentry *isofs_lookup(struct inode *, struct dentry *); extern int isofs_get_block(struct inode *, long, struct buffer_head *, int); extern int isofs_bmap(struct inode *, int); -extern int isofs_lookup_grandparent(struct inode *, int); +extern struct buffer_head *isofs_bread(struct inode *, unsigned int, unsigned int); extern struct inode_operations isofs_dir_inode_operations; extern struct file_operations isofs_dir_operations; - 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: isofs broken (2.2 and 2.4)
On Sat, 18 Nov 2000 [EMAIL PROTECTED] wrote: > > But now that you did two-thirds of the job I take it you'll > also do the third part? It is again precisely the same stuff. Are you talking about isofs_lookup_grandparent()? The code is now dead, and has been for a long time actually (as the VFS layer keeps track of ".." for us these days). Removed. I'll look at the isofs_read_level3_size() thing. At least that one doesn't have the name translation crap in it. Linus - 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] CONFIG_EISA note in Documentation/Configure.help
> Some clues here > ... escd.html ... escd.rtf Thanks! I already had the former (but it refers to the EISA spec for most details) will look for the latter. Andries - 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: isofs broken (2.2 and 2.4)
On Fri, 17 Nov 2000, Harald Koenig wrote:
>
> Linus:0.380u 76.850s 1:19.12 97.6%0+0k 0+0io 113pf+0w
> Andries: 0.470u 97.220s 1:40.29 97.4%0+0k 0+0io 112pf+0w
The biggest difference is just the system times and the fact that it's
more efficient coding.
> BUT: there are some obvious bugs in the output of "du" and "find".
> some samples (all file names (should) match the format "xe%03d/xe%03d.%c%c"
> with both %03d being the _same_ number and both %c are in [a-z0-9]).
Yes. There's a silly bug there, now that I've tested it a bit. Basically
the test for stuff that traversed a boundary was wrong.
The whole name conversion code is pretty horrible. It's been written over
the years, and it was doing the same thing with small modifications in
both readdir() and lookup(). I've got a cleaned up version that also
should have the above bug fixed.
Still ready to test? This time I went over the files rather carefully, and
while I've not tested the fixed version I'm getting pretty happy with it.
I'll merge some more of the name translation logic, but before I do that
here's the newest patch..
Linus
-
diff -u --recursive --new-file v2.4.0-test10/linux/fs/isofs/dir.c linux/fs/isofs/dir.c
--- v2.4.0-test10/linux/fs/isofs/dir.c Fri Aug 11 14:29:01 2000
+++ linux/fs/isofs/dir.cFri Nov 17 15:43:36 2000
@@ -40,14 +40,17 @@
lookup: isofs_lookup,
};
-static int isofs_name_translate(char * old, int len, char * new)
+int isofs_name_translate(struct iso_directory_record *de, char *new, struct inode
+*inode)
{
- int i, c;
+ char * old = de->name;
+ int len = de->name_len[0];
+ int i;
for (i = 0; i < len; i++) {
- c = old[i];
+ unsigned char c = old[i];
if (!c)
break;
+
if (c >= 'A' && c <= 'Z')
c |= 0x20; /* lower case */
@@ -74,8 +77,7 @@
{
int std;
unsigned char * chr;
- int retnamlen = isofs_name_translate(de->name,
- de->name_len[0], retname);
+ int retnamlen = isofs_name_translate(de, retname, inode);
if (retnamlen == 0) return 0;
std = sizeof(struct iso_directory_record) + de->name_len[0];
if (std & 1) std++;
@@ -105,7 +107,7 @@
unsigned char bufbits = ISOFS_BUFFER_BITS(inode);
unsigned int block, offset;
int inode_number = 0; /* Quiet GCC */
- struct buffer_head *bh;
+ struct buffer_head *bh = NULL;
int len;
int map;
int high_sierra;
@@ -117,46 +119,22 @@
return 0;
offset = filp->f_pos & (bufsize - 1);
- block = isofs_bmap(inode, filp->f_pos >> bufbits);
+ block = filp->f_pos >> bufbits;
high_sierra = inode->i_sb->u.isofs_sb.s_high_sierra;
- if (!block)
- return 0;
-
- if (!(bh = breada(inode->i_dev, block, bufsize, filp->f_pos, inode->i_size)))
- return 0;
-
while (filp->f_pos < inode->i_size) {
int de_len;
-#ifdef DEBUG
- printk("Block, offset, f_pos: %x %x %x\n",
- block, offset, filp->f_pos);
- printk("inode->i_size = %x\n",inode->i_size);
-#endif
- /* Next directory_record on next CDROM sector */
- if (offset >= bufsize) {
-#ifdef DEBUG
- printk("offset >= bufsize\n");
-#endif
- brelse(bh);
- offset = 0;
- block = isofs_bmap(inode, (filp->f_pos) >> bufbits);
- if (!block)
- return 0;
- bh = breada(inode->i_dev, block, bufsize, filp->f_pos,
inode->i_size);
+
+ if (!bh) {
+ bh = isofs_bread(inode, bufsize, block);
if (!bh)
return 0;
- continue;
}
de = (struct iso_directory_record *) (bh->b_data + offset);
- if(first_de) inode_number = (block << bufbits) + (offset & (bufsize -
1));
+ if (first_de) inode_number = (bh->b_blocknr << bufbits) + offset;
de_len = *(unsigned char *) de;
-#ifdef DEBUG
- printk("de_len = %d\n", de_len);
-#endif
-
/* If the length byte is zero, we should move on to the next
CDROM sector. If we are at the end of the directory, we
@@ -164,36 +142,33 @@
if (de_len == 0) {
brelse(bh);
- filp->f_pos = ((filp->f_pos & ~(ISOFS_BLOCK_SIZE - 1))
- + ISOFS_BLOCK_SIZE);
+ bh = NULL;
+ filp->f_pos = ((filp->f_pos & ~(ISOFS_BLOCK_SIZE - 1)) +
+ISOFS_BLOCK_SIZE);
+
Re: BUG: isofs broken (2.2 and 2.4)
Linus:
> How about this version (full patch against test10 - it includes a
> slightly corrected version of my earlier dir.c patch)?
> It's entirely untested, but it looks good and compiles. Ship it!
There are three files that have to be changed.
You changed dir.c yesterday, and namei.c today
but still have to do inode.c.
Your stuff resembles my stuff. In namei.c I also replaced the 15
lines following
} else if (dir->i_sb->u.isofs_sb.s_mapping == 'n') {
by the line
dlen = isofs_name_translate(dpnt, dlen, page);
But now that you did two-thirds of the job I take it you'll
also do the third part? It is again precisely the same stuff.
Andries
-
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] CONFIG_EISA note in Documentation/Configure.help
> My code does something like
>
> /*
> * EISA board N has a 4-byte ID that can be read from 0xNc80-0xNc83
> * return 0 for success, -1 for failure (no EISA card in slot) and
> * 1 when a card is present but still needs to be configured.
> */
> static int
> get_eisa_id(int board, char *id) {
This is actually a lot like the MCA bus needs but with a slightly different
API.
Some clues here
http://www.google.com/search?q=cache:www.korpse.freeserve.co.uk/hardware/pnp/html/escd.html+eisa+data+format=en
but the original seems to have gone from korpse 8(
Microsoft have escd.rtf that documents the escd in terms of eisa records thus
gives clues
-
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/
[patchlet] fix some typos and pathnames in Configure.help (fwd)
Hello, this fixes some typos and pathnames in pointers from Configure.help to files in the Documentation subtree. Not much, but better than nothing. Diff is against 2.4.0-test10. Matthias --- Documentation/Configure.help.orig Sat Nov 18 00:14:01 2000 +++ Documentation/Configure.helpFri Nov 17 23:35:47 2000 @@ -77,7 +77,7 @@ in some special cases. Detailed bug reports from people familiar with the kernel internals are usually welcomed by the developers (before submitting bug reports, please read the documents README, - MAINTAINERS, REPORTING_BUGS, Documentation/BUG-HUNTING, and + MAINTAINERS, REPORTING-BUGS, Documentation/BUG-HUNTING, and Documentation/oops-tracing.txt in the kernel source). This option will also make obsoleted drivers available. These are @@ -113,7 +113,7 @@ Management" code will be disabled if you say Y here. See also the files Documentation/smp.tex, Documentation/smp.txt, - Documentation/IO-APIC.txt, Documentation/nmi_watchdog.txt and the + Documentation/i386/IO-APIC.txt, Documentation/nmi_watchdog.txt and the SMP-FAQ on the WWW at http://www.irisa.fr/prive/mentre/smp-faq/ . If you don't know what to do here, say N. @@ -3471,7 +3471,7 @@ The module will be called parport.o. If you have more than one parallel port and want to specify which port and IRQ to be used by this driver at module load time, take a look at - Documentation/networking/parport.txt. + Documentation/parport.txt. If unsure, say Y. @@ -3614,7 +3614,7 @@ "Sysctl support" below, you can change various aspects of the behavior of the TCP/IP code by writing to the (virtual) files in /proc/sys/net/ipv4/*; the options are explained in the file - Documentation/Networking/ip-sysctl.txt. + Documentation/networking/ip-sysctl.txt. Short answer: say Y. @@ -4995,7 +4995,7 @@ CONFIG_BLK_CPQ_CISS_DA This is the driver for Compaq Smart Array controllers. Everyone using these boards should say Y here. - See "linux/Documentation/cciss.txt" for the current list of + See Documentation/cciss.txt for the current list of boards supported by this driver, and for further information on the use of this driver. @@ -13995,7 +13995,7 @@ SGI Visual Workstation on-board audio CONFIG_SOUND_VWSND Say Y or M if you have an SGI Visual Workstation and you want to - be able to use its on-board audio. Read Documentation/sound/visws + be able to use its on-board audio. Read Documentation/sound/vwsnd for more info on this driver's capabilities. Ensoniq Soundscape support - 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/
[patchlet] fix some typos and pathnames in Configure.help
Hello, this fixes some typos and pathnames in pointers from Configure.help to files in the Documentation subtree. Not much, but better than nothing. Matthias --- Documentation/Configure.help.orig Sat Nov 18 00:14:01 2000 +++ Documentation/Configure.helpFri Nov 17 23:35:47 2000 @@ -77,7 +77,7 @@ in some special cases. Detailed bug reports from people familiar with the kernel internals are usually welcomed by the developers (before submitting bug reports, please read the documents README, - MAINTAINERS, REPORTING_BUGS, Documentation/BUG-HUNTING, and + MAINTAINERS, REPORTING-BUGS, Documentation/BUG-HUNTING, and Documentation/oops-tracing.txt in the kernel source). This option will also make obsoleted drivers available. These are @@ -113,7 +113,7 @@ Management" code will be disabled if you say Y here. See also the files Documentation/smp.tex, Documentation/smp.txt, - Documentation/IO-APIC.txt, Documentation/nmi_watchdog.txt and the + Documentation/i386/IO-APIC.txt, Documentation/nmi_watchdog.txt and the SMP-FAQ on the WWW at http://www.irisa.fr/prive/mentre/smp-faq/ . If you don't know what to do here, say N. @@ -3471,7 +3471,7 @@ The module will be called parport.o. If you have more than one parallel port and want to specify which port and IRQ to be used by this driver at module load time, take a look at - Documentation/networking/parport.txt. + Documentation/parport.txt. If unsure, say Y. @@ -3614,7 +3614,7 @@ "Sysctl support" below, you can change various aspects of the behavior of the TCP/IP code by writing to the (virtual) files in /proc/sys/net/ipv4/*; the options are explained in the file - Documentation/Networking/ip-sysctl.txt. + Documentation/networking/ip-sysctl.txt. Short answer: say Y. @@ -4995,7 +4995,7 @@ CONFIG_BLK_CPQ_CISS_DA This is the driver for Compaq Smart Array controllers. Everyone using these boards should say Y here. - See "linux/Documentation/cciss.txt" for the current list of + See Documentation/cciss.txt for the current list of boards supported by this driver, and for further information on the use of this driver. @@ -13995,7 +13995,7 @@ SGI Visual Workstation on-board audio CONFIG_SOUND_VWSND Say Y or M if you have an SGI Visual Workstation and you want to - be able to use its on-board audio. Read Documentation/sound/visws + be able to use its on-board audio. Read Documentation/sound/vwsnd for more info on this driver's capabilities. Ensoniq Soundscape support - 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: isofs broken (2.2 and 2.4)
On Nov 17, Linus Torvalds wrote:
>
>
> On Fri, 17 Nov 2000, Harald Koenig wrote:
> >
> > this seems to make things much worse: starting with ~90M free memory
> > "du" again started leaking (or maybe just using memory?) down to ~80M free
> > memory when the system suddently locked up completely, no console switch
> > was possible anymore (but Sysrq-B did reboot).
>
> How about this version (full patch against test10 - it includes a
> slightly corrected version of my earlier dir.c patch)?
>
> It's entirely untested, but it looks good and compiles. Ship it!
it looks slightly better performacewise with cold cache when compared
with Andries' patch:
Linus: 0.380u 76.850s 1:19.12 97.6%0+0k 0+0io 113pf+0w
Andries:0.470u 97.220s 1:40.29 97.4%0+0k 0+0io 112pf+0w
BUT: there are some obvious bugs in the output of "du" and "find".
some samples (all file names (should) match the format "xe%03d/xe%03d.%c%c"
with both %03d being the _same_ number and both %c are in [a-z0-9]).
from "find" output:
...
/mnt/xe001/xe001.hg
find: /mnt/xe001/xe001.h: No such file or directory
/mnt/xe001/xe001.hi
...
/mnt/xe001/xe001.ib
find: /mnt/xe001/xe001.h: No such file or directory
/mnt/xe001/xe001.id
...
find: /mnt/xe003/xe002.rg: No such file or directory
...
find: /mnt/xe004/xe003.rg: No such file or directory
...
find: /mnt/xe005/xe004.rg: No such file or directory
"find" from hot cache even shows some binary garbage:
...
/mnt/xe001/xe001.0k
find: /mnt/xe001/¶^¶ ¶¶p¶$¶^¶¶^¶^¶ ¶¶¶{}: No such file
or directory
/mnt/xe001/xe001.0m
...
/mnt/xe001/xe001.gl
find: /mnt/xe001/xe105/xe105.p1
/mnt/xe105/xe105.p2
/mnt/xe105/x: No such file or directory
/mnt/xe001/xe001.gn
...
and from "du":
...
du: /mnt/xe001/xe001.k: No such file or directory
du: /mnt/xe001/xe001.k: No such file or directory
du: /mnt/xe001/xe001.k: No such file or directory
du: /mnt/xe001/xe001.m: No such file or directory
du: /mnt/xe001/xe001.m: No such file or directory
du: /mnt/xe001/xe001.m: No such file or directory
du: /mnt/xe001/xe001.o: No such file or directory
du: /mnt/xe001/xe001.o: No such file or directory
du: /mnt/xe001/xe001.o: No such file or directory
du: /mnt/xe001/xe001.p: No such file or directory
du: /mnt/xe001/xe001.p: No such file or directory
du: /mnt/xe001/xe001.p: No such file or directory
du: /mnt/xe001/xe001.r: No such file or directory
3378/mnt/xe001
du: /mnt/xe002/xe001.og: No such file or directory
du: /mnt/xe002/xe001.og: No such file or directory
du: /mnt/xe002/xe001.og: No such file or directory
4587/mnt/xe002
du: /mnt/xe003/xe002.rg: No such file or directory
du: /mnt/xe003/xe002.rg: No such file or directory
du: /mnt/xe003/xe002.rg: No such file or directory
3669/mnt/xe003
4451/mnt/xe004
du: /mnt/xe005/xe004.rg: No such file or directory
du: /mnt/xe005/xe004.rg: No such file or directory
du: /mnt/xe005/xe004.rg: No such file or directory
3728/mnt/xe005
...
du: /mnt/xe010/
# note: this file is far from being complete: No such file or directory
du: /mnt/xe010/
# note: this file is far from being complete: No such file or directory
du: /mnt/xe010/
# note: this file is far from being complete: No such file or directory
4263/mnt/xe010
Harald
--
All SCSI disks will from now on ___ _
be required to send an email notice0--,|/OOO\
24 hours prior to complete hardware failure! <_/ / /OOO\
\ \/OOO\
\ O|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
[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/
[PATCH] raid5 fix after xor.c cleanup
Hi Ingo & lists,
due to the xor.c cleanup in 2.4.0-test11-pre5+, raid5 compiled into the
kernel fails when booting, because the calibrate_xor_block function
hasn't been called while registering a raid5 volume; this leads to a
panic, as no checksumming function has been chosen.
Here's a tiny patch to restore that functionality, can you apply it?
Regards,
--
Jasper Spaans <[EMAIL PROTECTED]>
diff -Nru linux-2.4.0-test11-pre6-orig/drivers/md/raid5.c
linux-2.4.0-test11-pre6/drivers/md/raid5.c
--- linux-2.4.0-test11-pre6-orig/drivers/md/raid5.c Fri Nov 17 23:21:18 2000
+++ linux-2.4.0-test11-pre6/drivers/md/raid5.c Fri Nov 17 23:19:24 2000
@@ -2344,6 +2344,9 @@
int raid5_init (void)
{
+#ifndef MODULE
+ calibrate_xor_block();
+#endif
return register_md_personality (RAID5, _personality);
}
diff -Nru linux-2.4.0-test11-pre6-orig/drivers/md/xor.c
linux-2.4.0-test11-pre6/drivers/md/xor.c
--- linux-2.4.0-test11-pre6-orig/drivers/md/xor.c Fri Nov 17 23:21:18 2000
+++ linux-2.4.0-test11-pre6/drivers/md/xor.cFri Nov 17 23:31:36 2000
@@ -98,7 +98,7 @@
speed / 1000, speed % 1000);
}
-static int
+int
calibrate_xor_block(void)
{
void *b1, *b2;
@@ -139,5 +139,6 @@
}
MD_EXPORT_SYMBOL(xor_block);
+MD_EXPORT_SYMBOL(calibrate_xor_block);
module_init(calibrate_xor_block);
diff -Nru linux-2.4.0-test11-pre6-orig/include/linux/raid/xor.h
linux-2.4.0-test11-pre6/include/linux/raid/xor.h
--- linux-2.4.0-test11-pre6-orig/include/linux/raid/xor.h Fri Nov 17 23:21:48
2000
+++ linux-2.4.0-test11-pre6/include/linux/raid/xor.hFri Nov 17 23:33:03 2000
@@ -6,6 +6,7 @@
#define MAX_XOR_BLOCKS 5
extern void xor_block(unsigned int count, struct buffer_head **bh_ptr);
+extern int calibrate_xor_block(void);
struct xor_block_template {
struct xor_block_template *next;
-
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: sunhme.c patch for new PCI interface (UNTESTED)
"Adam J. Richter" wrote:
> Jeff Garzik writes:
> >Are you aware of any hotplug sunhme hardware? If no, don't change it to
> >__devinit...
>
> Can I have a hot plug PCI bridge card that connects to
> a regular PCI backplane (perhaps as some kind of CardBus docking
> station card)? If so, all PCI drivers should use __dev{init,exit}{,data}.
I am willing to consider adding __devxxx only when other __devxxx
entries already exist.
These conversions to _devxxx are too late in the freeze, and only have
value for isolated cases --which you admit you don't even know exist--.
Linus Rule 1: Don't overdesign. Even if such cases do exist, and this
is a need, it should be addressed some other way.
Your suggestion bloats drivers needlessly for the majority of cases and
I will not be applying any such patches...
Jeff
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft| -- Picasso
-
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: isofs broken (2.2 and 2.4)
On Nov 17, [EMAIL PROTECTED] wrote:
>
> > > + if (cpnt)
> > > + kfree(cpnt);
>
> > this seems to make things much worse
>
> Yes, I meant
>
> if (cpnt) {
> kfree(cpnt);
> cpnt = NULL;
> }
>
> at that place, otherwise things will be freed multiple times.
_MUCH_ better now!!! no lockups anymore, no memory leak(s).
BUT: there is still this small performace and memory usage issue:
each of these CDs contains >80k files in ~110 directories each
(the full db consists of 18 CDs!) and running "find" or "du"
on one CDROM (or 4MB isofs loop mount from hard disk) takes
a huge amount of time (real and system cpu) with cold cache:
time find /cdrom
0.610u 97.250s 1:40.58 97.2%0+0k 0+0io 98pf+0w
flush cache...
time du /cdrom
0.470u 97.220s 1:40.29 97.4%0+0k 0+0io 112pf+0w
whereas with hot cache (takes ~45MB memory off the value
for "free + buffer/cache" for a 4MB isofs image!) gives (PPro200, 128MB):
time find /cdrom
0.460u 1.280s 0:01.79 97.2% 0+0k 0+0io 102pf+0w
time du /cdrom
0.270u 1.260s 0:01.54 99.3% 0+0k 0+0io 108pf+0w
so it seems to work (data still not checked, can do this only next week)
but performace really sucks :(
anyway, thanks a lot for your help and quick patch !
now at least we can copy all the data to some hard disk
and use it that way.
a patch for 2.2.x (the real production machine can't run 2.4.x yet)
and/or fixes for the bad performace would be appreciated anyway ;^)
thanks!
Harald
--
All SCSI disks will from now on ___ _
be required to send an email notice0--,|/OOO\
24 hours prior to complete hardware failure! <_/ / /OOO\
\ \/OOO\
\ O|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
[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: [CFT] dmfe.c network driver update for 2.4
> --On Friday, November 17, 2000 10:20 AM +0100 Tobias Ringstrom > > How about adding an ifdef CONFIG_SMP then print ugly warning to all known > > SMP unsafe drivers? A message could be printed booth at compile and load > > time. Frank Davis wrote: > I would rather fix those non-SMP compliant drivers to be SMP compliant, > then keeping them 'broken'. Adding the print statements would only be a > temporary solution. Agreed. If people have SMP safety patches for net drivers, let me know... Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - 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: isofs broken (2.2 and 2.4)
On Fri, 17 Nov 2000, Harald Koenig wrote:
>
> this seems to make things much worse: starting with ~90M free memory
> "du" again started leaking (or maybe just using memory?) down to ~80M free
> memory when the system suddently locked up completely, no console switch
> was possible anymore (but Sysrq-B did reboot).
How about this version (full patch against test10 - it includes a
slightly corrected version of my earlier dir.c patch)?
It's entirely untested, but it looks good and compiles. Ship it!
Linus
-
diff -u --recursive --new-file v2.4.0-test10/linux/fs/isofs/dir.c linux/fs/isofs/dir.c
--- v2.4.0-test10/linux/fs/isofs/dir.c Fri Aug 11 14:29:01 2000
+++ linux/fs/isofs/dir.cFri Nov 17 13:38:01 2000
@@ -94,6 +94,14 @@
return retnamlen;
}
+static struct buffer_head *isofs_bread(struct inode *inode, unsigned int bufsize,
+unsigned int block)
+{
+ unsigned int blknr = isofs_bmap(inode, block);
+ if (!blknr)
+ return NULL;
+ return bread(inode->i_dev, blknr, bufsize);
+}
+
/*
* This should _really_ be cleaned up some day..
*/
@@ -105,7 +113,7 @@
unsigned char bufbits = ISOFS_BUFFER_BITS(inode);
unsigned int block, offset;
int inode_number = 0; /* Quiet GCC */
- struct buffer_head *bh;
+ struct buffer_head *bh = NULL;
int len;
int map;
int high_sierra;
@@ -117,46 +125,25 @@
return 0;
offset = filp->f_pos & (bufsize - 1);
- block = isofs_bmap(inode, filp->f_pos >> bufbits);
+ block = filp->f_pos >> bufbits;
high_sierra = inode->i_sb->u.isofs_sb.s_high_sierra;
- if (!block)
- return 0;
-
- if (!(bh = breada(inode->i_dev, block, bufsize, filp->f_pos, inode->i_size)))
- return 0;
-
while (filp->f_pos < inode->i_size) {
int de_len;
-#ifdef DEBUG
- printk("Block, offset, f_pos: %x %x %x\n",
- block, offset, filp->f_pos);
- printk("inode->i_size = %x\n",inode->i_size);
-#endif
- /* Next directory_record on next CDROM sector */
- if (offset >= bufsize) {
-#ifdef DEBUG
- printk("offset >= bufsize\n");
-#endif
- brelse(bh);
- offset = 0;
- block = isofs_bmap(inode, (filp->f_pos) >> bufbits);
- if (!block)
- return 0;
- bh = breada(inode->i_dev, block, bufsize, filp->f_pos,
inode->i_size);
+
+ if (!bh) {
+ bh = isofs_bread(inode, bufsize, block);
if (!bh)
return 0;
- continue;
}
de = (struct iso_directory_record *) (bh->b_data + offset);
- if(first_de) inode_number = (block << bufbits) + (offset & (bufsize -
1));
+ if (first_de) inode_number = (bh->b_blocknr << bufbits) + offset;
de_len = *(unsigned char *) de;
#ifdef DEBUG
printk("de_len = %d\n", de_len);
-#endif
-
+#endif
/* If the length byte is zero, we should move on to the next
CDROM sector. If we are at the end of the directory, we
@@ -164,36 +151,33 @@
if (de_len == 0) {
brelse(bh);
- filp->f_pos = ((filp->f_pos & ~(ISOFS_BLOCK_SIZE - 1))
- + ISOFS_BLOCK_SIZE);
+ bh = NULL;
+ filp->f_pos = ((filp->f_pos & ~(ISOFS_BLOCK_SIZE - 1)) +
+ISOFS_BLOCK_SIZE);
+ block = filp->f_pos >> bufbits;
offset = 0;
-
- if (filp->f_pos >= inode->i_size)
- return 0;
-
- block = isofs_bmap(inode, (filp->f_pos) >> bufbits);
- if (!block)
- return 0;
- bh = breada(inode->i_dev, block, bufsize, filp->f_pos,
inode->i_size);
- if (!bh)
- return 0;
continue;
}
- offset += de_len;
- if (offset > bufsize) {
- /*
-* This would only normally happen if we had
-* a buggy cdrom image. All directory
-* entries should terminate with a null size
-* or end exactly at the end of the sector.
-*/
- printk("next_offset (%x) > bufsize (%lx)\n",
- offset,bufsize);
- break;
+ offset += de_len;
+
+ /* Make sure we have a full directory entry */
+
Re: [CFT] dmfe.c network driver update for 2.4
I would rather fix those non-SMP compliant drivers to be SMP compliant, then keeping them 'broken'. Adding the print statements would only be a temporary solution. Regards, Frank --On Friday, November 17, 2000 10:20 AM +0100 Tobias Ringstrom > How about adding an ifdef CONFIG_SMP then print ugly warning to all known > SMP unsafe drivers? A message could be printed booth at compile and load > time. > > /Tobias > - 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: sunhme.c patch for new PCI interface (UNTESTED)
Jeff Garzik writes:
>Are you aware of any hotplug sunhme hardware? If no, don't change it to
>__devinit...
Can I have a hot plug PCI bridge card that connects to
a regular PCI backplane (perhaps as some kind of CardBus docking
station card)? If so, all PCI drivers should use __dev{init,exit}{,data}.
The other excellent points that you raise apply equally to
the driver before and after my patch (although my patch made it
more clear that the struct netdevice parameters previously being
passed around were always null). It is important to realize this
becase, as of yesterday, Dave had said that he was not going to
apply the new style PCI changes at this point, but had integrated
the MODULE_DEVICE_TABLE changes. So, Dave: you should look at
the points that Jeff raised, even if you are not integrating
the rest of my new style PCI patch.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
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: Advanced Linux Kernel/Enterprise Linux Kernel
Michael Rothwell wrote: > 4) A high reliability internal file system. > > Ext2 + bdflush + kupdated? Not likely. To quote the Be Filesystems > book, Ext2 throws safety to the wind to achieve speed. This also ties > into Linux' convoluted VM system, and is shot in the foot by NFS. We > would need minimally a journaled filesystem and a clean VM design, > probably with a unified cache (no separate buffer, directory entry and > page caches). The Tux2 Phase Trees look to be a good step in the > direction as well, in terms of FS reliability. The filesystem would have > to do checksums on every block. Actually, I was planning on doing on putting in a hack to do something like that: calculate a checksum after every buffer data update and check it after write completion, to make sure nothing scribbled in the buffer in the interim. This would also pick up some bad memory problems. > Some type of mirroring/clustering would > be good. And the ability to grow filesystems online, and replace disks > online, would be key. If your disks are getting old, you may want to > pre-emptively replace them with faster, newer, larger ones with more > MTBF left. This is all coming, but as you say, it's not quite here yet. -- Daniel - 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: VGA PCI IO port reservations
Followup to: <[EMAIL PROTECTED]> By author:Matthew Kirkwood <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > On Fri, 17 Nov 2000, Russell King wrote: > > > Therefore, it should be reserved independent of whether we have the > > driver loaded/in kernel or not. > > Is this not an argument for a more flexible resource allocation > API? One offering both: > >res = allocate_resource(restype, dev, RES_ALLOC_UNUSED, region); > > and > >res = allocate_resource(restype, dev_ RES_ALLOC_HW, region); > One way to do this is to treat PCI IO and ISA IO as two separate address spaces. The PCI IO address space is a 14-bit address space (bits 9:8 are always zero) ranging from 0x1000 to 0xFCFF. ISA IO is a 10-bit space (bits 15:10 are available for the card to use) ranging from 0x100 to 0x3FF. VGA cards may be PCI and AGP, but still have allocations in the ISA range. -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: [PATCH] CONFIG_EISA note in Documentation/Configure.help
On Wed, Nov 15, 2000 at 06:16:00AM -0500, Paul Gortmaker wrote:
> > What use is knowing that a machine has EISA slots? As far as I can see
> > the only use is to ask for the EISA ID of the card.
> > Should we? I collected 1200 .cfg files and estimate that this is
> > less than 10% of what exists - we do not want a data base built
> > into the kernel, I think. But the kernel could collect these
> > EISA IDs at boot time, enabling drivers to inquire.
>
> There could have been an API for EISA card probes if there
> were enough drivers to demand it - but I guess there never was.
> Something like:
>
> if (ioaddr=probe_EISA_ID("abc1234") == 0) return -ENODEV;
I see how to make
if ((slot = probe_EISA_ID("abc1234")) == -1) return -ENODEV;
but have no idea how you want to find an ioaddr.
My code does something like
/*
* EISA board N has a 4-byte ID that can be read from 0xNc80-0xNc83
* return 0 for success, -1 for failure (no EISA card in slot) and
* 1 when a card is present but still needs to be configured.
*/
static int
get_eisa_id(int board, char *id) {
int idaddr = (board << 12) + 0x0c80;
char val;
outb(0xff, idaddr);
val = inb(idaddr);
if (val & 0x80)
return -1;
if ((val & 0xf0) == 0x70)
return 1;
id[0] = val;
id[1] = inb(idaddr+1);
id[2] = inb(idaddr+2);
id[3] = inb(idaddr+3);
return 0;
}
(I looked at this in order to get information in a situation
with several onboard chips. The EISA slot for them is 0,
but there is no obvious way to get at the ioaddr.)
> > (iv) Finally a question: does anyone know of a URL for the
> > EISA standard?
>
> I recall looking about several years ago when I was playing
> with some drivers for old EISA ethernet cards. Never found
> much of anything. A couple of html-docs on a Digital EISA
> box which I found collecting dust in my personal archive of
> junk. (see below)
Thanks! However, I had these same docs.
(Labeled AA-Q0R6C-TET1.)
> > [PS I would like to be mistaken about the impossibility of
> > parsing the EISA configuration area. There is useful info
> > there, e.g. about dma and irq. It would be nice if this info
> > were available.]
>
> I think you are mistaken - I have written several EISA drivers
> for network cards, and at least three of these I wrote having
> never seen the card at all - only the .cfg file - which was
> enough for me to get the card I/O IRQ and so on.
Yes, the file is fine. But I only gave you the EISA configuration area.
Now what do you do? I don't know. As far as I can see only very
machine-dependent things work.
Andries
-
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: VGA PCI IO port reservations
On Fri, 17 Nov 2000, Russell King wrote: > Therefore, it should be reserved independent of whether we have the > driver loaded/in kernel or not. Is this not an argument for a more flexible resource allocation API? One offering both: res = allocate_resource(restype, dev, RES_ALLOC_UNUSED, region); and res = allocate_resource(restype, dev_ RES_ALLOC_HW, region); ? Maybe the kernel might ask: allocate_resource(restype, dev, RES_ALLOC_UNMOVABLE_HW, region); Matthew. - 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: sunhme.c patch for new PCI interface (UNTESTED)
"Adam J. Richter" wrote:
> -static struct happy_meal *root_happy_dev = NULL;
> -
> #ifdef CONFIG_SBUS
> +static struct happy_meal *root_happy_dev = NULL;
> static struct quattro *qfe_sbus_list = NULL;
> #endif
don't initialize static to zero/null explicitly..
> - if (dev == NULL) {
> - dev = init_etherdev(0, sizeof(struct happy_meal));
> - } else {
> - dev->priv = kmalloc(sizeof(struct happy_meal), GFP_KERNEL);
> - if (dev->priv == NULL)
> - return -ENOMEM;
> - }
> + dev = init_etherdev(0, sizeof(struct happy_meal));
allocation failure not checked
> -static int __init happy_meal_pci_init(struct net_device *dev, struct pci_dev *pdev)
> +static int __devinit happy_meal_pci_probe(struct pci_dev *pdev,
> + const struct pci_device_id *id)
Are you aware of any hotplug sunhme hardware? If no, don't change it to
__devinit...
> - if (dev == NULL) {
> - dev = init_etherdev(0, sizeof(struct happy_meal));
> - } else {
> - dev->priv = kmalloc(sizeof(struct happy_meal), GFP_KERNEL);
> - if (dev->priv == NULL)
> - return -ENOMEM;
> - }
> + dev = init_etherdev(0, sizeof(struct happy_meal));
check for failure.
also, ether_setup() call is not needed if you always call
init_etherdev(NULL, ...).
> +static void __devexit happy_meal_pci_remove (struct pci_dev *pdev)
> +{
> + struct happy_meal *hp = pdev->driver_data;
> +
> + pci_free_consistent(hp->happy_dev,
> + PAGE_SIZE,
> + hp->happy_block,
> + hp->hblock_dvma);
> + unregister_netdev(hp->dev);
> + kfree(hp->dev);
> +}
zero pdev->driver_data. If this driver has to be portable, use
pci_{get,set}_drvdata() instead of directly accessing ::driver_data.
> +static struct pci_device_id happymeal_pci_ids[] __devinitdata = {
again, no __devxxx if not hotplug.
> #ifdef CONFIG_PCI
> - cards += happy_meal_pci_probe(dev);
> + return pci_module_init(_meal_pci_driver);
> +#else
> + return (cards > 0) ? 0 : -ENODEV;
> #endif
ifdef not needed
> +#ifdef CONFIG_PCI
> + pci_unregister_driver (_meal_pci_driver);
> +#endif
ifdef not needed.
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft| -- Picasso
-
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: VGA PCI IO port reservations
[EMAIL PROTECTED] ("Richard B. Johnson") writes:
[about PCI setup code]
> This stuff has to be set up before you
> have any resources necessary to execute the output of a 'C' compiler,
> so, if you are looking for 'C' syntax, you are out of luck.
Sorry, but that's plain rubbish.
Some things in bootcode usually have to be done in assembly, but
PCI setup is definitely *not* among them, unless you have some
really unique hardware. Hell, I've even written bootcode where
the memory-controller is set up from C.
//Marcus
--
---+---
Marcus Sundberg| Phone: +46 707 452062
Embedded Systems Consultant | Email: [EMAIL PROTECTED]
Cendio Systems AB | http://www.cendio.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: BUG: isofs broken (2.2 and 2.4)
On Nov 17, [EMAIL PROTECTED] wrote: > > memory leak > > Aha. Must be a missing kfree(). > Does this help? > > --- namei.c~Fri Nov 17 00:48:37 2000 > +++ namei.c Fri Nov 17 21:59:49 2000 > @@ -197,6 +197,8 @@ > bh = NULL; > break; > } > + if (cpnt) > + kfree(cpnt); > } > if (page) > free_page((unsigned long) page); > > Andries this seems to make things much worse: starting with ~90M free memory "du" again started leaking (or maybe just using memory?) down to ~80M free memory when the system suddently locked up completely, no console switch was possible anymore (but Sysrq-B did reboot). Harald -- All SCSI disks will from now on ___ _ be required to send an email notice0--,|/OOO\ 24 hours prior to complete hardware failure! <_/ / /OOO\ \ \/OOO\ \ O|// Harald Koenig, \/\/\/\/\/\/\/\/\/ Inst.f.Theoret.Astrophysik // / \\ \ [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: BUG: isofs broken (2.2 and 2.4)
> memory leak Aha. Must be a missing kfree(). Does this help? --- namei.c~Fri Nov 17 00:48:37 2000 +++ namei.c Fri Nov 17 21:59:49 2000 @@ -197,6 +197,8 @@ bh = NULL; break; } + if (cpnt) + kfree(cpnt); } if (page) free_page((unsigned long) page); Andries - 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: duplicate entries in rtl8129 driver
"Adam J. Richter" wrote: > > Both linux-2.4.0-test12-pre6/drivers/net/rtl8129.c and > Don Becker's version at ftp.sycld.com appear to have identical > PCI device ID and vendor ID values for these two cards: rtl8129 is going away as soon as humanly possible. :) RealTek sent me a RTL8130 so I can test the MII stuff finally. Note that those duplicate ids should be commented out of rtl8129.c, also. -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - 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's internal PCMCIA works for me (was Re: [PATCH] pcmcia event thread)
On Fri, Nov 17, 2000 at 12:30:38PM -0800, Barry K. Nathan wrote: > > I do understand that the in-kernel support isn't as mature as the external > support yet. However, it isn't universally broken and useless either. That's certainly true; it should work fine for the large majority of configurations. I think the non-platform-specific issues are mostly resolved. -- Dave - 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: duplicate entries in rtl8129 driver
On Fri, 17 Nov 2000, Adam J. Richter wrote: > Both linux-2.4.0-test12-pre6/drivers/net/rtl8129.c and > Don Becker's version at ftp.sycld.com appear to have identical > PCI device ID and vendor ID values for these two cards: > > SMC1211TX EZCard 10/100 (RealTek RTL8139) > Accton MPX5030 (RealTek RTL8139) > > So, I do not see how the latter entry in pci_tbl is ever > matched. I think the result would be that users of either card > will be told that they have an SMC1211TX EZCard 10/100. I suggest > deleting the latter entry and combine its label into the previous > one, so it will be described as: > > SMC1211TX EZCard 10/100 or Accton MPX5030 (RealTek RTL8139) They are distinguished by the PCI subsystem ID, which was truncated from the list. Note that Accton is really SMC. They purchased part of SMC several years ago, including the brand name. The chip part of the old SMC is now named SMsC, and they still make the EPIC Ethernet chip. I do have a long list of subsystem IDs, but using multiple names for a one-chip board with no design options is just confusing. (Vs. the 21143 chip, which has at least 70 different driver-visible board design variations.) Bottom line: Yes, it's redundant. But there was a reason. Donald Becker [EMAIL PROTECTED] Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 - 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 entries in rtl8129 driver
Both linux-2.4.0-test12-pre6/drivers/net/rtl8129.c and Don Becker's version at ftp.sycld.com appear to have identical PCI device ID and vendor ID values for these two cards: SMC1211TX EZCard 10/100 (RealTek RTL8139) Accton MPX5030 (RealTek RTL8139) So, I do not see how the latter entry in pci_tbl is ever matched. I think the result would be that users of either card will be told that they have an SMC1211TX EZCard 10/100. I suggest deleting the latter entry and combine its label into the previous one, so it will be described as: SMC1211TX EZCard 10/100 or Accton MPX5030 (RealTek RTL8139) Comments? Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - 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.2.17 poor performace with many processes
-BEGIN PGP SIGNED MESSAGE- Last night I attempted to install a firewall system that runs over a thousand processes (useing the TIS FWTK proxies). I upped the NR_TASKS to 4090 to allow them all to run. the way the particular proxies work is to have a listener for each port that forks off a copy of itself to handle the connection. one issue that I was seeing however is that under a light load (~30-50 simultanious connections, ~20-30 new connections/sec) vmstat was showing ~10% user, 40%system CPU utilization. at teh time it was useing ~80MB of ram. each proxy logs to syslog, while I had syslog configured to write to a local file system time went up by ~10%. configuring syslog to write out a serial port makes it so running syslog or not makes no noticable difference in the sup utilization unfortunantly the system is no longer in production, approx 2 hours after I went home this morning it hit the max FD limit (I had bumped it up to 16K) at ~100 connections/sec and we had to pull it out as nobody was available to do diagnostics. hardware is AMD thunderbird 950MHz, 512MB PC133 ram, 7200rpm ATA/66 drive is this something that 2.4 should improve? or are there other tuning paramaters I need to fiddle with? David Lang -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQEVAwUBOhWd3z7msCGEppcbAQGsQwf6A2AAnSDwtUlftuaHuIaLleu6VKEDVwwI X2cWQfavGQFebLC01KzL9tTyEJwLHaKAhNsoKvOy7FwPFIVaOPafXlSR33tJokAD VC/899S39MTuD1huNP7sdjVfdovqmz7KaIXxqasymiUFlB7woFsxHhfjV0T6VKi4 jkJRJCPJ7yilli2DqOllES6MBC+tMqfiZ9mnMmaiRKcbZSHEMLI/eFM06kgjzBTI EDT0XNgj575Xa0SUC9JmOS9csxwTodfXCnfiqHwgqEAt/qGyfEZUgI1xID6HHTqH QfNt4mejDGhsJ3uFd6sYxN/Z/DrtoQLeYU8uYB/yfH7XZA31SGJYVQ== =qrrI -END PGP SIGNATURE- - 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] vgacon
On Fri, 17 Nov 2000 [EMAIL PROTECTED] wrote: > > Hi James, > > here is a patch for vgacon.c could you please check it? Okay. Thank for for posting it not as a attachment. > 1) removes explicit 0 initialisation of statics Those are fine. I already have in the ruby tree for the linux console project. > 2) removes an apparently unnecesary line in vgacon_scroll: > as I see it scr_end is computed anyway after the if statement so > no need to put it on the else branch. Hum. Never noticed that one. I will try this part out just to make sure their is no 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: BUG: isofs broken (2.2 and 2.4)
On Nov 17, [EMAIL PROTECTED] wrote: > > both 2.2.x and 2.4.x kernels can't read `real sky' CDs > > Yes. 2.0.38 is OK. I just made a patch that seems to work. > > Harald, could you try > ftp.xx.kernel.org/.../people/aeb/linux-2.4.0test9-isofs-patch > and report? works -- sort of:( I've tried both test9 and test10 with your patch on a PPro200 with 128MB ram and I get the same effects both times: directory listing seems to be possible (haven't checked data contents yet) BUT if I try "du /cdrom/" (either using real cdrom device or loopback mount of my sample isofs image) there seems to be a huge memory leak ! first observation is that "du" is awfuly slow -- it takes ~90 secs real time and ~60 system cpu secs to "du" through the first ~70 of 106 direcories, then the 128MB memory are almost used up and the systems starts to swap heavily. this meory doesn't get freed up even after umount/losetup -d or whatever -- only reboot "helps"... I'll attach log files showing output of "free", /proc/meminfo and output of ALT-SYSREQ-M plus full "ps" output for both -test9 and -test10 with your patch in the situation when almost all memory is "gone" (du already killed). hope this helps... Harald -- All SCSI disks will from now on ___ _ be required to send an email notice0--,|/OOO\ 24 hours prior to complete hardware failure! <_/ / /OOO\ \ \/OOO\ \ O|// Harald Koenig, \/\/\/\/\/\/\/\/\/ Inst.f.Theoret.Astrophysik // / \\ \ [EMAIL PROTECTED] ^ ^ log-test9.gz log-test10.gz
2.4's internal PCMCIA works for me (was Re: [PATCH] pcmcia event thread)
Linus Torvalds wrote: > Right now, I suspect that the in-kernel pcmcia code is actually at the > point where it _is_ possible to use it. David Hinds has been keeping the > cs layer in synch with the external versions, and tons of people have > helped make the low-level drivers stable again. > > If somebody still has a problem with the in-kernel stuff, speak up. I'm going to speak up as someone who uses the in-kernel code without problems (on my Dell Inspiron 5000e and Dell/3Com CardBus 10/100 NIC). The in-kernel support always seems to get a bad rap, so I want to mention that, for some people anyway, the in-kernel code works just as well as the external code. I do understand that the in-kernel support isn't as mature as the external support yet. However, it isn't universally broken and useless either. -Barry K. Nathan <[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: VGA PCI IO port reservations
On 17 Nov 2000, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Russell King <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Richard B. Johnson writes: > > > The code necessary to find the lowest unaliased address looks like > > > this: > > > > Any chance of providing something more readable? I may be able to read > > some x86 asm, but I don't have the time to try to decode that lot. > > > > Ignore this code. It's bullshit -- you can't just go and poke random > boards -- even with IN's -- indiscriminately. As usual, Richard is > writing long lectures on subjects he is seriously mistaken about (and > probably will send me yet another email trying to browbeat me into not > calling him on all his errors.) It's not bullshit, and as usual, you will never learn. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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] vgacon
> I've checked that and it works both on 2.2 and 2.4 but another test won't > hurt :-) No problems here :-) - 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: VGA PCI IO port reservations
On Fri, 17 Nov 2000, Russell King wrote: > Richard B. Johnson writes: > > It's Intel assembly on Intel machines. It's a hell of a lot more > > readable than AT assembly. This stuff has to be set up before you > > have any resources necessary to execute the output of a 'C' compiler, > > so, if you are looking for 'C' syntax, you are out of luck. > > Hello Dick! > > Come in! > > I don't care about what style of assembly it is. Believe it or not, > this may come as a dramatic revelation to you, but not every single > person on this planet knows X86 assembler of any form. > > I am one of the lucky people who doesn't have his brain crambed full > of the intracies of such a language. Instead I have my brain full of > ARM assembler instead, which is a hell of a lot more readable than > X86 assembler. > > Therefore, you quoting bits of X86 assembler to me is meaningless. > > -EAGAIN (try again) Okay. I'll bite (byte). The last port available is 0x. It's an odd number, so start at 0xfffe because all the PCI port bases start at even numbers (actually long words). Then, you read the port as a WORD (16 bits). If nothing responds, you get the value of 0x. If somebody is responding, you will read something if it's enabled for writes by devices (reads by the CPU). You keep decrementing the port number by 2 until either somebody responds or you get to 0x1000. The lowest port number, without anybody reponding is the first port you can allocate. However, the allocation has to be a correct PCI allocation, i.e., if somebody wants 16 bytes, you must allocate on a 16-byte boundary, potentially wasting 15 bytes of address space. The first aliased addresses will usually start to appear below 0x8000. This typically gives you almost 32k of I/O space to allocate. Since PCI devices can come alive in just about any state, before you actually do the snoop, your code should disable I/O for all PCI devices found except the first bridge. You do this by reading the second longword for each device, anding off the lowest 3 bits, then writing it back. (Command/Status register). The low word is the command register. The high word is the status register. Since any bits set in the status register, will be written back (this is how the bits get reset), you automatically reset any errors the device may have accumulated upon startup. If you have a PCI to ISA bridge (like PIIX4) , you have to enable it even though ISA bridge decodes are full 32-bit decodes. This is because the board itself will not do a 32-bit decode and can result in aliases. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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] Inconsistent behaviour of rmdir
On Fri, 17 Nov 2000, Guest section DW wrote: > I see that an entire discussion has taken place. Let me just remark this, > quoting the Austin draft: > > If the path argument refers to a path whose final component is either > dot or dot-dot, rmdir( ) shall fail. > > EINVALThe path argument contains a last component that is dot. [snip] > So, it seems that -EINVAL would be a better return value in case LAST_DOT. No problems with that... Linus, could you apply the following (cut-and-paste alert)? --- fs/namei.c Fri Nov 17 18:43:20 2000 +++ fs/namei.c.new Fri Nov 17 18:48:00 2000 @@ -1381,8 +1381,11 @@ case LAST_DOTDOT: error = -ENOTEMPTY; goto exit1; - case LAST_ROOT: case LAST_DOT: + case LAST_ROOT: error = -EBUSY; + goto exit1; + case LAST_DOT: + error = -EINVAL; goto exit1; } down(>d_inode->i_sem); - 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: BTTV detection broken in 2.4.0-test11-pre5
Werner Almesberger wrote: > The BTTV driver 0.7.48 doesn't detect my old Hauppauge card anymore. Yes. I've taken out the detection heuristics for bt848 cards. The code is very old, from the days where only 2-3 different bt848 cards where available. It simply did'nt work correctly and often used to misdetect random bt848 cards as either MIRO or Hauppauge (which where the first available cards). > The problem seems to be that my card sets PCI_SUBSYSTEM_ID and > PCI_SUBSYSTEM_VENDOR_ID to zero (lspci output below). Only bt878 chips have a subsystem ID. The bt848 has not. That's why there is simply no _reliable_ way to detect bt848 based cards. Gerd -- Wirtschaftsinformatiker == Leute, die zwar die aktuellen Aktienkurse jedes Softwareherstellers kennen, aber keines der Produkte auch nur ansatzweise bedienen können.-- Benedict Mangelsdorff - 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] vgacon
> > 2) removes an apparently unnecesary line in vgacon_scroll: > > as I see it scr_end is computed anyway after the if statement so > > no need to put it on the else branch. > > Hum. Never noticed that one. I will try this part out just to make sure > their is no problem. > I've checked that and it works both on 2.2 and 2.4 but another test won't hurt :-) Jani. - 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: VGA PCI IO port reservations
Followup to: <[EMAIL PROTECTED]> By author:Russell King <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Richard B. Johnson writes: > > The code necessary to find the lowest unaliased address looks like > > this: > > Any chance of providing something more readable? I may be able to read > some x86 asm, but I don't have the time to try to decode that lot. > Ignore this code. It's bullshit -- you can't just go and poke random boards -- even with IN's -- indiscriminately. As usual, Richard is writing long lectures on subjects he is seriously mistaken about (and probably will send me yet another email trying to browbeat me into not calling him on all his errors.) The standard algorithm, documented in many places, is the one I gave before: (port >= 0x1000 && (port & 0x0300) == 0) Allocating ports in any other ranges is unsafe. -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: who's maintaning vgacon.c ?
> or in any way responsible for it? > James Simmons maybe ? I do some console work but mostly for 2.5.X. Their is no offical maintainer for this sub system as of now. - 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] vgacon
Hi James,
here is a patch for vgacon.c could you please check it?
1) removes explicit 0 initialisation of statics
2) removes an apparently unnecesary line in vgacon_scroll:
as I see it scr_end is computed anyway after the if statement so
no need to put it on the else branch.
Jani.
--- /usr/src/linux-2.4.0/drivers/video/vgacon.c Thu Nov 16 20:04:52 2000
+++ vgacon.cFri Nov 17 10:42:29 2000
@@ -104,7 +104,7 @@
static u16 vga_video_port_val; /* Video register value port */
static unsigned intvga_video_num_columns; /* Number of text columns */
static unsigned intvga_video_num_lines;/* Number of text lines */
-static intvga_can_do_color = 0;/* Do we support colors? */
+static intvga_can_do_color;/* Do we support colors? */
static unsigned intvga_default_font_height;/* Height of default screen
font */
static unsigned char vga_video_type; /* Card type */
static unsigned char vga_hardscroll_enabled;
@@ -112,7 +112,7 @@
/*
* SoftSDV doesn't have hardware assist VGA scrolling
*/
-static unsigned char vga_hardscroll_user_enable = 0;
+static unsigned char vga_hardscroll_user_enable;
#else
static unsigned char vga_hardscroll_user_enable = 1;
#endif
@@ -122,7 +122,7 @@
static intvga_is_gfx;
static intvga_512_chars;
static intvga_video_font_height;
-static unsigned intvga_rolled_over = 0;
+static unsigned intvga_rolled_over;
static int __init no_scroll(char *str)
@@ -965,7 +965,7 @@
static void vgacon_save_screen(struct vc_data *c)
{
- static int vga_bootup_console = 0;
+ static int vga_bootup_console;
if (!vga_bootup_console) {
/* This is a gross hack, but here is the only place we can
@@ -1015,7 +1015,6 @@
vga_rolled_over = 0;
} else
c->vc_origin -= delta;
- c->vc_scr_end = c->vc_origin + c->vc_screenbuf_size;
scr_memsetw((u16 *)(c->vc_origin), c->vc_video_erase_char, delta);
}
c->vc_scr_end = c->vc_origin + c->vc_screenbuf_size;
-
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: test11-pre6 still very broken
Followup to: <[EMAIL PROTECTED]> By author:Tigran Aivazian <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Hi, > > The mysterious lockups in test11-pre5 continue in test11-pre6. It is very > difficult because the lockups appear to be kdb-specific (and kdb itself > goes mad) but when there is no kdb there is very little useful information > one can extract from a dead system... > > I will start removing kernel subsystems, one by one and try to reproduce > it on as plain kernel as possible (i.e. just io, no networking etc.) > > So, this not-very-useful report just says -- test11-pre6 is extremely > unstable, a simple "ltrace ls" can cause a lockup. Also, some programs > work when run normally but coredump (or hang) when run via strace, but > only sometimes, not always... (no, I don't have faulty memory, I run > memtest!) > It could be that -test5 and -test6 break some assumption kdb makes. It has been eminently stable here. -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: VGA PCI IO port reservations
Richard B. Johnson writes: > It's Intel assembly on Intel machines. It's a hell of a lot more > readable than AT assembly. This stuff has to be set up before you > have any resources necessary to execute the output of a 'C' compiler, > so, if you are looking for 'C' syntax, you are out of luck. Hello Dick! Come in! I don't care about what style of assembly it is. Believe it or not, this may come as a dramatic revelation to you, but not every single person on this planet knows X86 assembler of any form. I am one of the lucky people who doesn't have his brain crambed full of the intracies of such a language. Instead I have my brain full of ARM assembler instead, which is a hell of a lot more readable than X86 assembler. Therefore, you quoting bits of X86 assembler to me is meaningless. -EAGAIN (try again) _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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] pcmcia event thread. (fwd)
> 2. Even when I specify cs_irq=27, it resorts to polling: > > Intel PCIC probe: > Intel i82365sl DF ISA-to-PCMCIA at port 0x8400 ofs 0x00, 2 sockets > host opts [0]: none > host opts [1]: none > ISA irqs (default) = none! polling interval = 1000 ms The driver means it when it says "ISA irqs". A value of 27 is not valid for cs_irq because this is an ISA irq number and must be 0..15; this is not a property of the host system, this is a property of the i82365 register specification. PCI interrupts have to be handled differently (well, the stripped-down i82365 driver just can't handle them at all) -- Dave - 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: VGA PCI IO port reservations
On Fri, 17 Nov 2000, Russell King wrote: > Richard B. Johnson writes: > > The code necessary to find the lowest unaliased address looks like > > this: > > Any chance of providing something more readable? I may be able to read > some x86 asm, but I don't have the time to try to decode that lot. It's Intel assembly on Intel machines. It's a hell of a lot more readable than AT assembly. This stuff has to be set up before you have any resources necessary to execute the output of a 'C' compiler, so, if you are looking for 'C' syntax, you are out of luck. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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/
test11-pre6 still very broken
Hi, The mysterious lockups in test11-pre5 continue in test11-pre6. It is very difficult because the lockups appear to be kdb-specific (and kdb itself goes mad) but when there is no kdb there is very little useful information one can extract from a dead system... I will start removing kernel subsystems, one by one and try to reproduce it on as plain kernel as possible (i.e. just io, no networking etc.) So, this not-very-useful report just says -- test11-pre6 is extremely unstable, a simple "ltrace ls" can cause a lockup. Also, some programs work when run normally but coredump (or hang) when run via strace, but only sometimes, not always... (no, I don't have faulty memory, I run memtest!) Regards, Tigran - 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: VGA PCI IO port reservations
Richard B. Johnson writes: > The code necessary to find the lowest unaliased address looks like > this: Any chance of providing something more readable? I may be able to read some x86 asm, but I don't have the time to try to decode that lot. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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 with no HOTPLUG set.
On Fri, 17 Nov 2000, Cezary Kaliszyk wrote: > When I try to compile 2.4.0test11pre6 without HOTPLUG make says: > > gcc -D__KERNEL__ -I/usr/src/linux-2.4/include -Wall -Wstrict-prototypes > -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe > -mpreferred-stack-boundary=2 -march=i686-c -o dev.o dev.c > dev.c: In function `run_sbin_hotplug': > dev.c:2736: `hotplug_path' undeclared (first use in this function) > dev.c:2736: (Each undeclared identifier is reported only once > dev.c:2736: for each function it appears in.) > make[3]: *** [dev.o] Error 1 > make[3]: Leaving directory `/usr/src/linux-2.4/net/core' > make[2]: *** [first_rule] Error 2 > make[2]: Leaving directory `/usr/src/linux-2.4/net/core' > make[1]: *** [_subdir_core] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4/net' > make: *** [_dir_net] Error 2 > > It looks like /net/core/dev.c should add functions like run_sbin_hotplug > only if CONFIG_HOTPLUG is set. no, not just there but also in init/main.c the patch below has been posted here ages ago and a similar one even earlier (so I was told, I didn't check). Regards, Tigran diff -urN -X dontdiff linux/init/main.c work/init/main.c --- linux/init/main.c Fri Nov 17 10:29:34 2000 +++ work/init/main.cFri Nov 17 11:27:27 2000 @@ -712,11 +712,13 @@ init_pcmcia_ds(); /* Do this last */ #endif +#ifdef CONFIG_HOTPLUG /* do this after other 'do this last' stuff, because we want * to minimize spurious executions of /sbin/hotplug * during boot-up */ net_notifier_init(); +#endif /* Mount the root filesystem.. */ mount_root(); diff -urN -X dontdiff linux/net/core/dev.c work/net/core/dev.c --- linux/net/core/dev.cFri Nov 17 10:29:34 2000 +++ work/net/core/dev.c Fri Nov 17 11:27:15 2000 @@ -2704,6 +2704,7 @@ return 0; } +#ifdef CONFIG_HOTPLUG /* Notify userspace when a netdevice event occurs, * by running '/sbin/hotplug net' with certain @@ -2765,3 +2766,4 @@ printk (KERN_WARNING "unable to register netdev notifier\n" KERN_WARNING "/sbin/hotplug will not be run.\n"); } +#endif - 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.2.18pre21
On Fri, Nov 17, 2000 at 12:30:00AM -0600, Peter Samuelson wrote: > Two easy "get out of jail free" cards. There are other, more complex > exploits. You have added one more. They all require root privileges. Actually, I've heard that a chrooted _non-root_ process can find another process with the same uid that's not chrooted and can ptrace() to pull itself out of the jail. I'd imagine dropping CAP_SYS_PTRACE would avoid this, though. > Bottom line: once you are in the chroot jail, you must drop root > privileges, or you defeat the purpose. Security-conscious coders know > this; it's not Linux-specific behavior or anything. It appears that even dropping root privileges might not be enough. And I realize that there are a number of ways that a root process can escape, I was mostly objecting to the assertion that chroot() was secure because everything before the chroot call is assumed to be trusted. -Jesse - 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-fbdev] Re: Video driver bug (fwd)
The aty128fb patch is good.
> Did anybody test these patches? Currently any user can crash the kernel by
> abusing this bug.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> -- Forwarded message --
> Date: Sat, 14 Oct 2000 18:21:25 +0200 (CEST)
> From: Geert Uytterhoeven <[EMAIL PROTECTED]>
> To: Samuel Rydh <[EMAIL PROTECTED]>
> Cc: Linux Frame Buffer Device Development <[EMAIL PROTECTED]>,
> Linux/PPC Development <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: [linux-fbdev] Re: Video driver bug
>
> On Sat, 7 Oct 2000, Geert Uytterhoeven wrote:
> > On Sat, 7 Oct 2000, Samuel Rydh wrote:
> > > Certain 2.4 video drivers (aty128, aty, platinum, tdfx, iga)
> > > appear to be buggy. More specifically, the problem is the
> > > following:
> > >
> > > In the set_disp function, info->dispsw is initialized and disp->dispsw
> > > is given the address of info->dispsw:
> > >
> > > static void aty128_set_disp(..)
> > > {
> > > switch(bpp) {
> > > case 8:
> > > info->dispsw = accel ? fbcon_aty128_8 : fbcon_cfb8;
> > > disp->dispsw = >dispsw;
> > > break;
> > > ...
> > > }
> > >
> > > The problem is that the info struct is shared by all virtual consoles.
> > > Thus if the video mode is set on a console which is not active, the
> > > active console will be affected too. This typically results in a kernel
> > > panic (the wrong set of console output functions is used).
> >
> > You're right. *_set_disp() may be called for non-active VTs, changing
> > info->dispsw for the active VT.
>
> Here are my fixes for aty128fb, atyfb, platinumfb, and tdfxfb.
>
> Igafb is not affected since it sets disp during initialization only.
>
> Can someone please test these patches so I can send them to Linus? I'm unable
> to test any of them (besides a simple compile test). Thanks!
>
> --- linux-dispsw-fix-2.4.0-test10-pre2/drivers/video/atyfb.c Sun Sep 17 20:04:17
>2000
> +++ geert-dispsw-fix-2.4.0-test10-pre2/drivers/video/atyfb.c Sat Oct 14 18:17:40
>2000
> @@ -466,8 +466,8 @@
> static int encode_fix(struct fb_fix_screeninfo *fix,
> const struct atyfb_par *par,
> const struct fb_info_aty *info);
> -static void atyfb_set_disp(struct display *disp, struct fb_info_aty *info,
> -int bpp, int accel);
> +static void atyfb_set_dispsw(struct display *disp, struct fb_info_aty *info,
> + int bpp, int accel);
> static int atyfb_getcolreg(u_int regno, u_int *red, u_int *green, u_int *blue,
>u_int *transp, struct fb_info *fb);
> static int atyfb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
> @@ -2826,8 +2826,8 @@
> }
>
>
> -static void atyfb_set_disp(struct display *disp, struct fb_info_aty *info,
> -int bpp, int accel)
> +static void atyfb_set_dispsw(struct display *disp, struct fb_info_aty *info,
> + int bpp, int accel)
> {
> switch (bpp) {
> #ifdef FBCON_HAS_CFB8
> @@ -2898,6 +2898,7 @@
> oldbpp = display->var.bits_per_pixel;
> oldaccel = display->var.accel_flags;
> display->var = *var;
> + accel = var->accel_flags & FB_ACCELF_TEXT;
> if (oldxres != var->xres || oldyres != var->yres ||
> oldvxres != var->xres_virtual || oldvyres != var->yres_virtual ||
> oldbpp != var->bits_per_pixel || oldaccel != var->accel_flags) {
> @@ -2913,8 +2914,6 @@
> display->line_length = fix.line_length;
> display->can_soft_blank = 1;
> display->inverse = 0;
> - accel = var->accel_flags & FB_ACCELF_TEXT;
> - atyfb_set_disp(display, info, par.crtc.bpp, accel);
> if (accel)
> display->scrollmode = (info->bus_type == PCI) ? SCROLL_YNOMOVE : 0;
> else
> @@ -2923,8 +2922,10 @@
> (*info->fb_info.changevar)(con);
> }
> if (!info->fb_info.display_fg ||
> - info->fb_info.display_fg->vc_num == con)
> + info->fb_info.display_fg->vc_num == con) {
> atyfb_set_par(, info);
> + atyfb_set_dispsw(display, info, par.crtc.bpp, accel);
> + }
> if (oldbpp != var->bits_per_pixel) {
> if ((err = fb_alloc_cmap(>cmap, 0, 0)))
> return err;
> @@ -4241,8 +4242,8 @@
>
> atyfb_decode_var(_display[con].var, , info);
> atyfb_set_par(, info);
> -atyfb_set_disp(_display[con], info, par.crtc.bpp,
> -par.accel_flags & FB_ACCELF_TEXT);
> +atyfb_set_dispsw(_display[con], info, par.crtc.bpp,
> + par.accel_flags & FB_ACCELF_TEXT);
>
> /* Install new colormap */
> do_install_cmap(con, fb);
> --- linux-dispsw-fix-2.4.0-test10-pre2/drivers/video/tdfxfb.c Fri Jul 28 21:19:20
>2000
> +++ geert-dispsw-fix-2.4.0-test10-pre2/drivers/video/tdfxfb.c Sat Oct 14 17:29:21
>2000
> @@ -327,7 +327,6 @@
>struct
Re: [linux-fbdev] Re: Video driver bug (fwd)
The aty128fb patch is good.
> Did anybody test these patches? Currently any user can crash the kernel by
> abusing this bug.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> -- Forwarded message --
> Date: Sat, 14 Oct 2000 18:21:25 +0200 (CEST)
> From: Geert Uytterhoeven <[EMAIL PROTECTED]>
> To: Samuel Rydh <[EMAIL PROTECTED]>
> Cc: Linux Frame Buffer Device Development <[EMAIL PROTECTED]>,
> Linux/PPC Development <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: [linux-fbdev] Re: Video driver bug
>
> On Sat, 7 Oct 2000, Geert Uytterhoeven wrote:
> > On Sat, 7 Oct 2000, Samuel Rydh wrote:
> > > Certain 2.4 video drivers (aty128, aty, platinum, tdfx, iga)
> > > appear to be buggy. More specifically, the problem is the
> > > following:
> > >
> > > In the set_disp function, info->dispsw is initialized and disp->dispsw
> > > is given the address of info->dispsw:
> > >
> > > static void aty128_set_disp(..)
> > > {
> > > switch(bpp) {
> > > case 8:
> > > info->dispsw = accel ? fbcon_aty128_8 : fbcon_cfb8;
> > > disp->dispsw = >dispsw;
> > > break;
> > > ...
> > > }
> > >
> > > The problem is that the info struct is shared by all virtual consoles.
> > > Thus if the video mode is set on a console which is not active, the
> > > active console will be affected too. This typically results in a kernel
> > > panic (the wrong set of console output functions is used).
> >
> > You're right. *_set_disp() may be called for non-active VTs, changing
> > info->dispsw for the active VT.
>
> Here are my fixes for aty128fb, atyfb, platinumfb, and tdfxfb.
>
> Igafb is not affected since it sets disp during initialization only.
>
> Can someone please test these patches so I can send them to Linus? I'm unable
> to test any of them (besides a simple compile test). Thanks!
>
> --- linux-dispsw-fix-2.4.0-test10-pre2/drivers/video/atyfb.c Sun Sep 17 20:04:17
>2000
> +++ geert-dispsw-fix-2.4.0-test10-pre2/drivers/video/atyfb.c Sat Oct 14 18:17:40
>2000
> @@ -466,8 +466,8 @@
> static int encode_fix(struct fb_fix_screeninfo *fix,
> const struct atyfb_par *par,
> const struct fb_info_aty *info);
> -static void atyfb_set_disp(struct display *disp, struct fb_info_aty *info,
> -int bpp, int accel);
> +static void atyfb_set_dispsw(struct display *disp, struct fb_info_aty *info,
> + int bpp, int accel);
> static int atyfb_getcolreg(u_int regno, u_int *red, u_int *green, u_int *blue,
>u_int *transp, struct fb_info *fb);
> static int atyfb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
> @@ -2826,8 +2826,8 @@
> }
>
>
> -static void atyfb_set_disp(struct display *disp, struct fb_info_aty *info,
> -int bpp, int accel)
> +static void atyfb_set_dispsw(struct display *disp, struct fb_info_aty *info,
> + int bpp, int accel)
> {
> switch (bpp) {
> #ifdef FBCON_HAS_CFB8
> @@ -2898,6 +2898,7 @@
> oldbpp = display->var.bits_per_pixel;
> oldaccel = display->var.accel_flags;
> display->var = *var;
> + accel = var->accel_flags & FB_ACCELF_TEXT;
> if (oldxres != var->xres || oldyres != var->yres ||
> oldvxres != var->xres_virtual || oldvyres != var->yres_virtual ||
> oldbpp != var->bits_per_pixel || oldaccel != var->accel_flags) {
> @@ -2913,8 +2914,6 @@
> display->line_length = fix.line_length;
> display->can_soft_blank = 1;
> display->inverse = 0;
> - accel = var->accel_flags & FB_ACCELF_TEXT;
> - atyfb_set_disp(display, info, par.crtc.bpp, accel);
> if (accel)
> display->scrollmode = (info->bus_type == PCI) ? SCROLL_YNOMOVE : 0;
> else
> @@ -2923,8 +2922,10 @@
> (*info->fb_info.changevar)(con);
> }
> if (!info->fb_info.display_fg ||
> - info->fb_info.display_fg->vc_num == con)
> + info->fb_info.display_fg->vc_num == con) {
> atyfb_set_par(, info);
> + atyfb_set_dispsw(display, info, par.crtc.bpp, accel);
> + }
> if (oldbpp != var->bits_per_pixel) {
> if ((err = fb_alloc_cmap(>cmap, 0, 0)))
> return err;
> @@ -4241,8 +4242,8 @@
>
> atyfb_decode_var(_display[con].var, , info);
> atyfb_set_par(, info);
> -atyfb_set_disp(_display[con], info, par.crtc.bpp,
> -par.accel_flags & FB_ACCELF_TEXT);
> +atyfb_set_dispsw(_display[con], info, par.crtc.bpp,
> + par.accel_flags & FB_ACCELF_TEXT);
>
> /* Install new colormap */
> do_install_cmap(con, fb);
> --- linux-dispsw-fix-2.4.0-test10-pre2/drivers/video/tdfxfb.c Fri Jul 28 21:19:20
>2000
> +++ geert-dispsw-fix-2.4.0-test10-pre2/drivers/video/tdfxfb.c Sat Oct 14 17:29:21
>2000
> @@ -327,7 +327,6 @@
>struct
