[PATCH] move xchg/cmpxchg to atomic.h
On parisc-linux mailing list, Grant Grundler wrote:
> After surveying all the arches that define __HAVE_ARCH_CMPXCHG:
>
> ./include/asm-alpha/system.h:#define __HAVE_ARCH_CMPXCHG 1
> ./include/asm-i386/system.h:#define __HAVE_ARCH_CMPXCHG 1
> ./include/asm-ia64/system.h:#define __HAVE_ARCH_CMPXCHG 1
> ./include/asm-ppc/system.h:#define __HAVE_ARCH_CMPXCHG 1
> ./include/asm-sparc64/system.h:#define __HAVE_ARCH_CMPXCHG 1
>
> I've come to the conclusion xchg/cmpxchg definitions do NOT
> belong in system.h. AFAICT, all the above use Load Linked semantics
> (or in the i386 case, operation is atomic). In other words, xchg/cmpxchg
> are atomic operations. Shouldn't xchg/cmpxchg definitions live
> with other atomic operations - asm/atomic.h?
On Sat, 30 Dec 2000 16:46:57 + (GMT), Alan Cox replied:
| Seems a reasonable thing to try and move to atomic.h yes
Fundemental problem is parisc only supports one atomic operation
(LDCW/LDCD) and uses spinlocks for all atomic operations including
xchg/cmpxchg. Issue is dependencies between system.h, atomic.h
and spinlock.h are *really* ugly and prevented parisc port from
inlining xchg/cmpxchg definitions. This is a first step in fixing
that problem.
I've already made this change to the parisc-linux source tree for parisc
and parisc64 builds. Below is the i386 patch for linux-2.4.0-prerelease.
This is a simple cut/paste.
thanks,
grant
diff -ruNp linux/include/asm-i386/atomic.h linux.patch/include/asm-i386/atomic.h
--- linux/include/asm-i386/atomic.h Sun Dec 31 11:10:16 2000
+++ linux.patch/include/asm-i386/atomic.h Mon Jan 1 23:28:08 2001
@@ -2,6 +2,7 @@
#define __ARCH_I386_ATOMIC__
#include
+#include /* for LOCK_PREFIX */
/*
* Atomic operations that C can't guarantee us. Useful for
@@ -111,4 +112,136 @@ __asm__ __volatile__(LOCK "andl %0,%1" \
__asm__ __volatile__(LOCK "orl %0,%1" \
: : "r" (mask),"m" (*addr) : "memory")
+
+/* xchg/cmpxchg moved from asm/system.h */
+#define xchg(ptr,v) ((__typeof__(*(ptr)))__xchg((unsigned
+long)(v),(ptr),sizeof(*(ptr
+
+#define tas(ptr) (xchg((ptr),1))
+
+struct __xchg_dummy { unsigned long a[100]; };
+#define __xg(x) ((struct __xchg_dummy *)(x))
+
+
+/*
+ * The semantics of XCHGCMP8B are a bit strange, this is why
+ * there is a loop and the loading of %%eax and %%edx has to
+ * be inside. This inlines well in most cases, the cached
+ * cost is around ~38 cycles. (in the future we might want
+ * to do an SIMD/3DNOW!/MMX/FPU 64-bit store here, but that
+ * might have an implicit FPU-save as a cost, so it's not
+ * clear which path to go.)
+ */
+extern inline void __set_64bit (unsigned long long * ptr,
+ unsigned int low, unsigned int high)
+{
+__asm__ __volatile__ (
+ "1: movl (%0), %%eax;
+ movl 4(%0), %%edx;
+ cmpxchg8b (%0);
+ jnz 1b"
+ :: "D"(ptr),
+ "b"(low),
+ "c"(high)
+ :
+ "ax","dx","memory");
+}
+
+extern void inline __set_64bit_constant (unsigned long long *ptr,
+unsigned long long value)
+{
+ __set_64bit(ptr,(unsigned int)(value), (unsigned int)((value)>>32ULL));
+}
+#define ll_low(x) *(((unsigned int*)&(x))+0)
+#define ll_high(x) *(((unsigned int*)&(x))+1)
+
+extern void inline __set_64bit_var (unsigned long long *ptr,
+unsigned long long value)
+{
+ __set_64bit(ptr,ll_low(value), ll_high(value));
+}
+
+#define set_64bit(ptr,value) \
+(__builtin_constant_p(value) ? \
+ __set_64bit_constant(ptr, value) : \
+ __set_64bit_var(ptr, value) )
+
+#define _set_64bit(ptr,value) \
+(__builtin_constant_p(value) ? \
+ __set_64bit(ptr, (unsigned int)(value), (unsigned int)((value)>>32ULL) ) : \
+ __set_64bit(ptr, ll_low(value), ll_high(value)) )
+
+/*
+ * Note: no "lock" prefix even on SMP: xchg always implies lock anyway
+ * Note 2: xchg has side effect, so that attribute volatile is necessary,
+ * but generally the primitive is invalid, *ptr is output argument. --ANK
+ */
+static inline unsigned long __xchg(unsigned long x, volatile void * ptr, int size)
+{
+ switch (size) {
+ case 1:
+ __asm__ __volatile__("xchgb %b0,%1"
+ :"=q" (x)
+ :"m" (*__xg(ptr)), "0" (x)
+ :"memory");
+ break;
+ case 2:
+ __asm__ __volatile__("xchgw %w0,%1"
+ :"=r" (x)
+ :"m" (*__xg(ptr)), "0" (x)
+ :"memory");
+ break;
+ case 4:
+ __asm__ __volatile__("xchgl %0,%1"
+ :"=r" (x)
+ :"m" (*__xg(ptr)), "0" (x)
+ :"memory");
+
Re: start___kallsyms missing from i386 vmlinux.lds ?
On Tue, 02 Jan 2001 01:56:08 -0500,
Paul Gortmaker <[EMAIL PROTECTED]> wrote:
>--- linux/arch/i386/vmlinux.lds~ Fri Jul 7 03:47:07 2000
>+++ linux/arch/i386/vmlinux.ldsMon Jan 1 07:55:50 2001
>+ __start___kallsyms = .; /* All kernel symbols */
>+ __kallsyms : { *(__kallsyms) }
>+ __stop___kallsyms = .;
kernel/module.c defines
extern const char __start___kallsyms[] __attribute__ ((weak));
extern const char __stop___kallsyms[] __attribute__ ((weak));
The symbols are weak and do not need to be defined. If gcc is not
honouring __attribute__ ((weak)) then you have a broken or obsolete
version of gcc. You need at least gcc 2.91.66 for kernel 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: Sparc64 compile error for 2.4.0-prerelease
Date:Tue, 02 Jan 2001 11:57:13 +0800 From: Tommy Wu <[EMAIL PROTECTED]> This patch still has problem for define 'HZ' in 'asm-sparc64/delay.h'. It defined in linux/param.h. I've been doing only SMP builds lately which is why I didn't catch this, thanks a lot. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
start___kallsyms missing from i386 vmlinux.lds ?
Hi,
I wasn't sure if this was overlooked or left out intentionally.
Paul.
--- linux/arch/i386/vmlinux.lds~Fri Jul 7 03:47:07 2000
+++ linux/arch/i386/vmlinux.lds Mon Jan 1 07:55:50 2001
@@ -26,6 +26,10 @@
__ksymtab : { *(__ksymtab) }
__stop___ksymtab = .;
+ __start___kallsyms = .; /* All kernel symbols */
+ __kallsyms : { *(__kallsyms) }
+ __stop___kallsyms = .;
+
_etext = .; /* End of text section */
.data : {/* Data */
--78FB7F1E1ED5961B194C9718--
__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.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: PC-speaker control
On Tue, Jan 02, 2001 at 01:40:43AM +0100, Daniel Phillips wrote: > Daniel Phillips wrote: > > > > Robert Read wrote: > > > Try this on the console: > > > > > > setterm -blength 0 > > > > > > no assembly required. :) > > > > Yes, and my xterm still beeps - if I make that go away then something > > else will beep. > > > > Somebody posted a patch to do a global disable of the speaker some time > > back, and I wish that the patch were generally available. The result of > > not having the global disable is an office full of beeping > > computers. Right, I see what you mean. Disabling the beep is one thing I always do, and it requires a few differnt steps, like "xset b off" for xterms and so on. It would be nice to switch it off in one place and be done with it. > > > > How does this look: > > > echo 0 >/proc/sys/dev/speaker/beep > This looks good to me. As far as I can tell, it looks like the beep is generated by kd_mksound, which is a function pointer that usually points to drivers/char/vt.c:_kd_mksound(). Can anyone verify this? It doesn't look to hard to write a sysctl driver that would change the function pointer to something quieter. Is this what patch did? robert - 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: Additional info. for PCI VIA IDE crazyness. Please read.
Is this problem possibly related to my issues on alpha? (when compiling for PC164 optimizations instead of generic alphaI get a lost interrupt message as well ) --Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[OOPS] kacpid dies on boot 2.4.0-prerelease
Attached is a ksymoops processed oops which kacpid creates as part of its initialization (i.e. at boot time). It was connected to AC power with a full battery, if that is significant. Kernel is 2.4.0-prerelease. The machine is a IBM Thinkpad i1200 series (to be more specific model 1161-267), Coppermine Celeron CPU 550MHz, 64MB RAM, BIOS updated to 1.0R. This machine works fine under APM except that it sucks as much power on suspend than when running (LCD and HD shut off, that's all). With ACPI I have the contrary problem that it goes into CPU powersave even when it should be running normally. The userspace bogomips program normally reports 546bm but only 64bm when running ACPI (and it is slow; kernel cpuinfo reports 1040bm in both cases, it is reduced in speed only after kernel did its own measurement). This could be related to the kacipd failure however. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ ksymoops 2.3.4 on i686 2.4.0-prerelease-acpi. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-prerelease-acpi/ (default) -m /boot/System.map-2.4.0-prerelease-acpi (specified) Unable to handle kernel NULL pointer dereference at virtual address c01ac476 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: a800 ebx: c3fa1ea4 ecx: 001e edx: c1123770 esi: edi: c027e3fc ebp: c027e378 esp: c3fa1e84 ds: 0018 es: 0018 ss: 0018 Process kacpid (pid: 7, stackpage=c3fa1000) Stack: c3f86360 c3fa1f1c c3fa1f78 c3f86360 c3f86360 c3fa1f1c c3fa1f78 c1123770 00f0 c1123760 c01ac597 c3f86360 c027e378 c020ef80 c3f86360 c3fa1f1c c3fa1f78 0006 30544142 0009 30504e50 00413043 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: ac aa 84 c0 75 f7 f3 aa 8b 43 04 50 e8 4d ab f7 ff 31 c0 83 >>EIP; c01ac476<= Trace; c01ac597 Trace; c020ef80 <_acpi_ctype+3700/6a45> Trace; c01988e1 Trace; c01a6187 Trace; c01a5a13 Trace; c020ea58 <_acpi_ctype+31d8/6a45> Trace; c01a61d7 Trace; c01a60e0 Trace; c01ac494 Trace; c020f30e <_acpi_ctype+3a8e/6a45> Trace; c01ac96c Trace; c020f30e <_acpi_ctype+3a8e/6a45> Trace; c01ac494 Trace; c020ea58 <_acpi_ctype+31d8/6a45> Trace; c020fc22 <_acpi_ctype+43a2/6a45> Trace; c01adaf8 Trace; c020fc1c <_acpi_ctype+439c/6a45> Trace; c01adb12 Trace; c01ac12f Trace; c020eb82 <_acpi_ctype+3302/6a45> Trace; c0220018 <__ksymtab_arp_broken_ops+0/8> Trace; c01074c3 Trace; c01074cc Code; c01ac476 <_EIP>: Code; c01ac476<= 0: aclods %ds:(%esi),%al <= Code; c01ac477 1: aastos %al,%es:(%edi) Code; c01ac478 2: 84 c0 test %al,%al Code; c01ac47a 4: 75 f7 jnefffd <_EIP+0xfffd> c01ac473 Code; c01ac47c 6: f3 aa repz stos %al,%es:(%edi) Code; c01ac47e 8: 8b 43 04 mov0x4(%ebx),%eax Code; c01ac481 b: 50push %eax Code; c01ac482 c: e8 4d ab f7 ffcall fff7ab5e <_EIP+0xfff7ab5e> c0126fd4 Code; c01ac487 11: 31 c0 xor%eax,%eax Code; c01ac489 13: 83 00 00 addl $0x0,(%eax)
[PATCH] Makefile fix for ieee1394
Now that I've had the time to understand the new kernel makefile structure the patch Kai Germaschewski posted is indeed the correct fix (move include line up). Furthermore it builds an .o object in the static compiled case now. I don't see any reason to choose the .a format and most other drivers also do .o. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/ diff -ruN linux-2.4.orig/Makefile linux-2.4/Makefile --- linux-2.4.orig/Makefile Tue Jan 2 03:38:50 2001 +++ linux-2.4/Makefile Tue Jan 2 05:12:36 2001 @@ -145,7 +145,7 @@ DRIVERS-$(CONFIG_ATM) += drivers/atm/atm.o DRIVERS-$(CONFIG_IDE) += drivers/ide/idedriver.o DRIVERS-$(CONFIG_SCSI) += drivers/scsi/scsidrv.o -DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394.a +DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394drv.o ifneq ($(CONFIG_CD_NO_IDESCSI)$(CONFIG_BLK_DEV_IDECD)$(CONFIG_BLK_DEV_SR)$(CONFIG_PARIDE_PCD),) DRIVERS-y += drivers/cdrom/driver.o diff -ruN linux-2.4.orig/drivers/ieee1394/Makefile linux-2.4/drivers/ieee1394/Makefile --- linux-2.4.orig/drivers/ieee1394/MakefileTue Jan 2 03:38:59 2001 +++ linux-2.4/drivers/ieee1394/Makefile Tue Jan 2 05:12:38 2001 @@ -8,7 +8,7 @@ # Note 2! The CFLAGS definitions are now in the main makefile. # -L_TARGET := ieee1394.a +O_TARGET = ieee1394drv.o export-objs := ieee1394_syms.o @@ -23,7 +23,7 @@ obj-$(CONFIG_IEEE1394_VIDEO1394) += video1394.o obj-$(CONFIG_IEEE1394_RAWIO) += raw1394.o +include $(TOPDIR)/Rules.make + ieee1394.o: $(ieee1394-objs) $(LD) -r -o $@ $(ieee1394-objs) - -include $(TOPDIR)/Rules.make - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Generic deferred file writing
On Tue, 2 Jan 2001, Roman Zippel wrote: > Block allocation is not my problem right now (and even directory handling > is not that difficult), but I will post somethings about this on fsdevel > later. > But one question is still open, I'd really like an answer for: > Is it possible to use a per-inode-indirect-block-semaphore? Depends on a filesystem. Generally you don't want asynchronous operations to grab semaphores shared with something else. kswapd knows to skip the locked pages, but that's it - if writepage() is going to block on a semaphore you will not know what had hit you. And while buffer-cache operations will not trigger writepage() (grep for GFP_BUFFER and GFP_IO and you'll see) you have no such warranties for other sources of memory pressure. If one of them hits while you are holding such semaphore - you are toast. We probably could pull it off for ext2_truncate() vs. ext2_get_block() but it would not do us any good. It would give excessive exclusion for operations that can be done in parallel just fine (example: we have a hole from 100Kb to 200Kb. Pageouts in that area can be trivially done i parallel - current code will not even try to do unrolls. With your locking they will be serialized for no good reason). What for? - 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: Additional info. for PCI VIA IDE crazyness. Please read.
In article <[EMAIL PROTECTED]>, Evan Thompson <[EMAIL PROTECTED]> wrote: > >-- THE PROBLEM -- > >I know that any kernel version in the 2.2, 2.3, 2.3.99pre series and >2.4.0-test kernels =<2.4.0-test11, I need to append >'ide1=0x170,0x376,15' to get my (so called) PCI VIA IDE controller to >put the secondary channel on IRQ 15 (otherwise, it'd put it on IRQ 14, >causing hdc/hdd: lost interrupt errors and would take 5 or so minutes >too boot). Hmm.. The PCI irq code will parse your BIOS pirq tables, and enforce the fact that those tables do seem to say that it's irq 14. It obviously appears that the tables are wrong, which is kind of sad. Especially as a lot of machines _have_ to trust the tables in order to get a working setup. What happens if you don't try to override the ide logic with the command line? It looks like Linux has always wanted to put it on irq14, which implies that the BIOS really set it up that way, and your irq15 thing was always something that the driver disagreed with. In particular, notice how even before, the IDE driver ignored the fact that you had specified irq15. The driver was very aware of the fact that it really had irq14 allocated: >2.4.0-test11: > >Uniform Multi-Platform E-IDE driver Revision: 6.31 >ide: Assuming 33MHz system bus speed for PIO modes; override with >idebus=xx >VP_IDE: IDE controller on PCI bus 00 dev 39 >VP_IDE: chipset revision 6 >VP_IDE: 100% native mode on irq 14 and it may be that what the irq=15 thing did was just hide some other bug. For example, what the PCI irq routing code will do is to not just enable irq14 (which looks like it was enabled even in test11), but it will also mark it as being level-triggered. It may be that the IDE driver itself has problems with this: it used to ignore the (real) irq14 before because you had specified irq15 by hand, and if that was an edge-triggered irq it didn't hurt. Now, when the PCI irq is properly set up as a level-triggered one, ignoring the real interrupt will result in an infinite flood of interrupts - they will _not_ go away until they are handled (which they never will be, because you lied to it and said it had irq 15). Please try a few things: - enabled DEBUG in arch/i386/kernel/pci-i386.h to see what the PCI irq routing tables say. - don't pass the command line with the bogus irq - alternatively, pass the command line, but use "ide1=0x170,0x376,14" instead (which will force it to use irq14 - the only difference from no command line at all should be that it doesn't even try to probe it) - see what happens if VIA low-level driver support is disabled, so that you end up using the non-chipset-specific code. It may be that the chipset-specific code has some magic "change the irq setup" code that clashes with the fact that the PCI layer has enabled the irq routing. (In particular, some of the low-level drivers have tried to do some things by hand, to work around the fact that the PCI layer hasn't done the kind of complete setup that it _does_ try to do these days. Sometimes that code is broken.). 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/
Re: [PATCH] set_bit takes a long.
From: Rusty Russell <[EMAIL PROTECTED]> Date:Tue, 02 Jan 2001 13:58:05 +1100 Alan has this, obviously hasn't made it to you. Yes it has, see testing/prerelease-diff :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Sparc64 compile error for 2.4.0-prerelease
See testing/prerelease-diff Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Generic deferred file writing
Hi, On Mon, 1 Jan 2001, Alexander Viro wrote: > But... But with AFFS you _have_ exclusion between block-allocation and > truncate(). It has no sparse files, so pageout will never allocate > anything. I.e. all allocations come from write(2). And both write(2) and > truncate(2) hold i_sem. > > Problem with AFFS is on the directory side of that business and there it's > really scary. Block allocation is trivial... Block allocation is not my problem right now (and even directory handling is not that difficult), but I will post somethings about this on fsdevel later. But one question is still open, I'd really like an answer for: Is it possible to use a per-inode-indirect-block-semaphore? bye, Roman - 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] set_bit takes a long.
Alan has this, obviously hasn't made it to you. This is the only part of the `set_bit takes a long' audit results I personally care about. Thanks, Rusty. -- Hacking time. diff -urN -I \$.*\$ -X /tmp/kerndiff.oiH8zd --minimal linux-2.4.0-test11-5/include/linux/netfilter_ipv4/ip_conntrack.h working-2.4.0-test11-5/include/linux/netfilter_ipv4/ip_conntrack.h --- linux-2.4.0-test11-5/include/linux/netfilter_ipv4/ip_conntrack.hTue Nov 7 15:33:02 2000 +++ working-2.4.0-test11-5/include/linux/netfilter_ipv4/ip_conntrack.h Thu Nov 16 +19:38:19 2000 @@ -101,7 +101,7 @@ struct ip_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX]; /* Have we seen traffic both ways yet? (bitset) */ - volatile unsigned int status; + volatile unsigned long status; /* Timer function; drops refcnt when it goes off. */ struct timer_list timeout; - 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: Sparc64 compile error for 2.4.0-prerelease
same on alpha On Tue, Jan 02, 2001 at 09:36:09AM +0800, Tommy Wu wrote: > panic.c: In function `panic': > panic.c:80: `loops_per_sec' undeclared (first use in this function) > panic.c:80: (Each undeclared identifier is reported only once > panic.c:80: for each function it appears in.) -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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/
Additional info. for PCI VIA IDE crazyness. Please read.
IN ADVANCE: I'm sorry for this being so long, but I'm just trying to make sure people understand what my problem is. If you need more info, I'll be happy to give as much as I can, just give me a reply. Okay. Many of you already know the problems I'm having with my PCI VIA IDE controller. I've done a bit of additional testing and I think I have found out what the problem is. The only problem is that I'm not too versed in kernel programming (I'm getting there, but still don't understand some more complex C ideas), and therefore cannot fix this. -- THE PROBLEM -- I know that any kernel version in the 2.2, 2.3, 2.3.99pre series and 2.4.0-test kernels =<2.4.0-test11, I need to append 'ide1=0x170,0x376,15' to get my (so called) PCI VIA IDE controller to put the secondary channel on IRQ 15 (otherwise, it'd put it on IRQ 14, causing hdc/hdd: lost interrupt errors and would take 5 or so minutes too boot). -- WHAT I HAVE FOUND NOW, is that something has changed from 2.4.0-test11 to 2.4.0-test12 in either the ide implimentation or with IRQ handling (although there was only one change in irq.c -- something going from and int to a long) that has caused my system to complain about hdb: lost interrupt, and refuses to boot. I used the EXACT SAME configuration for both -test11 and -test12, and 11 worked properly, and 12 causes problems (see above). I was clever enough to add printer console support to my kernel, and was able to print out the kernel messages for -test12 (I didn't need to print out -test11's messages, but the support was still in the kernel). After comparing the output, the only relavent change I found was the addition of this line in the kernel message: 2.4.0-test11: Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 6 VP_IDE: 100% native mode on irq 14 TO 2.4.0-test12: Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 +PCI: Assigned IRQ 14 for device 00:07.1 VP_IDE: chipset revision 6 VP_IDE: 100% native mode on irq 14 (notice the new line idicated with the '+'). -- If I haven't given enough information, don't hesitate to ask for more. I'd like some reply to this situation because it just seems odd for this to happen. Like I said eariler, if I knew what to do, I'd be happy to submit a patch, but I'm still learning C, so I'm not capable to do that yet. Thanks in advance, -- | Evan Thompson| ICQ:2233067 | | Freelance Computer Nerd | AIM:Evaner517 | | [EMAIL PROTECTED] | Yahoo!: evanat| | http://evaner.penguinpowered.com | MSN:evaner517 | - 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] Re: FAIL: 2.2.18 + AA-VM-global-7 + serial 5.05
According to Matthias Andree: > I have a vanilla 2.2.18 that I patch Andrea Arcangeli's VM-global-7 > patch (for 2.2.18pre25) on top, as well as I²C 2.5.4, the current > --12-09 IDE.2.2.18 patch and ReiserFS 3.5.28. So far, so good. If I now > patch serial 5.05 on top of that, the kernel itself detects devices, but > does nothing if it's to boot /sbin/init. ctrl-alt-del and Magic SysRq > are both functional and can reboot the machine. VA's current kernel includes VM-global and serial-5.05 (and lots of other stuff :-)). The only problem we had with serial-5.05 was its 2.2/2.4 compatibility code getting confused because 2.2.18 has more of 2.4's init macros available. Try this: Index: tty_io.c === RCS file: /cvs/valinux/kernel/linux/drivers/char/tty_io.c,v retrieving revision 1.2 retrieving revision 1.2.12.1 diff -u -2 -p -r1.2 -r1.2.12.1 --- tty_io.c2000/08/30 21:33:27 1.2 +++ tty_io.c2000/09/28 08:21:34 1.2.12.1 @@ -2185,7 +2185,4 @@ __initfunc(int tty_init(void)) espserial_init(); #endif -#ifdef CONFIG_SERIAL - rs_init(); -#endif #ifdef CONFIG_COMPUTONE ip2_init(); -- Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]> "Give me immortality, or give me death!" // Firesign Theatre - 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: ne2000 (ISA) & test11+
> Second: I'm having problems loading my ne2000 (ISA) card as a module ditto for myself since i started using new SMP machine sometime around 2.4.0-test8 or so. the modprobe works the second time (and subsequently) when i run it by hand after boot scripts finish. i've tried all kinds of combinations of insmod/modprobe/isapnp etc with no luck. wouldnt mind tracking this annoyance down. boot log: Jan 1 08:03:18 localhost kernel: isapnp: Scanning for Pnp cards... Jan 1 08:03:18 localhost kernel: isapnp: Card 'NDC Plug & Play Ethernet Card' Jan 1 08:03:18 localhost kernel: isapnp: 1 Plug & Play card detected total Jan 1 08:03:18 localhost kernel: ne.c: No NE*000 card found at i/o = 0x220 [snip eth0] Jan 1 08:03:18 localhost kernel: ne.c: No NE*000 card found at i/o = 0x220 Jan 1 08:03:18 localhost kernel: ne.c: No NE*000 card found at i/o = 0x220 [snip sound card / parallel port ] Jan 1 08:03:21 localhost kernel: ne.c: No NE*000 card found at i/o = 0x220 Jan 1 08:03:21 localhost insmod: /lib/modules/2.4.0-test12/kernel/drivers/net/ne.o: init_module: No such device or address Jan 1 08:03:21 localhost insmod: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters Jan 1 08:03:21 localhost insmod: /lib/modules/2.4.0-test12/kernel/drivers/net/ne.o: insmod eth1 failed Jan 1 08:03:23 localhost kernel: ne.c: No NE*000 card found at i/o = 0x220 Jan 1 08:03:23 localhost insmod: /lib/modules/2.4.0-test12/kernel/drivers/net/ne.o: init_module: No such device or address Jan 1 08:03:23 localhost insmod: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters Jan 1 08:03:23 localhost insmod: /lib/modules/2.4.0-test12/kernel/drivers/net/ne.o: insmod eth1 failed [finish boot] then modprobe by hand: Jan 1 08:03:59 localhost kernel: ne.c: ISAPnP reports Generic PNP at i/o 0x220, irq 5. Jan 1 08:03:59 localhost kernel: ne.c:v1.10 9/23/94 Donald Becker ([EMAIL PROTECTED]) Jan 1 08:03:59 localhost kernel: Last modified Nov 1, 2000 by Paul Gortmaker Jan 1 08:03:59 localhost kernel: NE*000 ethercard probe at 0x220: 00 80 c6 f5 19 08 Jan 1 08:03:59 localhost kernel: eth1: NE2000 found at 0x220, using IRQ 5. les schaffer debian unstable SMP (speggy)/var/log/: lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Apollo PRO] (rev 23) [snip] from e/tc/modules.conf: alias eth1 ne options ne irq=5 io=0x220 - 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: Happy new year^H^H^H^Hkernel..
The ISDN changes for the HISAX drivers
that came in since test12 have introduced a bug that causes a
AIEE-something and a complete kernel hang when i hangup the isdn line.
I have reversed the patch for all occurences of INIT_LIST_HEAD in the
isdn patch part and it works for me now.
The relevant part is attached. Please back it out for 2.4.0.
Happy new year
Gerold Jury
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/hisax/config.c
linux/drivers/isdn/hisax/config.c
--- v2.4.0-test12/linux/drivers/isdn/hisax/config.c Mon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/hisax/config.c Fri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: config.c,v 2.57.6.3 2000/11/29 17:48:59 kai Exp $
+/* $Id: config.c,v 2.57.6.6 2000/12/10 23:39:19 kai Exp $
*
* Author Karsten Keil ([EMAIL PROTECTED])
* based on the teles driver from Jan den Ouden
@@ -1180,7 +1180,6 @@
cs->tx_skb = NULL;
cs->tx_cnt = 0;
cs->event = 0;
- INIT_LIST_HEAD(>tqueue.list);
cs->tqueue.sync = 0;
cs->tqueue.data = cs;
@@ -1756,6 +1755,7 @@
{PCI_VENDOR_ID_CCD, PCI_DEVICE_ID_CCD_B00B, PCI_ANY_ID,
PCI_ANY_ID},
{PCI_VENDOR_ID_CCD, PCI_DEVICE_ID_CCD_B00C, PCI_ANY_ID,
PCI_ANY_ID},
{PCI_VENDOR_ID_CCD, PCI_DEVICE_ID_CCD_B100, PCI_ANY_ID,
PCI_ANY_ID},
+ {PCI_VENDOR_ID_ABOCOM, PCI_DEVICE_ID_ABOCOM_2BD1, PCI_ANY_ID,
+PCI_ANY_ID},
{PCI_VENDOR_ID_ASUSTEK, PCI_DEVICE_ID_ASUSTEK_0675, PCI_ANY_ID,
PCI_ANY_ID},
{PCI_VENDOR_ID_BERKOM, PCI_DEVICE_ID_BERKOM_T_CONCEPT, PCI_ANY_ID,
PCI_ANY_ID},
{PCI_VENDOR_ID_BERKOM, PCI_DEVICE_ID_BERKOM_A1T, PCI_ANY_ID,
PCI_ANY_ID},
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/hisax/isdnl1.c
linux/drivers/isdn/hisax/isdnl1.c
--- v2.4.0-test12/linux/drivers/isdn/hisax/isdnl1.c Mon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/hisax/isdnl1.c Fri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: isdnl1.c,v 2.41 2000/11/24 17:05:37 kai Exp $
+/* $Id: isdnl1.c,v 2.41.6.1 2000/12/10 22:01:04 kai Exp $
*
* isdnl1.c common low level stuff for Siemens Chipsetbased isdn cards
* based on the teles driver from Jan den Ouden
@@ -15,7 +15,7 @@
*
*/
-const char *l1_revision = "$Revision: 2.41 $";
+const char *l1_revision = "$Revision: 2.41.6.1 $";
#define __NO_VERSION__
#include
@@ -343,7 +343,6 @@
bcs->cs = cs;
bcs->channel = bc;
- INIT_LIST_HEAD(>tqueue.list);
bcs->tqueue.sync = 0;
bcs->tqueue.routine = (void *) (void *) BChannel_bh;
bcs->tqueue.data = bcs;
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/hysdn/boardergo.c
linux/drivers/isdn/hysdn/boardergo.c
--- v2.4.0-test12/linux/drivers/isdn/hysdn/boardergo.c Mon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/hysdn/boardergo.cFri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: boardergo.c,v 1.5 2000/11/22 17:13:13 kai Exp $
+/* $Id: boardergo.c,v 1.5.6.1 2000/12/10 22:01:04 kai Exp $
* Linux driver for HYSDN cards, specific routines for ergo type boards.
*
@@ -458,7 +458,6 @@
card->writebootseq = ergo_writebootseq;
card->waitpofready = ergo_waitpofready;
card->set_errlog_state = ergo_set_errlog_state;
- INIT_LIST_HEAD(>irq_queue.list);
card->irq_queue.sync = 0;
card->irq_queue.data = card;/* init task queue for interrupt */
card->irq_queue.routine = (void *) (void *) ergo_irq_bh;
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/isdn_net.c
linux/drivers/isdn/isdn_net.c
--- v2.4.0-test12/linux/drivers/isdn/isdn_net.c Sun Nov 19 18:44:08 2000
+++ linux/drivers/isdn/isdn_net.c Fri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: isdn_net.c,v 1.140 2000/11/01 17:54:01 detabc Exp $
+/* $Id: isdn_net.c,v 1.140.6.1 2000/12/10 22:01:04 kai Exp $
* Linux ISDN subsystem, network interfaces and related functions (linklevel).
*
@@ -181,7 +181,7 @@
int isdn_net_force_dial_lp(isdn_net_local *);
static int isdn_net_start_xmit(struct sk_buff *, struct net_device *);
-char *isdn_net_revision = "$Revision: 1.140 $";
+char *isdn_net_revision = "$Revision: 1.140.6.1 $";
/*
* Code for raw-networking over ISDN
@@ -2371,7 +2371,7 @@
netdev->local->netdev = netdev;
netdev->local->next = netdev->local;
- memset(>local->tqueue, 0, sizeof(struct tq_struct));
+ netdev->local->tqueue.sync = 0;
netdev->local->tqueue.routine = isdn_net_softint;
netdev->local->tqueue.data = netdev->local;
spin_lock_init(>local->xmit_lock);
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/pcbit/drv.c
linux/drivers/isdn/pcbit/drv.c
--- v2.4.0-test12/linux/drivers/isdn/pcbit/drv.cMon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/pcbit/drv.c Fri Dec 29 14:07:22 2000
@@ -134,8 +134,6 @@
memset(dev->b2, 0, sizeof(struct
[PATCH] fat_cache is not SMP safe (2.4.0-prerelease)
When copying large files to/from my vfat filesystem, I frequently get NULL
pointer dereference oopsen. I believe this to be a possible solution.
(I have been unable to cause an oops since I did this.)
(against 2.4.0-prerelease)
--- fs/fat/cache.c.orig Mon Jan 1 14:33:43 2001
+++ fs/fat/cache.c Mon Jan 1 19:13:29 2001
@@ -24,6 +24,7 @@
#endif
static struct fat_cache *fat_cache,cache[FAT_CACHE];
+spinlock_t fat_cache_lock = SPIN_LOCK_UNLOCKED;
/* Returns the this'th FAT entry, -1 if it is an end-of-file entry. If
new_value is != -1, that FAT entry is replaced by it. */
@@ -133,13 +134,16 @@
return next;
}
-
void fat_cache_init(void)
{
static int initialized = 0;
int count;
- if (initialized) return;
+ spin_lock(_cache_lock);
+ if (initialized) {
+ spin_unlock(_cache_lock);
+ return;
+ }
fat_cache = [0];
for (count = 0; count < FAT_CACHE; count++) {
cache[count].device = 0;
@@ -147,6 +151,7 @@
[count+1];
}
initialized = 1;
+ spin_unlock(_cache_lock);
}
@@ -157,6 +162,7 @@
if (!first)
return;
+ spin_lock(_cache_lock);
for (walk = fat_cache; walk; walk = walk->next)
if (inode->i_dev == walk->device
&& walk->start_cluster == first
@@ -166,8 +172,12 @@
#ifdef DEBUG
printk("cache hit: %d (%d)\n",walk->file_cluster,*d_clu);
#endif
- if ((*f_clu = walk->file_cluster) == cluster) return;
+ if ((*f_clu = walk->file_cluster) == cluster) {
+ spin_unlock(_cache_lock);
+ return;
+ }
}
+ spin_unlock(_cache_lock);
#ifdef DEBUG
printk("cache miss\n");
#endif
@@ -197,6 +207,7 @@
int first = MSDOS_I(inode)->i_start;
last = NULL;
+ spin_lock(_cache_lock);
for (walk = fat_cache; walk->next; walk = (last = walk)->next)
if (inode->i_dev == walk->device
&& walk->start_cluster == first
@@ -204,17 +215,22 @@
if (walk->disk_cluster != d_clu) {
printk("FAT cache corruption inode=%ld\n",
inode->i_ino);
+ spin_unlock(_cache_lock);
fat_cache_inval_inode(inode);
return;
}
/* update LRU */
- if (last == NULL) return;
+ if (last == NULL) {
+ spin_unlock(_cache_lock);
+ return;
+ }
last->next = walk->next;
walk->next = fat_cache;
fat_cache = walk;
#ifdef DEBUG
list_cache();
#endif
+ spin_unlock(_cache_lock);
return;
}
walk->device = inode->i_dev;
@@ -224,6 +240,7 @@
last->next = NULL;
walk->next = fat_cache;
fat_cache = walk;
+ spin_unlock(_cache_lock);
#ifdef DEBUG
list_cache();
#endif
@@ -238,10 +255,12 @@
struct fat_cache *walk;
int first = MSDOS_I(inode)->i_start;
+ spin_lock(_cache_lock);
for (walk = fat_cache; walk; walk = walk->next)
if (walk->device == inode->i_dev
&& walk->start_cluster == first)
walk->device = 0;
+ spin_unlock(_cache_lock);
}
@@ -249,9 +268,11 @@
{
struct fat_cache *walk;
+ spin_lock(_cache_lock);
for (walk = fat_cache; walk; walk = walk->next)
if (walk->device == device)
walk->device = 0;
+ spin_unlock(_cache_lock);
}
-
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/
Sparc64 compile error for 2.4.0-prerelease
make[2]: Entering directory `/usr/src/kernel-source-2.4.0-prerelease/kernel' sparc64-linux-gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototype s -O2 -fomit-frame-pointer -fno-strict-aliasing -m64 -pipe -mno-fpu -mcpu=ultras parc -mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare -Wa,--undeclared-regs-c -o panic.o panic.c panic.c: In function `panic': panic.c:80: `loops_per_sec' undeclared (first use in this function) panic.c:80: (Each undeclared identifier is reported only once panic.c:80: for each function it appears in.) make[2]: *** [panic.o] Error 1 make[2]: Leaving directory `/usr/src/kernel-source-2.4.0-prerelease/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/kernel-source-2.4.0-prerelease/kernel' make: *** [_dir_kernel] Error 2 -- Tommy Wu mailto:[EMAIL PROTECTED] http://www.teatime.com.tw/~tommy ICQ: 22766091 Mobile Phone: +886 936 909490 TeaTime BBS +886 2 31515964 24Hrs V.Everything - 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: sync() broken for raw devices in 2.4.x??
On Mon, Jan 01, 2001 at 07:50:31PM -0500, [EMAIL PROTECTED] wrote: > > I have a sync()/fdatasync() intensive application that is designed to work > on both raw files and raw partitions. Today I upgraded my kernel to the > new pre-release and found that my benchmark program would no longer finish > when handed a raw partition. I've written a small Java program (my app is > in Java) which demonstrates the bug. Make foo.dat a raw scsi partition to > re-produce. In my case it's "mknod foo.dat b 8 18". Just a minor correction: this is not a raw partition, but a buffered blockdevice. If you want a real rawdevice (where sync is a noop because all IO goes synchronously to disk) you need to bind a character raw device to the block device first using the raw util. >From a quick look sync_buffers() [which implements fsync on block devices] has not changed significantly between 2.2 and 2.4 and uses the same algorithm. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-testX fails to compile on my Athlon
In article <[EMAIL PROTECTED]> you write: > well.. silly me :)... I did have SMP enabled (it appears that's the > default option? but anyways...now I get a whole slew of other > errors which I'm not going to go into right now, cos that would > involve spamming everyone with about 4 pages of spam Did you do a "make mrproper" after changing to UP (be sure to save your .config first, though)? I've had trouble in the past where not everything that needs to get regenerated does. -- David M. Meyer [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/
ne2000 (ISA) & test11+
Hi All, First off: I wish everyone a very happy and coded 2001. Second: I'm having problems loading my ne2000 (ISA) card as a module since test11 (test10 + 2.2.17 works perfectly. Haven't tried 2.2.18...): When loading the module with 'modprobe ne io=0x360 irq=4' it says: /lib/modules/2.4.0-prerelease/kernel/drivers/net/ne.o: init_module: No such device or address Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters /lib/modules/2.4.0-prerelease/kernel/drivers/net/ne.o: insmod /lib/modules/2.4.0-prerelease/kernel/drivers/net/ne.o failed /lib/modules/2.4.0-prerelease/kernel/drivers/net/ne.o: insmod ne failed When using test10 or 2.2.17 it works ;) I'm I just being plain stupid (as in: did I miss something...), or is something wrong ?? system specs: 2.4.0-prerelease debian woody gcc version 2.95.2 2220 (Debian GNU/Linux) GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. GNU ld version 2.10.91 (with BFD 2.10.1.0.2) insmod version 2.3.23 tune2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Cheers, Taco. P.S.: I'm not linux-kernel, so please cc me (I read web-archives...) --- "I was only 75 years old when I met her and I was still a kid" -- Duncan McLeod - 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/
VM thrashing in test13-pre4 with Netscape
I don't know if this is a Netscape problem, or an XFree86 4.0.1 problem, or a kernel problem. I hadn't noticed it with previous kernels so I thought I should mention it. I'll download the latest kernel source tonight and try it out. I'm using 2.4.0-test13-pre4 with XFree86 4.0.1 and Netscape Communicator 4.73. The distro is slackware 7.1 on a Pentium III 667 MHz machine with an ASUS motherboard with a Via chipset and an Adaptec 29160 SCSI host bus adapter. It has 128 MB of 133 MHz ram. If I browse with Netscape for a while, after a while I start hearing a lot of disk activity and the response of the machine slows way down. "top" often shows kswapd as having the top CPU time. In one instance of this, Netscape was using 60% of the memory and XFree86 was using 40%. (I'm not sure if this is the memory in use or percentage of all available memory). If I quit netscape the thrashing stops, and I can start it up again and run OK for a while, but it seems to start up again much sooner. After a while I have to reboot. When it happens, the onset seems pretty sudden. It doesn't appear like something's slowly leaking memory. It feels more like something suddenly goes haywire. Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ [EMAIL PROTECTED] Tilting at Windmills for a Better Tomorrow. - 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/
sync() broken for raw devices in 2.4.x??
I have a sync()/fdatasync() intensive application that is designed to work
on both raw files and raw partitions. Today I upgraded my kernel to the
new pre-release and found that my benchmark program would no longer finish
when handed a raw partition. I've written a small Java program (my app is
in Java) which demonstrates the bug. Make foo.dat a raw scsi partition to
re-produce. In my case it's "mknod foo.dat b 8 18".
// -
import java.io.*;
public class sync {
public static void main(String args[]) throws Exception {
long ops = Long.parseLong(args[0]);
byte dat[] = new byte[Integer.parseInt(args[1])];
RandomAccessFile rf = new RandomAccessFile("foo.dat", "rw");
long time = System.currentTimeMillis();
long t2 = time;
for (int i=0; ihttp://www.tux.org/lkml/
Re: PC-speaker control
Daniel Phillips wrote: > > Robert Read wrote: > > Try this on the console: > > > > setterm -blength 0 > > > > no assembly required. :) > > Yes, and my xterm still beeps - if I make that go away then something > else will beep. > > Somebody posted a patch to do a global disable of the speaker some time > back, and I wish that the patch were generally available. The result of > not having the global disable is an office full of beeping computers. > > How does this look: > > cat 0 >/proc/sys/dev/speaker/beep eh, echo 0 >/proc/sys/dev/speaker/beep -- 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: PC-speaker control
Robert Read wrote: > Try this on the console: > > setterm -blength 0 > > no assembly required. :) Yes, and my xterm still beeps - if I make that go away then something else will beep. Somebody posted a patch to do a global disable of the speaker some time back, and I wish that the patch were generally available. The result of not having the global disable is an office full of beeping computers. How does this look: cat 0 >/proc/sys/dev/speaker/beep -- 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: 2.4.0-prerelease & 2048-byte FAT sectors
On Mon, 1 Jan 2001, Alan Cox wrote:
> > Just installed 2.4.0-prerelease, and it looks like FAT
> > filesystems on hardware 2048-byte sectors are still not
> > working.
> > Are there any plans to fix this, or should I consider
>
> Jens was fixing it for CD-ROM devices. I dont know if anyone was fixing
> for M/O devices currently
>
> > such devices obsolete? I'm keeping 2.2.17 around and
>
> Far from obsolete - its a bug.
This patch works good enough for me to get at the data on my MOs. Buyers
beware! I'm completely ignorant to fs issues, so the implementation is
not only dog slow but very probably also buggy. Anyway, it works for me,
and it should be better than the current oops on read(). Maybe Al can have
a quick look at it?
I also disabled mmap for large hw-block devices because the current
implementation yields incorrect results.
Regards,
Daniel.
--[snip]--
--- fs/fat/cvf.c.vanillaMon Jan 1 22:46:20 2001
+++ fs/fat/cvf.cMon Jan 1 23:31:23 2001
@@ -51,6 +51,9 @@
const char *buf,
size_t count,
loff_t *ppos);
+ssize_t bigblock_fat_file_read(struct file *filp, char *buf, size_t count,
+ loff_t *ppos);
+
struct cvf_format default_cvf = {
0, /* version - who cares? */
@@ -92,7 +95,7 @@
default_fat_access,
NULL,
default_fat_bmap,
- NULL,
+ bigblock_fat_file_read,
default_fat_file_write,
NULL,
NULL
--- fs/fat/file.c.vanilla Mon Jan 1 22:46:26 2001
+++ fs/fat/file.c Tue Jan 2 00:11:01 2001
@@ -4,6 +4,9 @@
* Written 1992,1993 by Werner Almesberger
*
* regular file handling primitives for fat-based filesystems
+ *
+ * 2001-1-1 Daniel Kobras <[EMAIL PROTECTED]>:
+ * Added quick read operation for large sector media.
*/
#define ASC_LINUX_VERSION(V, P, S) (((V) * 65536) + ((P) * 256) + (S))
@@ -114,6 +117,54 @@
return retval;
}
+/* This is a hack. No readahead and other fancy stuff, but hopefully enough
+ * to get MOs working again. [dk]
+ * FIXME: Not sure whether I got error checking right.
+ */
+ssize_t bigblock_fat_file_read(struct file *filp, char *buf, size_t count,
+ loff_t *ppos)
+{
+ struct inode *inode = filp->f_dentry->d_inode;
+ int phys, pos;
+ struct buffer_head *bh;
+ size_t to_go, done;
+ char *buf_start = buf;
+
+ /* Taken from 2.2 source. */
+ if (!S_ISREG(inode->i_mode) && !S_ISLNK(inode->i_mode))
+ return -EINVAL;
+
+ if (*ppos > inode->i_size || !count)
+ return 0;
+
+ if (inode->i_size - *ppos < count)
+ count = inode->i_size - *ppos;
+
+ pos = *ppos>>SECTOR_BITS;
+ to_go = SECTOR_SIZE - (*ppos&(SECTOR_SIZE-1));
+ goto _start;
+
+ do {
+ to_go = SECTOR_SIZE;
+_start:
+ phys = fat_bmap(inode, pos++);
+ if (!phys)
+ return -EIO;
+ bh = fat_bread(inode->i_sb, phys);
+ if (!bh)
+ return -EIO;
+ done = to_go > count ? count : to_go;
+ if (copy_to_user(buf, bh->b_data, done))
+ return -EFAULT;
+ fat_brelse(inode->i_sb, bh);
+ buf += done;
+ *ppos += done;
+ } while ((count -= done));
+
+ return buf - buf_start;
+}
+
+
void fat_truncate(struct inode *inode)
{
struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
--- fs/fat/inode.c.vanilla Tue Jan 2 00:36:18 2001
+++ fs/fat/inode.c Tue Jan 2 00:22:04 2001
@@ -820,6 +820,9 @@
inode->i_size = CF_LE_L(de->size);
inode->i_op = _file_inode_operations;
inode->i_fop = _file_operations;
+ /* FIXME: mmap is broken with large hwblocks! [dk] */
+ if (sb->s_blocksize > 512)
+ inode->i_fop->mmap = NULL;
inode->i_mapping->a_ops = _aops;
MSDOS_I(inode)->mmu_private = inode->i_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: NIC recommendations (was Re: Repeatable 2.4.0-test13-pre4...)
Followup to: <[EMAIL PROTECTED]> By author:"Barry K. Nathan" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > In any case, tulips have been more problematic for me than 8139, pcnet32, > or 3c905c (whose reliability are all comparable IME). I've never tried > eepro100, though. (Also, I'm speaking in terms of my experiences across > all OS's which I've used the cards under, not just under Linux, although > my Linux experiences are similar to the experiences I've had overall.) > I have used eepro100's on *a lot* of boxes, including *.kernel.org; haven't had any problems whatsoever any time recently. -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: devices.txt inconsistency
Followup to: <[EMAIL PROTECTED]> By author:Robert Read <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > devices.txt does need some updating. It still lists char-major-13 as > the PC Speaker, but 13 appears to be the major for new input driver, > and the joystick driver is now a minor off the that. Are there now > two Joystick drivers, or can char-major-15 be obsoleted/deleted? > I think there are two; at least, the number will remain reserved for a long time. The current devices.txt is available at: http://www.lanana.org/docs/device-list/devices.txt I don't have the details for /dev/input/* in there; I need to still make that update. -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: netfilter enum conflict?
In message <[EMAIL PROTECTED]> you write:
> Hi:
>
> include/linux/netfilter_ipv4.h and include/linux/netfilter_ipv6.h
> both define enum nf_ip_hook_priorities. This trips the compiler
> if both are included. Should one change to nf_ipv6_hook_priorities?
Yes. Only noone has ever included both yet.
Rusty.
--
Hacking time.
--- working-2.4.0-test13-3/include/linux/netfilter_ipv6.h.~1~ Tue May 23 02:50:55
2000
+++ working-2.4.0-test13-3/include/linux/netfilter_ipv6.h Tue Jan 2 10:27:51
+2001
@@ -54,7 +54,7 @@
#define NF_IP6_NUMHOOKS5
-enum nf_ip_hook_priorities {
+enum nf_ip6_hook_priorities {
NF_IP6_PRI_FIRST = INT_MIN,
NF_IP6_PRI_CONNTRACK = -200,
NF_IP6_PRI_MANGLE = -150,
-
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: devices.txt inconsistency
How's this? Should char-major-15 be obsoleted, deleted or just left in for now? robert --- linux/Documentation/devices.txt.bak Mon Jan 1 15:29:24 2001 +++ linux/Documentation/devices.txt Mon Jan 1 15:33:38 2001 @@ -430,14 +430,14 @@ 1 = /dev/dos_cd1 Second MSCDEX CD-ROM ... - 13 char PC speaker (OBSOLETE) - 0 = /dev/pcmixer Emulates /dev/mixer - 1 = /dev/pcsp Emulates /dev/dsp (8-bit) - 4 = /dev/pcaudio Emulates /dev/audio - 5 = /dev/pcsp16 Emulates /dev/dsp (16-bit) + 13 char Generic Input Driver + 0 = /dev/input/js0First joystick + 1 = /dev/input/js1Second joystick +... - The current PC speaker driver uses the Open Sound - System interface, and these devices are obsolete. + 64 = /dev/input/event0 For testing/debugging + 65 = /dev/input/event1 + ... block 8-bit MFM/RLL/IDE controller 0 = /dev/xda First XT disk whole disk On Mon, Jan 01, 2001 at 05:06:54PM -0500, Ari Pollak wrote: > This has not been fixed for at least a year that i can remember - in > Documentation/devices.txt, it says /dev/js* should be char-major-15*, > but in Documentation/joystick.txt it says it should be char-major-13. > I'm assuming joystick.txt is the correct one, and devices.txt should be > updated to reflect this.. before 2.4.0 would be nice. > - > 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: devices.txt inconsistency
devices.txt does need some updating. It still lists char-major-13 as the PC Speaker, but 13 appears to be the major for new input driver, and the joystick driver is now a minor off the that. Are there now two Joystick drivers, or can char-major-15 be obsoleted/deleted? robert On Mon, Jan 01, 2001 at 05:06:54PM -0500, Ari Pollak wrote: > This has not been fixed for at least a year that i can remember - in > Documentation/devices.txt, it says /dev/js* should be char-major-15*, > but in Documentation/joystick.txt it says it should be char-major-13. > I'm assuming joystick.txt is the correct one, and devices.txt should be > updated to reflect this.. before 2.4.0 would be nice. > - > 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: About Celeron processor memory barrier problem
Hi Linus.
On Sun, 24 Dec 2000, Linus Torvalds wrote:
> On Sun, 24 Dec 2000, Tim Wright wrote:
>>> Which is all fine, but maybe the kernel really ought to detect
>>> that problem and complain at boot time?
>>>
>>> Or does that happen already?
>> There was a similar thread to this recently. The issue is that if
>> you choose the wrong processor type, you may not even be able to
>> complain.
Perhaps the boot and setup code should always be compiled to assume that
it's running on an i386 (or whatever the lowest common denominator is)
until it has verified that the correct processor is actually present?
Memory says that the boot and setup code is discarded during the boot
process, so this shouldn't cause any problems.
> Indeed. Some of the issues end up just becoming compiler flags,
> which means that anything that uses C is "tainted" by the processor
> choice. And happily there isn't all that much non-C in the kernel
> any more.
> One thing we _could_ potentially do is to simplify the CPU selection
> a bit, and make it a two-stage process. Basically have a
> bool 'Optimize for current CPU' CONFIG_CPU_CURRENT
> which most people who just want to get the best kernel would use.
> Less confusion that way.
Something along the lines of the enclosed patch ???
Best wishes from Riley.
***
--- linux-2.2.18/arch/i386/config.in~ Tue Dec 12 12:59:50 2000
+++ linux-2.2.18/arch/i386/config.inMon Jan 1 11:44:23 2001
@@ -9,16 +9,36 @@
bool 'Prompt for development and/or incomplete code/drivers' CONFIG_EXPERIMENTAL
endmenu
mainmenu_option next_comment
comment 'Processor type and features'
+bool 'Optimize for current CPU' CONFIG_CPU_CURRENT
+if [ "$CONFIG_CPU_CURRENT" = "y" ]; then
+
+
+ ####
+ ## Select current CPU. This is NOT valid in config.in ##
+ ## as it doesn't work with `make xconfig` at all, and ##
+ ## may not work with `make menuconfig` either.##
+ ####
+ ## The scripts/cpu shell script produces the variable ##
+ ## for the current processor or CONFIG_CPU_UNKNOWN if ##
+ ## it is unable to determine the current processor. ##
+ ####
+
+
+ define_bool `bash -c scripts/cpu` y
+
+fi
+if [ "$CONFIG_CPU_CURRENT" != "y" -o "$CONFIG_CPU_UNKNOWN" = "y" ]; then
-choice 'Processor family' \
+ choice ' Processor family' \
"386CONFIG_M386 \
486/Cx486 CONFIG_M486 \
586/K5/5x86/6x86 CONFIG_M586 \
Pentium/K6/TSC CONFIG_M586TSC \
PPro/6x86MXCONFIG_M686" PPro
+fi
#
# Define implied options from the CPU selection here
#
if [ "$CONFIG_M386" != "y" ]; then
define_bool CONFIG_X86_WP_WORKS_OK y
--- linux-2.2.18/scripts/cpu~ Thu Jan 1 01:00:00 1970
+++ linux-2.2.18/scripts/cpuMon Jan 1 14:39:11 2001
@@ -0,0 +1,33 @@
+#!/bin/bash
+
+function analyse() {
+ local CPU=CONFIG_CPU_UNKNOWN
+ local WORD
+
+ while read WORD ; do
+ case ".$WORD" in
+ .amd_k5)CPU=CONFIG_M586 ;;
+ .amd_k6)CPU=CONFIG_M586TSC ;;
+ .i386) CPU=CONFIG_M386 ;;
+ .i486) CPU=CONFIG_M486 ;;
+ .i586) CPU=CONFIG_M586 ;;
+ .pentium) CPU=CONFIG_M586 ;;
+ esac
+# echo "DEBUG: WORD = '$WORD', CPU = $CPU" >&2
+ done
+ echo $CPU
+}
+
+function model() {
+ uname -m
+ grep '^model name' /proc/cpuinfo | cut -d : -f 2-
+}
+
+function prepare() {
+ tr '(-' ' _'\
+ | tr -cd 'A-Z a-z_0-9\n'\
+ | tr A-Z a-z\
+ | tr -s ' ' '\n'
+}
+
+model | prepare | analyse
-
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: PC-speaker control
Try this on the console: setterm -blength 0 no assembly required. :) robert On Mon, Jan 01, 2001 at 06:30:37PM -0200, Rafael Diniz wrote: > Hey, Is there a way to control the PC-speaker with the Linux kernel 2.2? > I want to disable it. > I guy told me that with this assembly code I can disable it: > in al , 97 > and al,253 > out 97,al > Linux 2.4 will have any syscall to do this? > > Thanks > Rafael Diniz > Brazil > = > Conectiva Linux 6.0 (2.2.17) XFree86-4.0.1 > PII 233mhz 96Mb ram > SB16, USR56k, S3 VirgeDX/GX 4Mb, CD creative48X > HDa 10Gb Quantum HDb 4.1Gb Fugitsu > MSX2.0 256k MegaRam 256k Mapper 128k Vram > MSX is the future > = > - > 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: 2.4.0-pre compile err (pcxx)
this is a patch against the pcxx.c in the prerelease distribution
[clear thinkos. brain ok now.]
anyhow, before it was awful close ;-)
thanks again
--- pcxx.c~ Fri Dec 29 22:35:47 2000
+++ pcxx.c Mon Jan 1 22:30:00 2001
@@ -152,7 +152,7 @@
DECLARE_TASK_QUEUE(tq_pcxx);
static void pcxxpoll(unsigned long dummy);
-static void pcxxdelay(int);
+static void pcxxdelay(unsigned long);
static void fepcmd(struct channel *, int, int, int, int, int);
static void pcxe_put_char(struct tty_struct *, unsigned char);
static void pcxe_flush_chars(struct tty_struct *);
@@ -1821,9 +1821,9 @@
/*
* pcxxdelay - delays a specified number of milliseconds
*/
-static void pcxxdelay(int msec)
+static void pcxxdelay(unsigned long ms)
{
- mdelay(mseconds);
+ mdelay(ms);
}
Alan Cox <[EMAIL PROTECTED]> writes:
> > when i make bzimage with the pc/xx driver configured as a module, it
> > compiles ok. configuring it as built-in gives the following error:
>
> Im amazed it built as a module - thats why I missed the error
>
> > pcxx.c:1826: `mseconds' undeclared (first use in this function)
> > pcxx.c:1826: (Each undeclared identifier is reported only once
>
>
> --- drivers/char/pcxx.c~ Sat Dec 30 01:07:21 2000
> +++ drivers/char/pcxx.c Mon Jan 1 17:12:05 2001
> @@ -1823,7 +1823,7 @@
> */
> static void pcxxdelay(int msec)
> {
> - mdelay(mseconds);
> + mdelay(msec);
> }
>
-
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.0-prerelease, AX25 problems
Hi Jean-Luc, On Mon, 1 Jan 2001, f5ibh wrote: > You wrote : > > Is the "previous test version" you talk about 2.4.0-test13-pre7? There > > weren't any changes since then that could explain this, except maybe: > Yes, I mean test13-pre[12134567] and other older versions too. > I've already had the problem some time ago with an older 2.4.0-testxx kernel. > I don't think it is directly related to the ax25 stuff but maybe (?) a timer > modified elsewhere ? Ok, so the problem lies deeper. Could you take a guess at the version that worked (say 2.2.17?) and the first one that stopped working (say 2.4.0-test1?)... Once we have a rough range, I'll see if I can find anything. Also: I assume you have PROC_FS compiled. What does /proc/net/z8530drv contain before and after the failed packet TX attempt? And: Can you receive any packets? -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-testX fails to compile on my Athlon
On Mon, 1 Jan 2001 [EMAIL PROTECTED] wrote: > Are you trying to compile for SMP as well? I've seen similar > errors when selecting Athlon with SMP by mistake. well.. silly me :)... I did have SMP enabled (it appears that's the default option? but anyways...now I get a whole slew of other errors which I'm not going to go into right now, cos that would involve spamming everyone with about 4 pages of spam Matt - 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: Chipsets, DVD-RAM, and timeouts....
> @@ -460,7 +460,7 @@ > opts.isvfat = sbi->options.isvfat; > if (!parse_options((char *) data, , , , , > cvf_format, cvf_options) > - || (blksize != 512 && blksize != 1024 && blksize != 2048)) > + || (blksize != 512 && blksize != 1024)) > goto out_fail; This stops me using FAT on CD-ROM (which does work) - 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/
usb broken in 2.4.0 prerelease versus 2.2.18
Johannes, I apologize for not getting back to you earlier. Holidays, a changing kernel, and work, kept me away from the test. DATA: s10sh 0.1.9 is a program used to access the USB bus to get to digital cameras and download pictures, etc. I used it for quite awhile with 2.4.0 test up until test 10(?) or so when it broke. I then switched over to 2.2.18 where s10sh works fine. With the 2.4.0 prerelease out I compiled the 2.4.0 prerelease kernel and tested and the 2.4.0 prerelease kernel still breaks s10sh though the same s10sh program works fine with 2.2.18. I cannot say that 2.4.0 is broken because I don't know if it is expected for a program like s10sh to break over the kernel shift. What was odd for me was that is worked fine for quite awhile with 2.4.0 then snapped. DEFINITION of SNAPPED: s10sh provides a command GETALL to download all of the pictures in a camera's 'directory'. Running GETALL under 2.4.0 now has the first picture file being somewhat reasonably sized, the second being roughly 200M in size, then the next being almost a gig in size, etc. until the parition I was in filled up and everything stops. I then rebooted to 2.2.18 and the same program downloaded the pictures just fine. If someone wants my .config files for 2.2.18 and 2.4.0 let me know with instructions for getting it to you (i.e. attachments versus ...) Heitzso [EMAIL PROTECTED] -Original Message- From: Johannes Erdfelt [mailto:[EMAIL PROTECTED]] Sent: Monday, December 18, 2000 4:41 PM To: Heitzso Cc: '[EMAIL PROTECTED]' Subject: Re: usb broken in 2.4.0 test 12 versus 2.2.18 On Mon, Dec 18, 2000, Heitzso <[EMAIL PROTECTED]> wrote: > I have a Canon usb camera that I access via a > recent copy of the s10sh program (with -u option). > > Getting to the camera via s10sh -u worked through > large sections of 2.4.0 test X but broke recently. > I cannot say for certain which test/patch the > break occurred in. > > Running 2.4.0 test12 malloc errors appear. > Everything is fine with 2.2.18. I haven't tried > the test13 series of patches. > > key .config options: > CONFIG_USB on > DEVICEFS on > HOTPLUG on > UHCI on > everything else off (i.e. printers, keyboards, > mice, etc.). > > Baseline system is RH6.2 with most patches applied > (so avoiding RH7 compiler problems). Basic dev > environment is same (i.e. compiling the two kernels > on the same box). Could you give us the exact error message you saw? JE - 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.0-prerelease, AX25 problems
Hi Hans, You wrote : > Is the "previous test version" you talk about 2.4.0-test13-pre7? There > weren't any changes since then that could explain this, except maybe: Yes, I mean test13-pre[12134567] and other older versions too. I've already had the problem some time ago with an older 2.4.0-testxx kernel. I don't think it is directly related to the ax25 stuff but maybe (?) a timer modified elsewhere ? > Gnu C 2.95.2 Possible too. These compilers problems (which one for which kernel) are a bit boring... Anyway, I've downloaded the correct version of the compiler and retried the operation. [root@debian-f5ibh] ~ # gcc -v Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) The result is the same than with the other compiler. - Best wishes for 2001 for you and your family Jean-Luc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [revisited] Oops on boot with 2.4.0testX and GCC snapshots
On 1 Jan 2001, at 19:00, Andreas Franck wrote: > Hello together, > > after all the new year's celebrations, I have today taken the time to create > a small patch, based on Linus' idea, that will fix this problem in the > kernel, _without_ pessimizing any code or breaking with earlier compilers. > > 2.4.0-prerelease is now running here for an hour compiled completely with > gcc-snapshot-2.97-20001222, without any noticed problems (so far). > > Perhaps this could be included in the kernel to enable people to look for the > real caveats when compiling everything on the bleeding edge, or should we > wait for the GCC maintainers' call - I haven't had any reaction on my bug > report yet. > > Along with it is a small fix for a typo in fs/umsdos/mangle.c, which was > detected by GCC's new preprocessor (#elseif instead of #else). > > Greetings and a happy new year to everyone, > Andreas > > -- > ->>>--- Andreas Franck <<<- > ---<<< [EMAIL PROTECTED] --->>>--- > ->>> Keep smiling! <<<- > Thanks, this patch works for me. I'm using gcc-2.97-20001225. - 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/
missing symbols in prerelease
depmod: *** Unresolved symbols in /lib/modules/2.4.0-prerelease/kernel/drivers/net/irda/toshoboe.o depmod: __bad_udelay depmod: *** Unresolved symbols in /lib/modules/2.4.0-prerelease/kernel/drivers/video/atyfb.o depmod: __bad_udelay Pau - 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: Chipsets, DVD-RAM, and timeouts....
On Mon, Jan 01, 2001 at 05:34:01PM +, Alan Cox wrote: > > for FAT etc when reading. Writing is a bit more difficult, as that > > then turns out to generate a read before we can commit a dirty > > block. IMO, this type of thing does not belong in the drivers -- > > we should _never_ receive request for < hard block size. > > Unfortunately someone ripped the support out from 2.2 to do this, then didnt > fix it. So right now 2.4 is useless to anyone with an M/O drive. "ripped the support" is a bit nice for a thing that causes here a hard freeze. Famous last word: Jan 1 19:34:52 xterm kernel: MSDOS: Hardware sector size is 2048 ext2 works, but it's extremely slow (compared to linear write using dd) "Don't do it then" is a bit hard, because I use "-t auto" on mount and both 2048 && 512 byte medias (yes, the girl that leaves my bed when I enter it uses msdos on 512b/sect medias). I don't know how hard a fix would be, I don't need it but I only want to avoid crashes. --- linux/fs/fat/inode.c.orig Mon Jan 1 20:06:17 2001 +++ linux/fs/fat/inode.cMon Jan 1 20:06:51 2001 @@ -460,7 +460,7 @@ opts.isvfat = sbi->options.isvfat; if (!parse_options((char *) data, , , , , cvf_format, cvf_options) - || (blksize != 512 && blksize != 1024 && blksize != 2048)) + || (blksize != 512 && blksize != 1024)) goto out_fail; /* N.B. we should parse directly into the sb structure */ memcpy(&(sbi->options), , sizeof(struct fat_mount_options)); -- ciao - Stefan " ( cd /lib ; ln -s libBrokenLocale-2.2.so libNiedersachsen.so ) " Stefan TrabyLinux/ia32 fax: +43-3133-6107-9 Mitterlasznitzstr. 13 Linux/alphaphone: +43-3133-6107-2 8302 Nestelbach Linux/sparc http://www.hello-penguin.com Austriamailto:[EMAIL PROTECTED] Europe mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[RFC, PATCH] TLB flush changes for S/390
Hello,
on the S/390 architecture we have problems implementing the flush_tlb_page()
macro efficiently. The only semantically correct implementation on S/390 is
to completely flush the TLB, which is somewhat suboptimal ...
With only minor interface changes, however, it becomes possible for us to
use the (very efficient) Invalidate Page Table Entry (ipte) instruction,
which clears out one particular mapping from a virtual to a physical page
in a particular address space on all CPUs. The reason why we cannot use
this to implement flush_tlb_page() is simply that ipte requires that the
*original* PTE is still present in the page table when ipte is performed.
Thus, I was wondering whether it would be possible that you check these
proposed modifications out, and if they don't pose any problems, integrate
them into the standard kernel?
The basic idea is simple: wherever we currently have some pte modification
followed by a flush_tlb_page, merge these two operations into a single routine
provided by the architecture. The default asm-generic implementation can
then simply use flush_tlb_page, while the S/390 implementation can use ipte
to perform both operations combined.
The changes in detail:
* Make establish_pte architecture-dependent (as ptep_establish).
Semantics unchanged.
* Add new arch-dependent routine ptep_invalidate, which performs a
combination of ptep_get_and_clear and flush_tlb_page. Use this
routine in try_to_swap_out.
* Change semantics of ptep_test_and_clear_{young|dirty} to have
these routines perform a TLB flush if they change the bit.
Therefore, remove the flush_tlb_page call in filemap_sync_pte.
Note that the only caller of ptep_test_and_clear_dirty was
filemap_sync_pte which did a flush_tlb_page anyway, so here
the overall semantics is unchanged. However, the only caller
of ptep_test_and_clear_young is try_to_swap_out, which does
currently *not* flush the TLB when it clears the accessed bit.
However, I would argue that the TLB *should* in fact be flushed,
otherwise the accessed bit might not be re-set by future
accesses to the page ...
All in all, this change means that an architecture which
implements those four routines (ptep_test_and_clear_{young|dirty},
ptep_invalidate, ptep_establish) need not implement
flush_tlb_page, because the common code does not call this
routine anymore. Those four routines can be efficiently
implemented on S/390 using ipte ...
Some remaining questions:
* Is there some reason why ptep_test_and_clear_young should
*not*, after all, flush the TLB?
* In try_to_swap_out, should the flush_cache_page call be
moved before the ptep_invalidate call to ensure it is
performed before the flush_tlb_page call?
Maybe flush_cache_page should even be *called* by
ptep_establish and ptep_invalidate?
* It is somewhat unfortunate that flush_tlb_page resides in
pgalloc.h, which makes it necessary to include pgalloc.h
into asm-generic/pgtable.h ...
Thanks,
Ulrich Weigand
(IBM Linux for S/390 development)
diff -ur linux-2.4.0-prerelease/include/asm-generic/pgtable.h
linux-2.4.0-prerelease-tlb/include/asm-generic/pgtable.h
--- linux-2.4.0-prerelease/include/asm-generic/pgtable.hMon Dec 11 22:45:42
2000
+++ linux-2.4.0-prerelease-tlb/include/asm-generic/pgtable.hMon Jan 1 20:51:00
+2001
@@ -1,22 +1,41 @@
#ifndef _ASM_GENERIC_PGTABLE_H
#define _ASM_GENERIC_PGTABLE_H
-static inline int ptep_test_and_clear_young(pte_t *ptep)
+#include
+
+static inline int ptep_test_and_clear_young(struct vm_area_struct *vma, unsigned long
+address, pte_t *ptep)
{
pte_t pte = *ptep;
if (!pte_young(pte))
return 0;
set_pte(ptep, pte_mkold(pte));
+ flush_tlb_page(vma, address);
return 1;
}
-static inline int ptep_test_and_clear_dirty(pte_t *ptep)
+static inline int ptep_test_and_clear_dirty(struct vm_area_struct *vma, unsigned long
+address, pte_t *ptep)
{
pte_t pte = *ptep;
if (!pte_dirty(pte))
return 0;
set_pte(ptep, pte_mkclean(pte));
+ flush_tlb_page(vma, address);
return 1;
+}
+
+static inline void ptep_establish(struct vm_area_struct *vma, unsigned long address,
+pte_t *ptep, pte_t entry)
+{
+ set_pte(ptep, entry);
+ flush_tlb_page(vma, address);
+ update_mmu_cache(vma, address, entry);
+}
+
+static inline pte_t ptep_invalidate(struct vm_area_struct *vma, unsigned long
+address, pte_t *ptep)
+{
+ pte_t pte = *ptep;
+ pte_clear(ptep);
+ flush_tlb_page(vma, address);
+ return pte;
}
static inline pte_t ptep_get_and_clear(pte_t *ptep)
diff -ur linux-2.4.0-prerelease/include/asm-i386/pgtable.h
linux-2.4.0-prerelease-tlb/include/asm-i386/pgtable.h
--- linux-2.4.0-prerelease/include/asm-i386/pgtable.h Sun Dec 31 20:10:17 2000
+++ linux-2.4.0-prerelease-tlb/include/asm-i386/pgtable.h Mon Jan 1 17:11:27
+2001
@@ -281,10 +281,35 @@
static inline
devices.txt inconsistency
This has not been fixed for at least a year that i can remember - in Documentation/devices.txt, it says /dev/js* should be char-major-15*, but in Documentation/joystick.txt it says it should be char-major-13. I'm assuming joystick.txt is the correct one, and devices.txt should be updated to reflect this.. before 2.4.0 would be nice. - 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/
Promise PDC20267 irq timeout
I'm attempting to use a Promise FastTrak100 in native Ultra100 mode. Anyone
have any idea how to get this working?
Linux-2.4.0-prerelease SMP
Promise FastTrak100 - no array defined in adapter BIOS
4 IBM DTLA-307030 drives
boot params: ide2=0xac00 ide3=0xb400
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
ide0: BM-DMA at 0x9000-0x9007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x9008-0x900f, BIOS settings: hdc:DMA, hdd:pio
PDC20267: IDE controller on PCI bus 00 dev 70
PDC20267: chipset revision 2
PDC20267: not 100% native mode: will probe irqs later
PDC20267: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode.
PDC20267: neither IDE port enabled (BIOS)
hde: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
hde: IBM-DTLA-307030, ATA DISK drive
hdf: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
hdf: IBM-DTLA-307030, ATA DISK drive
hdg: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
hdg: IBM-DTLA-307030, ATA DISK drive
hdh: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
hdh: IBM-DTLA-307030, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xac00-0xac07,0xae06 on irq 16
ide3 at 0xb400-0xb407,0xb606 on irq 16 (shared with ide2)
hde: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63
hdf: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63
hdg: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63
hdh: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63
Partition check:
hde:hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
ide2: reset: master: error (0x00?)
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
ide2(?): unexpected interrupt, status=0x58, count=1
ide2: reset: master: error (0x00?)
hde: status error: status=0x58 { DriveReady SeekComplete DataRequest }
end_request: I/O error, dev 21:00 (hde), sector 0
hde: drive not ready for command
unable to read partition table
hdf:hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
hdf: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
ide2(?): unexpected interrupt, status=0x58, count=2
ide2: reset: master: error (0x00?)
hdf: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdf: drive not ready for command
hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
hdf: irq timeout: status=0x50 { DriveReady SeekComplete }
hdf: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
ide2(?): unexpected interrupt, status=0x58, count=3
ide2: reset: master: error (0x00?)
hdf: status error: status=0x58 { DriveReady SeekComplete DataRequest }
end_request: I/O error, dev 21:40 (hdf), sector 0
hdf: drive not ready for command
unable to read partition table
...
(similar for hdg ... hdh ...)
...
Thanks,
Andy Galasso
[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: linux 2.2.19pre and thttpd (VM-global problem?)
Hi again, After more-than-expected amount of hours spent on this, i managed to localize the problem and found a partial solution. I ran a series of test with thttpd compiled on rh6 and rh7 serving a couple of files on different kernels. In the first run i used 6 average sized mp3s and could not reproduce the problem, but then i added a couple of 100mb and 200mb mpeg videos and boing, there it was. libc kernel version result 2.2.18raid 2.1.3 ok 2.2.18raid 2.1.94 ok 2.2.18cdhs 2.1.3 crash at the third simultaneous connection 2.2.18cdhs 2.1.94 ok 2.2.19pre3aa4 2.1.3 ok 2.2.19pre3aa4 2.1.94 ok 2.4.0-test102.1.3 ok 2.4.0-test102.1.94 ok Now i use thttpd statically compiled with newer libc with the 2.2.18cdhs on the box that was making problems before and so far it runs smooth. If anyone is interested of strace outputs of above tests and wants to discover the source of the problem, i can help. -- Pegasus - 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 that part of the patch.....
Sorry about that, it was an undo that happened back at pre10 when the correct changes were applied; however, we may rip it out if I can finish the execute_diagnostics call to clear the PDIAG line and get the drive to report the impedence decay to correctly address the bit13 of word 93. For now it was a goof to an incomplete feature, but that was the only goof I am aware of at this point. 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: Happy new year^H^H^H^Hkernel..
On Mon, 1 Jan 2001 09:39:38 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]> wrote: >On 1 Jan 2001, Adam Sampson wrote: >> >> It appears to work (even with the reiserfs patch with the obvious >> Makefile tweak), but the drm modules have unresolved symbols: > >Does this fix it for you (do a "make clean" before re-building your tree)? > > Linus > > >--- v2.4.0-prerelease/linux/drivers/char/drm/Makefile Mon Jan 1 09:38:35 2001 >+++ linux/drivers/char/drm/MakefileMon Jan 1 09:38:04 2001 >@@ -44,22 +44,22 @@ > mga-objs := mga_drv.o mga_dma.o mga_context.o mga_bufs.o mga_state.o > i810-objs := i810_drv.o i810_dma.oi810_context.o i810_bufs.o > >-obj-$(CONFIG_DRM_GAMMA) += gamma.o >-obj-$(CONFIG_DRM_TDFX) += tdfx.o >-obj-$(CONFIG_DRM_R128) += r128.o >-obj-$(CONFIG_DRM_FFB) += ffb.o >-obj-$(CONFIG_DRM_MGA) += mga.o >-obj-$(CONFIG_DRM_I810) += i810.o >- >- > # When linking into the kernel, link the library just once. > # If making modules, we include the library into each module > > ifdef MAKING_MODULES > lib = drmlib.a > else >- obj-y += drmlib.a >+ extra-obj = drmlib.a > endif >+ >+obj-$(CONFIG_DRM_GAMMA) += gamma.o $(extra-obj) >+obj-$(CONFIG_DRM_TDFX) += tdfx.o $(extra-obj) >+obj-$(CONFIG_DRM_R128) += r128.o $(extra-obj) >+obj-$(CONFIG_DRM_FFB) += ffb.o $(extra-obj) >+obj-$(CONFIG_DRM_MGA) += mga.o $(extra-obj) >+obj-$(CONFIG_DRM_I810) += i810.o $(extra-obj) >+ > > include $(TOPDIR)/Rules.make That will break for anybody compiling a DRM card into the kernel and compiling a second DRM card as a module. drmlib.a will get a split personality, it will be compiled twice, once for kernel and once for module, which version actually gets linked will depend on the phase of the moon. Either that or it only gets compiled for kernel, which is where we came in. DRM maintainers: can we remove this restriction on needing multiple copies of the library? It makes no sense anyway. If you build a new library with the same function names then you cannot have two DRM cards built into the kernel, the function names will collide within vmlinux. So you have to use different function names for a new library, but then the old cards can share the old library and the new cards can share the new library, i.e. there is no need for each driver to have its own copy of the library. I strongly recommend that you remove the restriction on having multiple copies of the library. Then Adam J. Richter's patch does the job nicely, making drmlib.a a helper module. - 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.0-testX fails to compile on my Athlon
> I've looked for answers to this question before, but all I could find was > someone asking a similar question and no replies... > > I'm having great trouble getting 2.4.0-testX to compile on my system when > I select Athlon/K7 as the Processor Family [snip] > /root/source/linux/include/asm/string.h: In function `__memcpy3d': > /root/source/linux/include/asm/string.h:312: `current' undeclared (first > use in this function) > make: *** [init/main.o] Error 1 > [root@dipsy linux]# Are you trying to compile for SMP as well? I've seen similar errors when selecting Athlon with SMP by mistake. - 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/
user-mode port 0.36-2.4.0-prerelease
The user-mode port of 2.4.0-prerelease is available. hostfs is more improved. Writing files really works now. Executing binaries also works. There is still some memory corruption, though. I fixed the swapoff crash. The input to consoles and serial lines is now much more general. You can attach them to ptys, ttys, and ports now, with a few more interfaces to come. The project's home page is http://user-mode-linux.sourceforge.net The project's download page is http://sourceforge.net/project/filelist.php?grou p_id=429 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/
Sparc32: Error linking 2.4.0-prerelease
I get the following errors during the final linking of 2.4.0-prerelease on a Sparc IPX (sun4c). .config available upon request. ld -m elf32_sparc -r /mnt/ipx04/src/linux-2.4.0-prerelease/arch/sparc/kernel/head.o /mnt/ipx04/src/linux-2.4.0-prerelease/arch/sparc/kernel/init_task.o /mnt/ipx04/src/linux-2.4.0-prerelease/init/main.o /mnt/ipx04/src/linux-2.4.0-prerelease/init/version.o \ --start-group \ /mnt/ipx04/src/linux-2.4.0-prerelease/arch/sparc/kernel/kernel.o /mnt/ipx04/src/linux-2.4.0-prerelease/arch/sparc/mm/mm.o /mnt/ipx04/src/linux-2.4.0-prerelease/kernel/kernel.o /mnt/ipx04/src/linux-2.4.0-prerelease/mm/mm.o /mnt/ipx04/src/linux-2.4.0-prerelease/fs/fs.o /mnt/ipx04/src/linux-2.4.0-prerelease/ipc/ipc.o /mnt/ipx04/src/linux-2.4.0-prerelease/arch/sparc/math-emu/math-emu.o /mnt/ipx04/src/linux-2.4.0-prerelease/drivers/block/block.o /mnt/ipx04/src/linux-2.4.0-prerelease/drivers/char/char.o /mnt/ipx04/src/linux-2.4.0-prerelease/drivers/misc/misc.o /mnt/ipx04/src/linux-2.4.0-prerelease/drivers/net/net.o /mnt/ipx04/src/linux-2.4.0-prerelease/drivers/media/media.o /mnt/ipx04/src/linux-2.4.0-prerelease/drivers/scsi/scsidrv.o /mnt/ipx04/src/linux-2.4.0-prerelease/drivers/cdrom/driver.o /mnt/ipx04/src/linux-2.4.0-prerelease/drivers/sbus/sbus_all.o /mnt/ipx04/src/linux-2.4.0-prerelease/drivers/video/video.o /mnt/ipx04/src/linux-2.4.0-prerelease/net/network.o \ /mnt/ipx04/src/linux-2.4.0-prerelease/lib/lib.a /mnt/ipx04/src/linux-2.4.0-prerelease/lib/lib.a /mnt/ipx04/src/linux-2.4.0-prerelease/arch/sparc/prom/promlib.a /mnt/ipx04/src/linux-2.4.0-prerelease/arch/sparc/lib/lib.a \ --end-group -o vmlinux.o objdump -x vmlinux.o | ./btfixupprep > btfix.s gcc -c -o btfix.o btfix.s make[1]: Leaving directory `/mnt/ipx04/src/linux-2.4.0-prerelease/arch/sparc/boot' ld -m elf32_sparc -T arch/sparc/vmlinux.lds arch/sparc/kernel/head.o arch/sparc/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/sparc/kernel/kernel.o arch/sparc/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/sparc/math-emu/math-emu.o arch/sparc/boot/btfix.o \ drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/sbus/sbus_all.o drivers/video/video.o \ net/network.o \ /mnt/ipx04/src/linux-2.4.0-prerelease/lib/lib.a /mnt/ipx04/src/linux-2.4.0-prerelease/lib/lib.a /mnt/ipx04/src/linux-2.4.0-prerelease/arch/sparc/prom/promlib.a /mnt/ipx04/src/linux-2.4.0-prerelease/arch/sparc/lib/lib.a \ --end-group \ -o vmlinux arch/sparc/kernel/kernel.o: In function `udelay': arch/sparc/kernel/kernel.o(.text+0x110c): undefined reference to `loops_per_sec'arch/sparc/kernel/kernel.o(.text+0x1114): undefined reference to `loops_per_sec'arch/sparc/kernel/kernel.o: In function `get_cpuinfo': arch/sparc/kernel/kernel.o(.text+0x7228): undefined reference to `loops_per_sec'arch/sparc/kernel/kernel.o(.text+0x7240): undefined reference to `loops_per_sec'arch/sparc/mm/mm.o: In function `srmmu_paging_init': arch/sparc/mm/mm.o(.text.init+0x1aac): undefined reference to `pkmap_page_table'arch/sparc/mm/mm.o(.text.init+0x1af8): undefined reference to `pkmap_page_table'arch/sparc/mm/mm.o(.text.init+0x1d1c): undefined reference to `pkmap_page_table'kernel/kernel.o: In function `access_one_page': kernel/kernel.o(.text+0xb040): undefined reference to `kmap_high' kernel/kernel.o(.text+0xb0ac): undefined reference to `kunmap_high' kernel/kernel.o(.text+0xb10c): undefined reference to `kmap_high' kernel/kernel.o(.text+0xb178): undefined reference to `kunmap_high' kernel/kernel.o(__ksymtab+0x228): undefined reference to `kmap_high' kernel/kernel.o(__ksymtab+0x230): undefined reference to `kunmap_high' kernel/kernel.o(__ksymtab+0xa00): undefined reference to `loops_per_sec' mm/mm.o: In function `do_wp_page': mm/mm.o(.text+0x15b0): undefined reference to `kmap_high' mm/mm.o(.text+0x1604): undefined reference to `kunmap_high' mm/mm.o(.text+0x1664): undefined reference to `kmap_high' mm/mm.o(.text+0x16bc): undefined reference to `kmap_high' mm/mm.o(.text+0x1710): undefined reference to `kunmap_high' mm/mm.o(.text+0x1758): undefined reference to `kunmap_high' mm/mm.o: In function `do_anonymous_page': mm/mm.o(.text+0x1dec): undefined reference to `kmap_high' mm/mm.o(.text+0x1e40): undefined reference to `kunmap_high' mm/mm.o: In function `truncate_list_pages': mm/mm.o(.text+0x3d24): undefined reference to `kmap_high' mm/mm.o(.text+0x3d7c): undefined reference to `kunmap_high' mm/mm.o: In function `file_read_actor': mm/mm.o(.text+0x5688): undefined reference to `kmap_high' mm/mm.o(.text+0x56ec): undefined reference to `kunmap_high' mm/mm.o: In function `file_send_actor': mm/mm.o(.text+0x5818): undefined reference to `kmap_high' mm/mm.o(.text+0x5888): undefined reference to `kunmap_high' mm/mm.o: In function `filemap_nopage': mm/mm.o(.text+0x5e14): undefined
PC-speaker control
Hey, Is there a way to control the PC-speaker with the Linux kernel 2.2? I want to disable it. I guy told me that with this assembly code I can disable it: in al , 97 and al,253 out 97,al Linux 2.4 will have any syscall to do this? Thanks Rafael Diniz Brazil = Conectiva Linux 6.0 (2.2.17) XFree86-4.0.1 PII 233mhz 96Mb ram SB16, USR56k, S3 VirgeDX/GX 4Mb, CD creative48X HDa 10Gb Quantum HDb 4.1Gb Fugitsu MSX2.0 256k MegaRam 256k Mapper 128k Vram MSX is the future = - 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: Chipsets, DVD-RAM, and timeouts....
I screwed up on the patch for that one and have to find the correct one that does the correct walk around on the mis matched standard problems. This is my bad, sorry...back in 20 minutes... 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/
bug report in kernel-2.2.18: kernel cannot start
Hi, I compiled a 2.2.18 kernel, and copied the bzImage to a floppy, made some rdev commands, and when I boot on the floppy, it printfs "Loading." and stopped with the following message: 0200 AX:0212 BX: CX:5201 Dx: 0400 AX:0212 And the floppy continue to works, while this text is printed and make an infinite loop. Maybe I made an error, then I don't want to write to alan cox for the moment. But if this is a real important bug, I hope I can help to fix it by sumbitting this bug report. I think this is a bug from the kernel, because it work when I compile with the same patches for a Pentium II instead of i386. The configuration file is attached. Here are some details: * It failed when I compiled for i386 and i486 * I had the same error with kernel 2.2.17, but it worked (for i386 too) with 2.2.16 * I can compile the same kernel for Pentium II without error * My processor is Celeron 433 not overclocked * I use Linux Debian Potato with a recompiled kernel-2.2.17 * I applied two patches: - ReiserFS (the official one, for 2.2.18) - I replaced the fs/hpfs directory with a read/write driver * I compiled many drivers (not as module) to create a rescue bootdisk The commands I used before copying to a floppy: rdev bzImage /dev/fd0 rdev -r bzImage 49152 rdev -R bzImage 0 Thanks. -- François Dupoux [EMAIL PROTECTED] http://partimage.sourceforge.net/ # # Automatically generated make config: don't edit # # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set # # Processor type and features # CONFIG_M386=y # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M686 is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_1GB=y # CONFIG_2GB is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_QUIRKS=y CONFIG_PCI_OLD_PROC=y CONFIG_MCA=y CONFIG_VISWS=y CONFIG_X86_VISWS_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_OTHER=y CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # CONFIG_TOSHIBA is not set # # Plug and Play support # CONFIG_PNP=y CONFIG_PNP_PARPORT=y # # Block devices # CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_IDETAPE=y CONFIG_BLK_DEV_IDEFLOPPY=y CONFIG_BLK_DEV_IDESCSI=y CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_IDEDMA_AUTO is not set # CONFIG_IDE_CHIPSETS is not set # CONFIG_BLK_DEV_PS2 is not set # # Additional Block Devices # CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y # CONFIG_BLK_DEV_MD is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_PARIDE_PARPORT=y # CONFIG_PARIDE is not set CONFIG_BLK_CPQ_DA=y CONFIG_BLK_CPQ_CISS_DA=y # CONFIG_BLK_DEV_HD is not set # # Networking options # CONFIG_PACKET=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y # CONFIG_NETLINK_DEV is not set CONFIG_FIREWALL=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_IP_FIREWALL is not set # CONFIG_IP_ROUTER is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set CONFIG_IP_MROUTE=y # CONFIG_IP_PIMSM_V1 is not set # CONFIG_IP_PIMSM_V2 is not set CONFIG_IP_ALIAS=y # CONFIG_SYN_COOKIES is not set # # (it is safe to leave these untouched) # # CONFIG_INET_RARP is not set CONFIG_SKB_LARGE=y # # # CONFIG_IPX=y CONFIG_IPX_INTERN=y CONFIG_ATALK=y # # Telephony Support # # CONFIG_PHONE is not set # # SCSI support # CONFIG_SCSI=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set
Re: Chipsets, DVD-RAM, and timeouts....
On Mon, 1 Jan 2001, Andre Hedrick wrote: > On Mon, 1 Jan 2001, Alan Cox wrote: > > > > > as it apparently makes CONFIG_IDEDMA_IVB a complete no-op? > > > > > > Exactly what it is designed to do, Ignore Validity Bits, because the whole > > > damn messedup the rules between ATA-4 and ATA-6 > > > > I think the question is more - so why not lose the ifdef > > - > > Because there are the exceptions that get it correct based on the level of > ATA support reported in the IDENTIFY page. Andre, stop blathering, and answer the question. The code on both sides of the #ifdef is the same. WHY IS THE IFDEF THERE? Don't bleat about standards and ATA-4/5/6. They won't make the code behave any other way. Why do you have a config option that doesn't _do_ anything, except restate the exact same test in two different ways? Doing the same test in two different ways and making it _look_ like two different tests is confusing. Your explanation seems to be that "the standards are confusing, the source code had better be confusing too". And quite frankly, that is not a very good reason. 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: [RFC] Generic deferred file writing
Alexander Viro wrote: > GFP_BUFFER _may_ become an issue if we move bitmaps into pagecache. > Then we'll need a per-address_space gfp_mask. Again, patches exist > and had been tested (not right now - I didn't port them to current > tree yet). Bugger if I remember whether they were posted or not - they've > definitely had been mentioned on linux-mm, but IIRC I had sent the > modifications of VM code only to Jens. I can repost them. Please, and I'll ask Rik to post them on the kernelnewbies.org patch page. (Rik?) Putting bitmaps and group descriptors into the page cache will allow the current adhoc bitmap and groupdesc caching code to be deleted - the for-real cache should have better lru, be more efficient to access, not need special locking and won't have an arbitrary limit on number of cached bitmaps. About 300 lines of spagetti gone. I suppose the group descriptor pages still need to be locked in memory so we can address them through a table instead of searching the hash. OK, this must be what you meant by a 'proper' fix to the ialloc group desc bug I posted last month, which by the way is *still* there. How about applying my patch in the interim? It's a real bug, it just doesn't trigger often. > Some pieces of balloc.c cleanup had been posted on fsdevel. Check the > archives. They prepare the ground for killing lock_super() contention > on ext2_new_inode(), but that part wasn't there back then. > > I will start -bird (aka FS-CURRENT) branch as soon as Linus opens 2.4. > Hopefully by the time of 2.5 it will be tested well enough. Right now > it exists as a large patchset against more or less recent -test and > I'm waiting for slowdown of the changes in main tree to put them all > together. It would be awfully nice to have those patches available via ftp. Web-based mail archives don't make it because you can't generally can't get the patches out intact - the tabs get expanded and other noise inserted. -- 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: test13-pre5
Followup to: <[EMAIL PROTECTED]> By author:Geert Uytterhoeven <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > What about defining new types for this? Like e.g. `x8', being `u8' on platforms > were that's OK, and `u32' on platforms where that's more efficient? > You may just want to look at how C99 handles this using ; stdint.h defines types of the following format: int, uint ... signed/unsigned ... exact size _least ... no smaller than _fast... no smaller than, and efficient _t E.g. uint32_t, int_least64_t, uint_fast8_t (the latter could easily be a 32-bit type, for eaxmple.) In addition, constructor macros are defined, as well as (u)intmax_t and (u)intptr_t; which are defined as the largest possible integer and an integer large enough to hold a (void *), respectively. In other words: (void *)(uintptr_t)(void *)foo == (void *)foo -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: PS2ESDI
On Mon, Jan 01, 2001 at 01:35:18PM -0600, Hal Duston wrote: > In moving from 2.2.x to 2.4.x I have found that PS/2 Esdi will no > longer boot. The problem was introduced by what appears to have been > a small architectural change that shouldn't have had an impact. I am > looking into it, if anyone has an idea of what could be causing this, > please mail me. The relevant change occured at 2.3.32-pre3 A new > parameter was add to xxx_do_request. The parameter isn't used by > ps2esdi_do_request, but I can't see why it should have caused any > drive problems. Hopefully, I will figure the problem out within the > next week. I'll look into it. Guess I'll have to get my 386 running again... /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
[PATCH] i810_audio.c in 2.4.0-prerelease (fixes RealPlayer for one)
The patch from Tjeerd Mulder that is already in 2.4.0-prerelease fixes a
lot of issues with i810_audio, but it still does not seem to enable
variable rates
(non 48K rates). I am not sure if VRA works for everybody else with the
current
code, but I needed the patch below for VRA to work on my Dell Optiplex
GX110.
So the patch below specifically enables VRA during rate
change requests (based on code from Jim Studt, posted to LKML on Dec
29). This
is needed for things like Real Player to work , because the first thing
RealPlayer
does is to set the DAC rate to 44100Hz.
Also, the patch already in 2.4.0.-prerelease introduced a bug in the
driver that we
get a divide-by-zero error if we just do "fd=open("/dev/dsp", O_WRONLY)
; close (fd);".
This is also fixed below (the last hunk).
--- linux/drivers/sound/i810_audio.c.oldSat Dec 30 13:23:14 2000
+++ linux/drivers/sound/i810_audio.cMon Jan 1 13:24:36 2001
@@ -383,6 +383,7 @@
{
struct dmabuf *dmabuf = >dmabuf;
u32 dacp;
+ u16 extended_status;
struct ac97_codec *codec=state->card->ac97_codec[0];
if(!(state->card->ac97_features&0x0001))
@@ -410,6 +411,10 @@
if(rate != i810_ac97_get(codec, AC97_PCM_FRONT_DAC_RATE))
{
+ /* Reset variable rate mode */
+ extended_status = i810_ac97_get(codec,
AC97_EXTENDED_STATUS);
i810_ac97_set(codec, AC97_POWER_CONTROL, dacp|0x0200);
@@ -433,6 +438,7 @@
{
struct dmabuf *dmabuf = >dmabuf;
u32 dacp;
+ u16 extended_status;
struct ac97_codec *codec=state->card->ac97_codec[0];
if(!(state->card->ac97_features&0x0001))
@@ -460,6 +466,10 @@
if(rate != i810_ac97_get(codec, AC97_PCM_LR_DAC_RATE))
{
+ /* Reset variable rate mode */
+ extended_status = i810_ac97_get(codec,
AC97_EXTENDED_STATUS);
+ if (!(extended_status&1))
+ i810_ac97_set(codec, AC97_EXTENDED_STATUS,
extended_status|1);
/* Power down the ADC */
dacp=i810_ac97_get(codec, AC97_POWER_CONTROL);
i810_ac97_set(codec, AC97_POWER_CONTROL, dacp|0x0100);
@@ -770,7 +780,10 @@
swptr = dmabuf->swptr;
spin_unlock_irqrestore(>card->lock, flags);
- len = swptr % (dmabuf->dmasize/SG_LEN);
+ if (dmabuf->dmasize)
+ len = swptr % (dmabuf->dmasize/SG_LEN);
+ else
+ len = 0;
memset(dmabuf->rawbuf + swptr, silence, len);
-
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.0-pre compile err (pcxx)
Alan Cox <[EMAIL PROTECTED]> writes: > > when i make bzimage with the pc/xx driver configured as a module, it > > compiles ok. configuring it as built-in gives the following error: > > Im amazed it built as a module - thats why I missed the error well, the kernel compiled, but i kind of forgot to make modules :-) many thanks - 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: Chipsets, DVD-RAM, and timeouts....
On Mon, 1 Jan 2001, Alan Cox wrote: > > > as it apparently makes CONFIG_IDEDMA_IVB a complete no-op? > > > > Exactly what it is designed to do, Ignore Validity Bits, because the whole > > damn messedup the rules between ATA-4 and ATA-6 > > I think the question is more - so why not lose the ifdef > - Because there are the exceptions that get it correct based on the level of ATA support reported in the IDENTIFY page. When I state that it is all screwed up, I mean in a contigious nature of the Standard. The rules for ATA-4 with ATA-4 limited support is correct as is ATA-5 with ATA-5, and ATA-6 with ATA-6, but ATA-4 rules do not mix with ATA-5 nor ATA-6. This is the mess in front of me to sort. So we default a full test of both bits 13 and 14, but it you have a hardware combination that fails the rules. ATA-4 is HOST side and Device side based on Bit 13 only ATA-5 is HOST side and Device side based on Bit 14 only ATA-6 is HOST side and Device side based on Bit 14 and Bit 13 ATA-6 is the correct method... Cheers, 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/
PS2ESDI
In moving from 2.2.x to 2.4.x I have found that PS/2 Esdi will no longer boot. The problem was introduced by what appears to have been a small architectural change that shouldn't have had an impact. I am looking into it, if anyone has an idea of what could be causing this, please mail me. The relevant change occured at 2.3.32-pre3 A new parameter was add to xxx_do_request. The parameter isn't used by ps2esdi_do_request, but I can't see why it should have caused any drive problems. Hopefully, I will figure the problem out within the next week. Not on the list, Hal Duston [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-prerelease shmget woes.
On Mon, 1 Jan 2001, Gregory McLean wrote:
>
> Hi, I just compiled and booted up 2.4.0-prerelease, dropped into X-Windows
> and now gtk/gnome apps are giving the following warning:
>
> Gdk-WARNING **: shmget failed!
>
> Any ideas on what changed in the shm space to cause this?
>
> This is a PII 333 RH 7.0 system 2.4.0-test10 worked just fine on this
> machine.
Per request here is an strace around where the shmget fails:
(xmms is the target app running Full file available if needed)
getrlimit(0x3, 0xb430, 0xb4f8, 0xb430, 0xb430) = 0
setrlimit(RLIMIT_STACK, {rlim_cur=2044*1024, rlim_max=RLIM_INFINITY}) = 0
brk(0x8172000) = 0x8172000
pipe([5, 6])= 0
clone(child_stack=0x8171ac8,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND)
= 6299
write(6, "\0\0\0\0\5\0\0\0\0\0\0\0\0\200\31@\0\0\0\0\30l\1@\360A"..., 148)
= 148
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
write(6, "\0\17\35@\0\0\0\0\0\0\0\0 \223\6\10\0\0\0\0\0\0\0\200\0"...,
148) = 14
8
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
rt_sigsuspend([]
--- SIGRT_0 (Real-time signal 0) ---
<... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system
call)
sigreturn() = ? (mask now [])
shmget(IPC_PRIVATE, 32768, IPC_CREAT|0x1ff|0666) = -1 ENOSPC (No space
left on d
evice)
write(2, "\n", 1
) = 1
write(2, "Gdk", 3Gdk) = 3
write(2, "-", 1-)= 1
write(2, "WARNING **: ", 12WARNING **: )= 12
write(2, "shmget failed!", 14shmget failed!) = 14
write(2, "\n", 1
) = 1
brk(0x817b000) = 0x817b000
brk(0x8184000) = 0x8184000
brk(0x818d000) = 0x818d000
brk(0x8196000) = 0x8196000
brk(0x819f000) = 0x819f000
brk(0x81a8000) = 0x81a8000
brk(0x81b9000) = 0x81b9000
write(3, "\211\30\2\0\2\0\0\0\20\0\10\0\30\0op_WIN_SUPPORTING_"..., 40) =
40
read(3, "\1`)\0\0\0\0\0\34\1\0\0\0\0\0\0\0\0\0\0\1\0\0\0\200\252"..., 32)
= 32
write(3, "\20\0\5\0\n\0\0\0_WIN_LAYERIN", 20) = 20
read(3, "\1\0*\0\0\0\0\0#\1\0\0\0\0\0\0\1\0\0\0\1\0\0\0\200\252"..., 32) =
32
write(3, "\20\0\5\0\n\0\0\0_WIN_HINTSIN", 20) = 20
(bunch more garbage of xmms talking to the x server)
>From what I can tell its saying no space left on device.
>From proc:
-
cat /proc/sys/kernel/shmmax
33554432
cat /proc/sys/kernel/shmall
0
cat /proc/sys/kernel/shmmni
4096
-
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] cs46xx deadlocks in non-blocking read
> I've already sent this to Nils/Thomas but since it hasn't materialized > in prerelease or ac1, and since it's quite small and needed for a > number of things to function correctly, I'm sending it again in the > hopes that it will get applied before 2.4 final. Thanks - 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/
[temp t13] Set Features CPRM Lock, Proposal (was Re: CPRM) (fwd)
Anyone want to comment on the proposal to create a global setfeatures lockout of CPRM? The language used is in terms of the SPEC. Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development -- Forwarded message -- Date: Sat, 30 Dec 2000 02:24:46 -0800 (PST) From: Andre Hedrick <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [temp t13] Set Features CPRM Lock, Proposal (was Re: CPRM) ** This is the quasi-official and semi-temporary T13 email list server. ** Mr. Chairman, I am request a Proposal Number to present the content below at the February meeting. Of course I am aware that I will need to get a 2/3 support in a roll-call vote of approval to allow adoption in to ATA-6; however, this is only necessary if "e00148rX" is adopted in the same fashion and rules during the February meeting. Upon receiving the number I will submit the document to be reviewed by all. The purpose of this offensive crossover feature set is to prevent a valid JAVA type CPRM tool from attempting to perfrom a CPRM action without the HOST first giving notice for enduser certification of the process. Upon applying this method, T13 may prevent issues that may be deemed actionable by forcing the customer to choose to allow CPRM actions to be performed on their HOST. They must issue the passcode to unlock the feature block to allow CPRM HOST action to be performed. Apply this constraint against the "e00148rX" and make it a feature that can be disabled and locked out if desired, then you will see better acceptance. This will provide the MPAA people with a method of stopping CPRM content from going to a device that does not allow CPRM features to be enabled. Everybody wins. Finally, if CPRM proposal is removed from possible adoption, I will withdrawl this proposal due to lack of symbiotic requirements. Additionally if this can be ammended to "e00148rX", then a new document will not be needed. On Fri, 29 Dec 2000, Dale Smith wrote: > ** This is the quasi-official and semi-temporary T13 email list server. ** > > I agree with your issue's Hugh, and it makes it > tough on honorable people. > > The entertainment industry will find ways to release > their songs in a protected format for play on > personal players. T13 can take the high road, and Songs are long gone...this is more about protecting the SEWER content of Hollywood, in my humble opinion. They what the ablity to charge you on a per usage basis, regardless that you own and purchased the content at an earlier time. Let the Law enforcement divisions go after bootleggers. Locks only server to keep honest people honest! > make a stand for freedom and against copy protection > on the grounds that individuals should be trusted > until they prove themselves untrustworthy, or we can > go along with the entertainment industries methods > of forcing compliance with copyright rules by removing > the temptation. Wait until this is not limited to Hollywood content and it effects Commerice and Trade because of a bad host (or employee/hacker), encrypts critical data for the operations of Wall Street and beyond. The only positive note is that CPRM viruses are not spreadable. ;-) > This decision is likely to made by executive pocketbooks > as Hale pointed out earlier. Hale has always had the vision of what is right and wrong, and that is why I went full tilt to successfully stop/postpone this from being adopted at the last meeting in Irvine. If you look at the orginal unsanitized version of this proposal the e00148r0 (note totally rejected in October) verses the stripped down almost technical version of e00148r2, you get the real picture. Now if you guys want to get me off the topic, ypou make e00148r3/4 for the meeting in February at Dell contain this addition. New Command Pair: Set Features CPRM Lock. 0x4C and 0xAC (Yes I cleverly picked the pair to reflect their true nature) These commands SHALL be included in all devices that support/enable the CPRM "e00148rX", which is now defined as OPTIONAL. Regardless if the CPRM key locks are supported, CPRM Enable:Disable SHALL be supported. The Enable Feature command SHALL be set only by embedded HOST that do not have an External HOST to overide the feature. The Enable Feature command SHALL set a concatenated 32-bit passcode to hold the enable lock. INPUTS: Enable CPRM Mode Lock Feature 0x4C Sector Count.c3 Sector Number .c2 Cylinder Low.c1 Cylinder High .c0 Device Head obs|na|obs|DEV|na|na|na|na Command 0xEF Sector Count - Sector Number - Cylinder Low - Cylinder High - The .c3 .c2 .c1 .c0 SHALL
[PATCH] cs46xx deadlocks in non-blocking read
Without this patch, the cs46xx driver in 2.4-prelease (well, in
-test12, at least) will hang the machine as soon as someone tries to
read from it in non-blocking mode.
The cs_read() function already removes the wait queue on exit, so it's
basically a correctness fix.
I've already sent this to Nils/Thomas but since it hasn't materialized
in prerelease or ac1, and since it's quite small and needed for a
number of things to function correctly, I'm sending it again in the
hopes that it will get applied before 2.4 final.
Cheers
--- linux-2.4/drivers/sound/cs46xx.c~ Sun Dec 31 18:24:54 2000
+++ linux-2.4/drivers/sound/cs46xx.cMon Jan 1 14:03:19 2001
@@ -1971,7 +1971,6 @@
start_adc(state);
if (file->f_flags & O_NONBLOCK) {
if (!ret) ret = -EAGAIN;
- remove_wait_queue(>dmabuf.wait, );
break;
}
schedule();
--
David Huggins-Daines- [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: Happy new year^H^H^H^Hkernel..
Linus Torvalds wrote: > On 1 Jan 2001, Adam Sampson wrote: > > > > It appears to work (even with the reiserfs patch with the obvious > > Makefile tweak), but the drm modules have unresolved symbols: > > Does this fix it for you (do a "make clean" before re-building your tree)? > > Linus > > > --- v2.4.0-prerelease/linux/drivers/char/drm/Makefile Mon Jan 1 09:38:35 2001 > +++ linux/drivers/char/drm/Makefile Mon Jan 1 09:38:04 2001 > @@ -44,22 +44,22 @@ > mga-objs := mga_drv.o mga_dma.o mga_context.o mga_bufs.o mga_state.o > i810-objs := i810_drv.o i810_dma.oi810_context.o i810_bufs.o > > -obj-$(CONFIG_DRM_GAMMA) += gamma.o > -obj-$(CONFIG_DRM_TDFX) += tdfx.o > -obj-$(CONFIG_DRM_R128) += r128.o > -obj-$(CONFIG_DRM_FFB) += ffb.o > -obj-$(CONFIG_DRM_MGA) += mga.o > -obj-$(CONFIG_DRM_I810) += i810.o > - > - > # When linking into the kernel, link the library just once. > # If making modules, we include the library into each module > > ifdef MAKING_MODULES >lib = drmlib.a > else > - obj-y += drmlib.a > + extra-obj = drmlib.a > endif > + > +obj-$(CONFIG_DRM_GAMMA) += gamma.o $(extra-obj) > +obj-$(CONFIG_DRM_TDFX) += tdfx.o $(extra-obj) > +obj-$(CONFIG_DRM_R128) += r128.o $(extra-obj) > +obj-$(CONFIG_DRM_FFB) += ffb.o $(extra-obj) > +obj-$(CONFIG_DRM_MGA) += mga.o $(extra-obj) > +obj-$(CONFIG_DRM_I810) += i810.o $(extra-obj) > + > > include $(TOPDIR)/Rules.make Works like a charm here fix added drmlib.a with tdfx.o to /lib/modules/2.4.0-prerelease/kernel/drivers/char/drm - 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: Happy new year^H^H^H^Hkernel..
Linus Torvalds wrote: > Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some > last-minute stuff that needed fixing (ie the dirty page lists etc), and > the best I can do is make a prerelease. It's even better this way. Now we kick off the new millenium with a new kernel. :-) -- 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: Chipsets, DVD-RAM, and timeouts....
> > as it apparently makes CONFIG_IDEDMA_IVB a complete no-op? > > Exactly what it is designed to do, Ignore Validity Bits, because the whole > damn messedup the rules between ATA-4 and ATA-6 I think the question is more - so why not lose the ifdef - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0 test13-pre7 still causes CDROM ioctl errors
[Saw your reply on the web archive: I'm not subscribed to linux-kernel. Cc-ing the list for archive -- I've faked an In-Reply-To for correct threading]. A "cat /proc/sys/dev/cdrom/info" says (I have 2 CD-ROMs, but the one with ioctl() errors is the SCSI one) CD-ROM information, Id: cdrom.c 3.12 2000/10/18 drive name: sr0 hdb drive speed:1 1 drive # of slots: 1 1 Can close tray: 1 1 Can open tray: 1 1 Can lock tray: 1 1 Can change speed: 0 1 Can select disk:1 0 Can read multisession: 1 1 Can read MCN: 1 1 Reports media changed: 1 1 Can play audio: 1 1 Can write CD-R: 1 0 Can write CD-RW:1 0 Can read DVD: 1 0 Can write DVD-R:1 0 Can write DVD-RAM: 1 0 Apparently, it recognizes its audio-playing capabilities. However, this is NOT a CD writer, and I don't know why it's saying it can *write* CDs. This CD-ROM is: Host: scsi1 Channel: 00 Id: 02 Lun: 00 Vendor: PLEXTOR Model: CD-ROM PX-40TS Rev: 1.01 Type: CD-ROM ANSI SCSI revision: 02 As for sr_mod loading, I don't have any special flags specified (no options in /etc/modules.conf). But I did not have any either previously. The module "sr_mod" loads correctly: Module Size Used by sr_mod 12688 0 (autoclean) es1371 29104 0 (autoclean) ac97_codec 7728 0 (autoclean) [es1371] vmnet 17824 3 vmmon 19056 3 nls_cp437 4352 2 (autoclean) Note that this does not prevent correct playback from xmcd, i.e. the control interface to launch the playback works correctly, xmcd just complains about the ioctl() error. However, I'm also running VMWare (as you can see with the vmnet and vmmon modules), and it refuses to connect my SCSI CD-ROM device. It says: CDROM: "/dev/cdrom" exists but does not appear to be a CDROM device And /dev/cdrom is: /dev/cdrom -> /dev/scd0 Raphael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-prerelease shmget woes.
Hi, I just compiled and booted up 2.4.0-prerelease, dropped into X-Windows and now gtk/gnome apps are giving the following warning: Gdk-WARNING **: shmget failed! Any ideas on what changed in the shm space to cause this? This is a PII 333 RH 7.0 system 2.4.0-test10 worked just fine on this machine. /dev/shm is mounted: none 0 0 0 - /dev/shm The /usr/src/linux/Documentation/Changes file only mentions that this need be mounted. Tips, clues welcome. -- 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: Chipsets, DVD-RAM, and timeouts....
Because the people writing the SPEC screwed up.
The was a discussion to remove drive side detection and make it only host,
but since many chipset makers can not connect GPIO's for the 80 conductor
ribbonlet me walk you through the mess.
Bit 13 of word 93 is a capacitance decay test if the host and device
support the capactor.
Bit 14 of word 93 is now defined as always set to 1 if mode 3 or higher is
supported.
Since some slave devices do not drop the PDIAG line to allow the sense
bit 13 to correctly be detected on the master device, well you get the
mess.
Phoenix Technologies and I are discussing to recreation of an new
detection rules table and make it a sane one. I hope to have a draft
porposal for the February Meeting at Dell.
This issue is a complete mess in the committee.
The Drive guys do not want to have the liablity of reporting.
The Chipset guys do not always get it right.
Thus the Software guys get shafted with making the mess work.
On Mon, 1 Jan 2001, Linus Torvalds wrote:
>
>
> Andre, what's the idea behind the following change:
>
> --- linux-2.4.0-prerelease-pristine/drivers/ide/ide-features.c Mon Oct 16 12:21:40
>2000
> +++ linux-2.4.0-prerelease/drivers/ide/ide-features.c Sun Dec 31 21:53:17 2000
> @@ -224,7 +224,7 @@
> #ifndef CONFIG_IDEDMA_IVB
> if ((drive->id->hw_config & 0x6000) == 0) {
> #else /* !CONFIG_IDEDMA_IVB */
> - if (((drive->id->hw_config & 0x2000) == 0) ||
> + if (((drive->id->hw_config & 0x2000) == 0) &&
> ((drive->id->hw_config & 0x4000) == 0)) {
> #endif /* CONFIG_IDEDMA_IVB */
> printk("%s: Speed warnings UDMA 3/4/5 is not functional.\n",
>drive->name);
>
> as it apparently makes CONFIG_IDEDMA_IVB a complete no-op?
Exactly what it is designed to do, Ignore Validity Bits, because the whole
damn messedup the rules between ATA-4 and ATA-6
Cheers,
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: NFS-Root on AIX
> > NFS doesnt handle this elegantly for NFSv2 - are you using v2 or v3 ? > That's the question! What does the RedHat 7 support? ;-) 2.2.16-* will be NFSv2 This means the dev_t is passed uninterpreted between server and client. You may find you need to NFS mount the directory on a Linux box, mknod the device files over NFS and then let the diskless client use them - 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: NFS-Root on AIX
On Mon, 1 Jan 2001, Alan Cox wrote: > > Last we had to use an AIX-Server as NFS-Server for NFSRoot-Boot. > > > > It did not work, because the all Major-Device-Numbers in /dev/ are all > > set to 0. The minor numbers are transported correctly. > > NFS doesnt handle this elegantly for NFSv2 - are you using v2 or v3 ? That's the question! What does the RedHat 7 support? ;-) Where is the switching for v2 or v3 as nfs-client done? Kernel-Config CONFIG_NFS_V3 or mount-option nfsvers? Which version does the nfsroot-boot use? BYtE Oli +++LINUX++ +++Manchmal stehe ich sogar nachts auf und installiere mir eins+++ ++ - 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: Chipsets, DVD-RAM, and timeouts....
Andre, what's the idea behind the following change:
--- linux-2.4.0-prerelease-pristine/drivers/ide/ide-features.c Mon Oct 16 12:21:40
2000
+++ linux-2.4.0-prerelease/drivers/ide/ide-features.c Sun Dec 31 21:53:17 2000
@@ -224,7 +224,7 @@
#ifndef CONFIG_IDEDMA_IVB
if ((drive->id->hw_config & 0x6000) == 0) {
#else /* !CONFIG_IDEDMA_IVB */
- if (((drive->id->hw_config & 0x2000) == 0) ||
+ if (((drive->id->hw_config & 0x2000) == 0) &&
((drive->id->hw_config & 0x4000) == 0)) {
#endif /* CONFIG_IDEDMA_IVB */
printk("%s: Speed warnings UDMA 3/4/5 is not functional.\n",
drive->name);
as it apparently makes CONFIG_IDEDMA_IVB a complete no-op?
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: NFS-Root on AIX
> Last we had to use an AIX-Server as NFS-Server for NFSRoot-Boot. > > It did not work, because the all Major-Device-Numbers in /dev/ are all > set to 0. The minor numbers are transported correctly. NFS doesnt handle this elegantly for NFSv2 - are you using v2 or v3 ? - 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.0-pre compile err (pcxx)
> when i make bzimage with the pc/xx driver configured as a module, it
> compiles ok. configuring it as built-in gives the following error:
Im amazed it built as a module - thats why I missed the error
> pcxx.c:1826: `mseconds' undeclared (first use in this function)
> pcxx.c:1826: (Each undeclared identifier is reported only once
--- drivers/char/pcxx.c~Sat Dec 30 01:07:21 2000
+++ drivers/char/pcxx.c Mon Jan 1 17:12:05 2001
@@ -1823,7 +1823,7 @@
*/
static void pcxxdelay(int msec)
{
- mdelay(mseconds);
+ mdelay(msec);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4 kernel halting...
Hi, I'm having problems getting anything from 2.4.0-test12 onward to get past the IDE detectin phase of bootup, and not even 2.4.0-prerelease will work, either. At the bottom of this is the output of dmesg, on my current kernel (2.4.0-test11), with the spot where test12+ freezes indicated. btw...does anyone out there know how to capture output on a bad kernel; since the one I'm having trouble with never gets far enough for me to check for an oops with an externel program? You can locate the point where I get the freeze by the whole line of '*' to show where it locks up. Also, please forward any replies to my e-mail since I don't subscribe to linux-kernel due to excessive traffic on my end. Thanks, and below is dmesg output... Cut Here--- Linux version 2.4.0-test11-ac4 (root@ummagumma) (gcc version 2.95.3 19991030 (prerelease)) #1 Wed Dec 27 03:15:22 EST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0002 @ 000e (reserved) BIOS-e820: 07f0 @ 0010 (usable) BIOS-e820: 1000 @ fec0 (reserved) BIOS-e820: 1000 @ fee0 (reserved) BIOS-e820: 0002 @ fffe (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009fc00 for 4096 bytes. On node 0 totalpages: 32768 zone(0): 4096 pages. zone(1): 28672 pages. zone(2): 0 pages. mapped APIC to e000 (01223000) Kernel command line: BOOT_IMAGE=Linux ro root=302 adlib=0x388 ftape=1,fc10 ftape=9,irq ftape=0,dma ide0=autotune ide1=autotune idebus=66 lp=auto parport=0x378,7,3 pci=biosirq sb=0x220,5,1,7 video=matrox:disabled [000] ftape-setup.c (ftape_setup) - fc10=1. [001] ftape-setup.c (ftape_setup) - irq=9. [002] ftape-setup.c (ftape_setup) - dma=0. ide_setup: ide0=autotune ide_setup: ide1=autotune ide_setup: idebus=66 Initializing CPU#0 Detected 199.966 MHz processor. Console: colour VGA+ 132x60 Calibrating delay loop... 398.95 BogoMIPS Memory: 126276k/131072k available (1634k kernel code, 4408k reserved, 116k data, 204k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: Before vendor init, caps: 008001bf , vendor = 0 Intel Pentium with F0 0F bug - workaround enabled. CPU: After vendor init, caps: 008001bf CPU: After generic, caps: 008001bf CPU: Common caps: 008001bf CPU: Intel Pentium MMX stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xfdb11, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using BIOS Interrupt Routing Table PCI: Using BIOS for IRQ routing Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 DMI 2.0 present. 0 structures occupying 0 bytes. DMI table at 0x000F. Starting kswapd v1.8 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 1 0x378: readIntrThreshold is 1 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: ECP port cfgA=0x10 cfgB=0x4b 0x378: ECP settings irq=7 dma=3 parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA] parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) pty: 256 Unix98 ptys configured lp0: using parport0 (interrupt-driven). ftape v3.04d 25/11/97 for Linux 2.4.0-test11-ac4 [003] ftape-init.c (ftape_init) - installing QIC-117 floppy tape hardware drive ... . [004] ftape-init.c (ftape_init) - ftape_init @ 0xc02c3910. [005] ftape-buffer.c (add_one_buffer) - buffer nr #1 @ c12e04e0, dma area @ c0328000. [006] ftape-buffer.c (add_one_buffer) - buffer nr #2 @ c12e0560, dma area @ c009. [007] ftape-buffer.c (add_one_buffer) - buffer nr #3 @ c12e05e0, dma area @ c0008000. [008] ftape-calibr.c (time_inb) - inb() duration: 394 nsec. [009] ftape-calibr.c (ftape_calibrate) - TC for `ftape_udelay()' = 570 nsec (at 10239 counts). [010] ftape-calibr.c (ftape_calibrate) - TC for `fdc_wait()' = 1926 nsec (at 5119 counts). zftape for ftape v3.04d 25/11/97 for Linux 2.4.0-test11-ac4 [011] zftape-init.c (zft_init) - zft_init @ 0xc02c3cd0. [012] zftape-init.c (zft_init) - installing zftape VFS interface for ftape driver Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 66MHz system bus speed for PIO modes ALI15X3: IDE controller on PCI bus 00 dev 58 PCI: Assigned IRQ 14 for device 00:0b.0 ALI15X3: chipset revision 32 ALI15X3: not 100% native mode: will probe irqs later
[revisited] Oops on boot with 2.4.0testX and GCC snapshots
Hello together, after all the new year's celebrations, I have today taken the time to create a small patch, based on Linus' idea, that will fix this problem in the kernel, _without_ pessimizing any code or breaking with earlier compilers. 2.4.0-prerelease is now running here for an hour compiled completely with gcc-snapshot-2.97-20001222, without any noticed problems (so far). Perhaps this could be included in the kernel to enable people to look for the real caveats when compiling everything on the bleeding edge, or should we wait for the GCC maintainers' call - I haven't had any reaction on my bug report yet. Along with it is a small fix for a typo in fs/umsdos/mangle.c, which was detected by GCC's new preprocessor (#elseif instead of #else). Greetings and a happy new year to everyone, Andreas -- ->>>--- Andreas Franck <<<- ---<<< [EMAIL PROTECTED] --->>>--- ->>> Keep smiling! <<<- --- linux-2.4.0-prerelease/include/asm-i386/semaphore.h.original Mon Jan 1 16:25:31 2001 +++ linux-2.4.0-prerelease/include/asm-i386/semaphore.h Mon Jan 1 17:38:40 2001 @@ -23,6 +23,12 @@ * Optimized "0(ecx)" -> "(ecx)" (the assembler does not * do this). Changed calling sequences from push/jmp to * traditional call/ret. + * Modified 2001-01-01 Andreas Franck <[EMAIL PROTECTED]> + * Some hacks to ensure compatibility with recent + * GCC snapshots, to avoid stack corruption when compiling + * with -fomit-frame-pointer. It's not sure if this will + * be fixed in GCC, as our previous implementation was a + * bit dubious. * * If you would like to see an analysis of this implementation, please * ftp to gcom.com and download the file @@ -113,14 +119,14 @@ __asm__ __volatile__( "# atomic down operation\n\t" - LOCK "decl (%0)\n\t" /* --sem->count */ + LOCK "decl (%1)\n\t" /* --sem->count */ "js 2f\n" "1:\n" ".section .text.lock,\"ax\"\n" "2:\tcall __down_failed\n\t" "jmp 1b\n" ".previous" - :/* no outputs */ + :"=m" (sem->count) :"c" (sem) :"memory"); } @@ -135,7 +141,7 @@ __asm__ __volatile__( "# atomic interruptible down operation\n\t" - LOCK "decl (%1)\n\t" /* --sem->count */ + LOCK "decl (%2)\n\t" /* --sem->count */ "js 2f\n\t" "xorl %0,%0\n" "1:\n" @@ -143,7 +149,7 @@ "2:\tcall __down_failed_interruptible\n\t" "jmp 1b\n" ".previous" - :"=a" (result) + :"=a" (result), "=m" (sem->count) :"c" (sem) :"memory"); return result; @@ -159,7 +165,7 @@ __asm__ __volatile__( "# atomic interruptible down operation\n\t" - LOCK "decl (%1)\n\t" /* --sem->count */ + LOCK "decl (%2)\n\t" /* --sem->count */ "js 2f\n\t" "xorl %0,%0\n" "1:\n" @@ -167,7 +173,7 @@ "2:\tcall __down_failed_trylock\n\t" "jmp 1b\n" ".previous" - :"=a" (result) + :"=a" (result), "=m" (sem->count) :"c" (sem) :"memory"); return result; @@ -186,14 +192,14 @@ #endif __asm__ __volatile__( "# atomic up operation\n\t" - LOCK "incl (%0)\n\t" /* ++sem->count */ + LOCK "incl (%1)\n\t" /* ++sem->count */ "jle 2f\n" "1:\n" ".section .text.lock,\"ax\"\n" "2:\tcall __up_wakeup\n\t" "jmp 1b\n" ".previous" - :/* no outputs */ + :"=m" (sem->count) :"c" (sem) :"memory"); } @@ -322,7 +328,8 @@ "2:\tcall __rwsem_wake\n\t" "jmp 1b\n" ".previous" - ::"a" (sem) + :"=m" (sem->count) + :"a" (sem) :"memory" ); } @@ -341,7 +348,8 @@ "2:\tcall __rwsem_wake\n\t" "jmp 1b\n" ".previous" - ::"a" (sem) + :"=m" (sem->count) + :"a" (sem) :"memory" ); } --- linux-2.4.0-prerelease/fs/umsdos/mangle.c.original Mon Jan 1 18:15:42 2001 +++ linux-2.4.0-prerelease/fs/umsdos/mangle.c Mon Jan 1 18:15:59 2001 @@ -435,7 +435,7 @@ "HELLO", 1, "hello", "Hello.1", 1, "hello.1", "Hello.c", 1, "hello.c", -#elseif +#else /* * I find the three examples below very unfortunate. I propose to * convert them to lower case in a quick preliminary pass, then test
NFS-Root on AIX
HY HY Last we had to use an AIX-Server as NFS-Server for NFSRoot-Boot. It did not work, because the all Major-Device-Numbers in /dev/ are all set to 0. The minor numbers are transported correctly. A mount between two AIXes showed no Problems. I tried this with various OS-Levels of AIX 4.3.x.x. and 4.2.x.x Linux-Kernel was 2.2.16 on i686 and S/390 with various patches. BYtE Oli +++LINUX++ +++Manchmal stehe ich sogar nachts auf und installiere mir eins+++ ++ - 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] Remove compile warnings from 2.4.0-prerelease1-ac1
Here is a patch that removes warnings about depecrated use of
labels at the end of compound statements and warnings about
extra tokens at the end of #undef directives when using the
20001225 gcc snapshot. Could you please look this over for
possible inclusion in 2.4.0 or 2.4.0-prerelease1-ac2? Some
warnings I had with prerelease1 were fixed in ac1 so I did similar
fixes for the warnings I still had.
Thanks.
Rich
diff -urN linux/drivers/acpi/hardware/hwcpu32.c rb/drivers/acpi/hardware/hwcpu32.c
--- linux/drivers/acpi/hardware/hwcpu32.c Sun Dec 31 19:19:05 2000
+++ rb/drivers/acpi/hardware/hwcpu32.c Mon Jan 1 08:48:20 2001
@@ -708,4 +708,4 @@
return;
}
-
\ No newline at end of file
+
diff -urN linux/drivers/acpi/namespace/nsxfobj.c rb/drivers/acpi/namespace/nsxfobj.c
--- linux/drivers/acpi/namespace/nsxfobj.c Sun Dec 31 19:19:05 2000
+++ rb/drivers/acpi/namespace/nsxfobj.c Mon Jan 1 11:32:39 2001
@@ -694,4 +694,5 @@
acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
return (status);
-}
\ No newline at end of file
+}
+
diff -urN linux/drivers/scsi/sym53c8xx.c rb/drivers/scsi/sym53c8xx.c
--- linux/drivers/scsi/sym53c8xx.c Tue Sep 19 10:31:53 2000
+++ rb/drivers/scsi/sym53c8xx.c Mon Jan 1 11:30:30 2001
@@ -11862,7 +11862,7 @@
out_clrack:
OUTL (nc_dsp, NCB_SCRIPT_PHYS (np, clrack));
return;
-out_stuck:
+out_stuck:;
}
@@ -14830,10 +14830,10 @@
return retv;
}
-#undef SET_BIT 0
-#undef CLR_BIT 1
-#undef SET_CLK 2
-#undef CLR_CLK 3
+#undef SET_BIT /* 0 */
+#undef CLR_BIT /* 1 */
+#undef SET_CLK /* 2 */
+#undef CLR_CLK /* 3 */
/*
* Try reading Symbios NVRAM.
diff -urN linux/drivers/sound/mpu401.c rb/drivers/sound/mpu401.c
--- linux/drivers/sound/mpu401.cSat Nov 11 21:32:01 2000
+++ rb/drivers/sound/mpu401.c Mon Jan 1 11:28:48 2001
@@ -1449,7 +1449,7 @@
}
break;
- default:
+ default:;
}
return TIMER_NOT_ARMED;
}
@@ -1559,7 +1559,7 @@
setup_metronome(midi_dev);
return 0;
- default:
+ default:;
}
return -EINVAL;
}
diff -urN linux/drivers/sound/sb_ess.c rb/drivers/sound/sb_ess.c
--- linux/drivers/sound/sb_ess.cFri Aug 11 10:26:43 2000
+++ rb/drivers/sound/sb_ess.c Mon Jan 1 11:27:14 2001
@@ -770,7 +770,7 @@
case IMODE_INIT:
break;
- default:
+ default:;
/* printk(KERN_WARN "ESS: Unexpected interrupt\n"); */
}
}
diff -urN linux/drivers/sound/sequencer.c rb/drivers/sound/sequencer.c
--- linux/drivers/sound/sequencer.c Mon Sep 25 14:32:54 2000
+++ rb/drivers/sound/sequencer.cMon Jan 1 11:26:19 2001
@@ -511,7 +511,7 @@
synth_devs[dev]->aftertouch(dev, voice, parm);
break;
- default:
+ default:;
}
#undef dev
#undef cmd
@@ -614,7 +614,7 @@
synth_devs[dev]->bender(dev, chn, w14);
break;
- default:
+ default:;
}
}
@@ -684,7 +684,7 @@
}
break;
- default:
+ default:;
}
return TIMER_NOT_ARMED;
@@ -701,7 +701,7 @@
DMAbuf_start_devices(parm);
break;
- default:
+ default:;
}
}
@@ -859,7 +859,7 @@
seq_sysex_message(q);
break;
- default:
+ default:;
}
return 0;
}
diff -urN linux/drivers/sound/sound_timer.c rb/drivers/sound/sound_timer.c
--- linux/drivers/sound/sound_timer.c Sun Oct 1 22:35:16 2000
+++ rb/drivers/sound/sound_timer.c Mon Jan 1 11:26:42 2001
@@ -165,7 +165,7 @@
seq_copy_to_input(event, 8);
break;
- default:
+ default:;
}
return TIMER_NOT_ARMED;
}
diff -urN linux/fs/isofs/inode.c rb/fs/isofs/inode.c
--- linux/fs/isofs/inode.c Mon Jan 1 08:10:13 2001
+++ rb/fs/isofs/inode.c Mon Jan 1 11:32:09 2001
@@ -1264,7 +1264,7 @@
(volume_seq_no != 0) && (volume_seq_no != 1)) {
printk(KERN_WARNING "Multi-volume CD somehow got mounted.\n");
} else
-#endif IGNORE_WRONG_MULTI_VOLUME_SPECS
+#endif /*IGNORE_WRONG_MULTI_VOLUME_SPECS */
{
if (S_ISREG(inode->i_mode)) {
inode->i_fop = _ro_fops;
diff -urN linux/net/ipv4/arp.c rb/net/ipv4/arp.c
--- linux/net/ipv4/arp.cTue Oct 10 12:33:52 2000
+++ rb/net/ipv4/arp.c Mon Jan 1 11:31:30 2001
@@ -292,7 +292,7 @@
neigh->output = neigh->ops->output;
return 0;
#endif
- }
netfilter enum conflict?
Hi: include/linux/netfilter_ipv4.h and include/linux/netfilter_ipv6.h both define enum nf_ip_hook_priorities. This trips the compiler if both are included. Should one change to nf_ipv6_hook_priorities? Mark - 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: kNFSd maintenance in 2.2.19pre
On Thu, Dec 21, 2000 at 12:05:41PM +1100, Neil Brown wrote:
> So, I have started putting some patches together and they can be
> found at
> http://www.cse.unsw.edu.au/~neilb/patches/knfsd-2.2/
I included the interesting ones in my tree.
Here two fixes against the vfs backport:
--- ./fs/nfsd/vfs.c.~1~ Fri Dec 29 18:02:01 2000
+++ ./fs/nfsd/vfs.c Mon Jan 1 18:09:46 2001
@@ -1603,9 +1603,11 @@
eof = !cd.eob;
if (cd.offset) {
+#ifdef CONFIG_NFSD_V3
if (rqstp->rq_vers == 3)
(void)enc64(cd.offset, file.f_pos);
else
+#endif /* CONFIG_NFSD_V3 */
*cd.offset = htonl(file.f_pos);
}
@@ -1624,6 +1626,7 @@
return err;
out_nfserr:
+ up(>i_sem);
err = nfserrno(-err);
goto out_close;
}
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-pre compile err (pcxx)
when i make bzimage with the pc/xx driver configured as a module, it compiles ok. configuring it as built-in gives the following error: gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-prerelease/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o pcxx.o pcxx.c pcxx.c: In function `pcxxdelay': pcxx.c:1826: `mseconds' undeclared (first use in this function) pcxx.c:1826: (Each undeclared identifier is reported only once pcxx.c:1826: for each function it appears in.) make[3]: *** [pcxx.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: [usb-storage] Re: [patchlet] enable HP 8200e USB CDRW
> On Sun, 31 Dec 2000, Matthew Dharm wrote: > > >> Um, I'm not sure that this driver is even ready for the EXPERIMENTAL label. >> What does the driver's author say? I'd say it's ready for prime-time. So far the problems that have been described to me have to do with not being able to burn CD's because of too high a write speed. There is still an unresolved problem with disk-at-once writing, but nothing that prevents work from being done. --Rob - 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: Happy new year^H^H^H^Hkernel..
On 1 Jan 2001, Adam Sampson wrote: > > It appears to work (even with the reiserfs patch with the obvious > Makefile tweak), but the drm modules have unresolved symbols: Does this fix it for you (do a "make clean" before re-building your tree)? Linus --- v2.4.0-prerelease/linux/drivers/char/drm/Makefile Mon Jan 1 09:38:35 2001 +++ linux/drivers/char/drm/Makefile Mon Jan 1 09:38:04 2001 @@ -44,22 +44,22 @@ mga-objs := mga_drv.o mga_dma.o mga_context.o mga_bufs.o mga_state.o i810-objs := i810_drv.o i810_dma.oi810_context.o i810_bufs.o -obj-$(CONFIG_DRM_GAMMA) += gamma.o -obj-$(CONFIG_DRM_TDFX) += tdfx.o -obj-$(CONFIG_DRM_R128) += r128.o -obj-$(CONFIG_DRM_FFB) += ffb.o -obj-$(CONFIG_DRM_MGA) += mga.o -obj-$(CONFIG_DRM_I810) += i810.o - - # When linking into the kernel, link the library just once. # If making modules, we include the library into each module ifdef MAKING_MODULES lib = drmlib.a else - obj-y += drmlib.a + extra-obj = drmlib.a endif + +obj-$(CONFIG_DRM_GAMMA) += gamma.o $(extra-obj) +obj-$(CONFIG_DRM_TDFX) += tdfx.o $(extra-obj) +obj-$(CONFIG_DRM_R128) += r128.o $(extra-obj) +obj-$(CONFIG_DRM_FFB) += ffb.o $(extra-obj) +obj-$(CONFIG_DRM_MGA) += mga.o $(extra-obj) +obj-$(CONFIG_DRM_I810) += i810.o $(extra-obj) + include $(TOPDIR)/Rules.make - 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: Chipsets, DVD-RAM, and timeouts....
> for FAT etc when reading. Writing is a bit more difficult, as that > then turns out to generate a read before we can commit a dirty > block. IMO, this type of thing does not belong in the drivers -- > we should _never_ receive request for < hard block size. Unfortunately someone ripped the support out from 2.2 to do this, then didnt fix it. So right now 2.4 is useless to anyone with an M/O drive. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Chipsets, DVD-RAM, and timeouts....
On Mon, Jan 01 2001, Alan Cox wrote: > > mke2fs -b 2048 /dev/hdc > > You must format to 2048 size blocks. > > FAT style FS doesnt support 2K blocks 8) Then don't use FAT on DVD-RAM :-). ide-cd will already appropriately cache a single block and dish out 512b sectors from that as needed for FAT etc when reading. Writing is a bit more difficult, as that then turns out to generate a read before we can commit a dirty block. IMO, this type of thing does not belong in the drivers -- we should _never_ receive request for < hard block size. -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - 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: Chipsets, DVD-RAM, and timeouts....
> ./drivers/ide/ide-cd.c > ./drivers/ide/ide-cd.h > > Adds ATAPI DVD-RAM native read/write mode for any FS. Interesting to say the least. But.. > mke2fs -b 2048 /dev/hdc > You must format to 2048 size blocks. FAT style FS doesnt support 2K blocks 8) - 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: __bad_udelay fixes(?) for linux-2.4.0-prerelease
> (that is, 20 milliseconds). I guess the purpose of this change is > to tell driver maintainers to either take a harder look at whether they > really need to do a busy sleep for that long (you can still do it with It is primarily there because udelay() that long will fail. An mdelay is an acceptable substitution. mdelay knows the delays will be bigger so the time to do the math and a loop doesnt throw small delays > drivers/video/atyfb.c - An intentional 50ms delay. > drivers/video/clgenfb.c - An intentional 100ms delay. > I've changed both files to keep the > delays by using mdelay instead of udelay. > Perhaps somebody could check the > approaprirate documentation and test > on real hardware to determine if the > delays really need to be this long. Seems sane. For toshoboe in my tree I just switched it to mdelay() - 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.0-prerelease, AX25 problems
On Mon, 1 Jan 2001, f5ibh wrote: > I've just compiled and tested 2.4.0-prerelease. My AX25 (hamradio) system does > not work with this new release. There is a timing problem. When a fram is sent > on the air, the frame is VERY long (switched off by the watchdog of my drsi > card) and contains no data. On this point of vue, the previous test version was > right. Is the "previous test version" you talk about 2.4.0-test13-pre7? There weren't any changes since then that could explain this, except maybe: > Gnu C 2.95.2 The minimum required gcc for 2.4 is now 2.91.66. However, AFAIK 2.95.5 was considered suspect at one point. -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Chipsets, DVD-RAM, and timeouts....
On Mon, Jan 01 2001, Andre Hedrick wrote: > ide.2.4.0-prerelease.cd.1231.patch : > > ./drivers/ide/ide-cd.c > ./drivers/ide/ide-cd.h > > Adds ATAPI DVD-RAM native read/write mode for any FS. > mke2fs -b 2048 /dev/hdc > You must format to 2048 size blocks. Any >= 2KB block size will work, using -b 2048 is not necessary. > UDF is an unknown. Barring strange (new) UDF bugs, it will work. And it's the preferred way of using the DVD-RAM, both from a portability and media stability standpoint. -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Generic deferred file writing
On Mon, 1 Jan 2001, Roman Zippel wrote: > The other reason for the question is that I'm currently overwork the block > handling in affs, especially the extended block handling, where I'm > implementing a new extended block cache, where I would pretty much prefer > to use a semaphore to protect it. Although I could do it probably without > the semaphore and use a spinlock+rechecking, but it would keep it so much > simpler. (I can post more details about this part on fsdevel if needed / > wanted.) But... But with AFFS you _have_ exclusion between block-allocation and truncate(). It has no sparse files, so pageout will never allocate anything. I.e. all allocations come from write(2). And both write(2) and truncate(2) hold i_sem. Problem with AFFS is on the directory side of that business and there it's really scary. Block allocation is trivial... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-prerelease, AX25 problems
Hi and Happy New Year, I've just compiled and tested 2.4.0-prerelease. My AX25 (hamradio) system does not work with this new release. There is a timing problem. When a fram is sent on the air, the frame is VERY long (switched off by the watchdog of my drsi card) and contains no data. On this point of vue, the previous test version was right. My system : --- K6-2 500 / 128Mb Kernel modules 2.3.24 Gnu C 2.95.2 Binutils 2.9.5.0.41 Linux C Library2.1.3 Dynamic linker ldd: version 1.9.11 Procps 2.0.6 Mount 2.10o Net-tools 2.05 Console-tools 0.2.3 Sh-utils 2.0 Modules Loaded ppp slhc af_packet scc ax25 parport_probe parport_pc lp parport mousedev usb-ohci hid input autofs lockd sunrpc usbcore serial unix Ax25 related config : - # # Amateur Radio support # CONFIG_HAMRADIO=y # # Packet Radio protocols # CONFIG_AX25=m CONFIG_AX25_DAMA_SLAVE=y # CONFIG_NETROM is not set # CONFIG_ROSE is not set # # AX.25 network device drivers # # CONFIG_MKISS is not set # CONFIG_6PACK is not set # CONFIG_BPQETHER is not set # CONFIG_DMASCC is not set CONFIG_SCC=m # CONFIG_SCC_DELAY is not set # CONFIG_SCC_TRXECHO is not set CONFIG_BAYCOM_SER_FDX=m # CONFIG_BAYCOM_SER_HDX is not set # CONFIG_BAYCOM_PAR is not set # CONFIG_BAYCOM_EPP is not set # CONFIG_SOUNDMODEM is not set # CONFIG_YAM is not set - Regards Jean-Luc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: path MTU bug still there?
On Sun, 31 Dec 2000, Alan Cox wrote: > > How is this solved? Personally, I am behind a CIPE tunnel with an MTU of > > 1442 or something like that. I experienced problems to some places and > > You have to get the other end to fix it. > > > Could it be some kind of incompability at the tunnel level that make you > > unable to receive large packets over the tunnel? Have you tcpdump:ed to > > see if the tunnel packets actually make it the way they should? > > Its normally seriously incompetent firewall admins on remote sites. Most >large > ecommerce sites have these kind of basic errors. Makes you glad to trust your > credit card details to them doesnt it 8) In the past few days I encountered an MTU problem on the Internet - some incompetent admin seemed to have set a low MTU on their router *and* prevented "can't fragment" messages from being sent from it. The result was my SSH tunnel kept stalling when the route happened to use that particular router. I fixed the problem by lowering the MTU on my dial-up PPP connection. I have also had problems with stalling connections under other circumstances, but I don't think the kernel or MTU are responsible - yet! -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a19 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+ -END GEEK CODE BLOCK- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
IRNET depending on PPP
Hi, IRNET depends on PPP, but that is not reflected in the configuration files. A patch is attached. Regards Oliver --- linux-vanilla/net/irda/irnet/Config.in Mon Jan 1 14:34:02 2001 +++ linux/net/irda/irnet/Config.in Mon Jan 1 15:35:15 2001 @@ -1 +1,3 @@ -dep_tristate ' IrNET protocol' CONFIG_IRNET $CONFIG_IRDA +if [ "$CONFIG_PPP" != "n" ]; then + dep_tristate ' IrNET protocol' CONFIG_IRNET $CONFIG_IRDA +fi
2.4.0-prerel-ac1: Looking good on Alpha
Hi,
2.4.0-prerelease with the Alan Cox new-year-special ac1 patches is
looking good for me on Alpha (LX164).
My standard build went just fine; so I decided to push it; I've built in
IPv6, a load of USB stuff, SCSI stuff, and a load of other stuff; loaded
them all as modules, all loaded OK and unloaded OK - haven't actually
stressed any of it.
Just two (1 and a half?) problems:
1) When doing make modules_install:
depmod: *** Unresolved symbols in
/lib/modules/2.4.0-prerelease-ac1/kernel/drivers/usb/storage/usb-storage.o
depmod: init_task_union
2) When I tried to play an audio CD this morning I got:
Jan 1 12:55:48 tardis kernel: hdb: irq timeout: status=0xd0 { Busy }
Jan 1 12:55:54 tardis kernel: hdb: ATAPI reset complete
Jan 1 12:56:04 tardis kernel: hdb: irq timeout: status=0xc0 { Busy }
Jan 1 12:56:10 tardis kernel: hdb: ATAPI reset complete
Jan 1 12:56:20 tardis kernel: hdb: irq timeout: status=0xc0 { Busy }
Jan 1 12:56:20 tardis kernel: end_request: I/O error, dev 03:40 (hdb),
sector 0
Jan 1 12:56:20 tardis kernel: hdb: status timeout: status=0xc0 { Busy }
Jan 1 12:56:20 tardis kernel: hdb: drive not ready for command
Jan 1 12:56:27 tardis kernel: hdb: ATAPI reset complete
Ejected the CD, put it back in and its fine, so I actually suspect the
drive was just having a bad day but its best just to list there was the
problem. (This on a CMD646 on the motherboard).
Dave
--
Have a happy GNU millennium! --
/ Dr. David Alan Gilbert | Running GNU/Linux on | Happy \
\ gro.gilbert @ treblig.org | Alpha, x86, ARM and SPARC | In Hex /
\ ___|___ http://www.treblig.org |/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
