vger.timpanogas.org is upgraded and back up
Thanks for the patience. vger.timpanogas.org is back up. The upgrade took a little longer than expected. We apologize for any inconveniance. 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/
Re: patch: atapi dvd-ram support
Thanks again.
> > > Ok, does /proc/sys/dev/cdrom/info list DVD-RAM as a capability?
> > CD-ROM information, Id: cdrom.c 3.12 2000/10/22
> >
> > Can write DVD-RAM: 1
>
> So far, so good.
:-)
> > Should I set any flags to permit write a DVD-RAM media ?
>
> No, as I said it should detect it automatically. But d'oh, I
> just realised that it is set too soon... Sorry, try with this
> patch.
Thank you for your quick response.
I tried the patch.
But kernel said Oops both fdisk /dev/hdc and
dd if=/dev/zero of=/dev/hdc bs=2048 count=1 .
strace dd if=/dev/zero of=/dev/hdc bs=2048 count=1 shows
-
[root@celto shibata]# strace dd if=/dev/zero of=/dev/hdc bs=2048 count=1
execve("/bin/dd", ["dd", "if=/dev/zero", "of=/dev/hdc", "bs=2048", "count=1"], [/* 19
vars */]) = 0
brk(0) = 0x80504a8
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40013000
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=19214, ...}) = 0
old_mmap(NULL, 19214, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0755, st_size=5224080, ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0(\215\1"..., 4096) = 4096
old_mmap(NULL, 941692, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40019000
mprotect(0x400f7000, 32380, PROT_NONE) = 0
old_mmap(0x400f7000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xdd000) =
0x400f7000
old_mmap(0x400fc000, 11900, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x400fc000
close(3)= 0
munmap(0x40014000, 19214) = 0
personality(PER_LINUX) = 0
getpid()= 709
brk(0) = 0x80504a8
brk(0x80504e0) = 0x80504e0
brk(0x8051000) = 0x8051000
close(0)= 0
open("/dev/zero", O_RDONLY|O_LARGEFILE) = 0
close(1)= 0
open("/dev/hdc", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 ENOSYS (Function not
implemented)
open("/dev/hdc", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 ENOSYS (Function not
implemented)
open("/dev/hdc", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1
rt_sigaction(SIGINT, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {0x804adec, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {0x804adec, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGPIPE, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGPIPE, {0x804adec, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGUSR1, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGUSR1, {0x804aeac, [], 0x400}, NULL, 8) = 0
brk(0x8054000) = 0x8054000
read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048
write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048
write(2, "1+0 records in\n", 151+0 records in
)= 15
write(2, "1+0 records out\n", 161+0 records out
) = 16
close(0)= 0
close(1
-
After showing above strace message in a few seconds, kernel panic happened.
I can not see some head line of Oops messages. Sorry.
Please let me test more patches. I will keep up with you.
Best Regards,
--
W [EMAIL PROTECTED]
|O-O| Hisaaki Shibata
0(mmm)0 P-mail: 070-5419-3233IRC: #luky
~http://his.luky.org/ last update:2000.3.12
-
To unsubscribe from this list: send 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: atapi dvd-ram support
On Sun, Oct 29 2000, Hisaaki Shibata wrote:
> > Ok, does /proc/sys/dev/cdrom/info list DVD-RAM as a capability?
>
> Yes.
> I think it seems good.
>
> # more info
> CD-ROM information, Id: cdrom.c 3.12 2000/10/22
>
> Can write DVD-RAM: 1
So far, so good.
> Should I set any flags to permit write a DVD-RAM media ?
No, as I said it should detect it automatically. But d'oh, I
just realised that it is set too soon... Sorry, try with this
patch.
--
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
--- drivers/block/ide-cd.c~ Sat Oct 28 20:09:03 2000
+++ drivers/block/ide-cd.c Sat Oct 28 20:09:23 2000
@@ -2597,8 +2597,6 @@
int minor = drive->select.b.unit << PARTN_BITS;
int nslots, ro;
- ro = !CDROM_CONFIG_FLAGS(drive)->dvd_ram;
- set_device_ro(MKDEV(HWIF(drive)->major, minor), ro);
set_blocksize(MKDEV(HWIF(drive)->major, minor), CD_FRAMESIZE);
drive->special.all = 0;
@@ -2718,6 +2716,9 @@
info->start_seek= 0;
nslots = ide_cdrom_probe_capabilities (drive);
+
+ ro = !CDROM_CONFIG_FLAGS(drive)->dvd_ram;
+ set_device_ro(MKDEV(HWIF(drive)->major, minor), ro);
if (ide_cdrom_register (drive, nslots)) {
printk ("%s: ide_cdrom_setup failed to register device with the cdrom
driver.\n", drive->name);
Re: patch: atapi dvd-ram support
Thank you, again. > On Sat, Oct 28 2000, Hisaaki Shibata wrote: > > > > But I could not mkudf nor mkext2fs to my ATAPI 9.4GB new DVD-RAM drive. > > > > > > What do you mean? What happened? strace of mke2fs of mkudf would > > > be nice to have. > > > > My system said it is not permited because it is read only. > > [snip] > > Ok, does /proc/sys/dev/cdrom/info list DVD-RAM as a capability? Yes. I think it seems good. # more info CD-ROM information, Id: cdrom.c 3.12 2000/10/22 drive name: hdc drive speed:0 drive # of slots: 1 Can close tray: 1 Can open tray: 1 Can lock tray: 1 Can change speed: 1 Can select disk:0 Can read multisession: 1 Can read MCN: 1 Reports media changed: 1 Can play audio: 1 Can write CD-R: 0 Can write CD-RW:0 Can read DVD: 1 Can write DVD-R:0 Can write DVD-RAM: 1 > > And /proc/ide/hdc/media says "cdrom". Is it OK? > > Yes, that is fine. OK. Should I set any flags to permit write a DVD-RAM media ? Best Regards, -- W [EMAIL PROTECTED] |O-O| Hisaaki Shibata 0(mmm)0 P-mail: 070-5419-3233IRC: #luky ~http://his.luky.org/ last update:2000.3.12 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] 2.4.0-test10-pre6 fix usb initialization order
This patch against 2.4.0-test10-pre6 implements LINK_FIRST and LINK_LAST to fix the problem with usb initialization order. The patch *only* affects drivers/usb because that is the only Makefile that specifies LINK_FIRST. All the other Makefiles still rely on the kludge where the link order is implicit in the order that objects are declared. USB is a special case[*] and the kludge is no longer enough, it really does need LINK_FIRST. Comments before it goes to Linus? [*]http://www.uwsg.indiana.edu/hypermail/linux/kernel/0010.3/0661.html Do not change any other Makefiles to use LINK_FIRST/LAST unless you can guarantee that you know and have take care of all the side effects of changing link order. Given the lack of documentation on link order in most Makefiles, that means leave link order alone until 2.5 unless there is absolutely no other way of fixing the problem. Index: 0-test10-pre6.1/drivers/usb/Makefile --- 0-test10-pre6.1/drivers/usb/Makefile Tue, 24 Oct 2000 14:20:12 +1100 kaos (linux-2.4/n/b/19_Makefile 1.1.1.11 644) +++ 0-test10-pre6.1(w)/drivers/usb/Makefile Sun, 29 Oct 2000 12:38:11 +1100 kaos +(linux-2.4/n/b/19_Makefile 1.1.1.11 644) @@ -18,6 +18,18 @@ O_OBJS := export-objs:= usb.o +# usb.o contains usb_init which is marked as __initcall (actually +# module_init). usb_init must be executed before all other usb __initcall +# routines, otherwise the individual drivers will be initialized before the +# hub driver is, causing the hub driver initialization sequence to +# needlessly probe every USB driver with the root hub device. This causes +# a lot of unnecessary system log messages, a lot of user confusion, and +# has been known to cause a incorrectly programmed USB device driver to +# grab the root hub device improperly. +# Greg Kroah-Hartman, 27 Oct 2000 + +LINK_FIRST := usb.o + # Multipart objects. list-multi := usbcore.o @@ -98,6 +110,10 @@ int-m := $(sort $(foreach m, $(multi-m) obj-m := $(filter-out $(obj-y), $(obj-m)) int-m := $(filter-out $(int-y), $(int-m)) + +# Take multi-part drivers out of obj-y and put components in. + +obj-y := $(filter-out $(list-multi), $(obj-y)) $(int-y) # Translate to Rules.make lists. Index: 0-test10-pre6.1/Rules.make --- 0-test10-pre6.1/Rules.make Tue, 19 Sep 2000 10:36:07 +1100 kaos (linux-2.4/B/c/24_Rules.make 1.2.1.4 644) +++ 0-test10-pre6.1(w)/Rules.make Sun, 29 Oct 2000 12:04:05 +1100 kaos +(linux-2.4/B/c/24_Rules.make 1.2.1.4 644) @@ -31,6 +31,9 @@ unexport LX_OBJS unexport MX_OBJS unexport MIX_OBJS unexport SYMTAB_OBJS +# Control link order, added 29 Oct 200 Keith Owens <[EMAIL PROTECTED]> +unexport LINK_FIRST +unexport LINK_LAST # # Get things started. @@ -84,8 +87,19 @@ all_targets: $(O_TARGET) $(L_TARGET) # # Rule to compile a set of .o files into one .o file # +# Note: if LINK_FIRST or LINK_LAST are specified, the rest of the +# object files are sorted to remove duplicates. Thus, if you use +# LINK_FIRST/LAST, make sure they specify all ordering requirements. +# ifdef O_TARGET -ALL_O = $(OX_OBJS) $(O_OBJS) + ALL_O = $(OX_OBJS) $(O_OBJS) + ifneq ($(strip $(LINK_FIRST)$(LINK_LAST)),) +ALL_O := $(sort $(ALL_O)) +ALL_O := \ + $(filter $(ALL_O), $(LINK_FIRST)) \ + $(filter-out $(LINK_FIRST) $(LINK_LAST), $(ALL_O)) \ + $(filter $(ALL_O), $(LINK_LAST)) + endif $(O_TARGET): $(ALL_O) rm -f $@ ifneq "$(strip $(ALL_O))" "" Index: 0-test10-pre6.1/Documentation/kbuild/makefiles.txt --- 0-test10-pre6.1/Documentation/kbuild/makefiles.txt Mon, 02 Oct 2000 15:28:44 +1100 kaos (linux-2.4/b/d/12_makefiles. 1.3 644) +++ 0-test10-pre6.1(w)/Documentation/kbuild/makefiles.txt Sun, 29 Oct 2000 13:39:06 ++1100 kaos (linux-2.4/b/d/12_makefiles. 1.3 644) @@ -1,6 +1,8 @@ Linux Kernel Makefiles 2000-September-14 Michael Elizabeth Chastain, <[EMAIL PROTECTED]> +2000-October-29 +LINK_FIRST/LAST Keith Owens <[EMAIL PROTECTED]> @@ -656,7 +658,12 @@ The public interface of Rules.make consi with the name $(O_TARGET). This $(O_TARGET) name also appears in the top Makefile. - The order of files in $(O_OBJS) and $(OX_OBJS) is significant. + Even if a subdirectory Makefile has an $(O_TARGET), the .config + options still control whether or not its $(O_TARGET) goes into + vmlinux. See the $(M_OBJS) example below. + + If neither of LINK_FIRST nor LINK_LAST are defined then the + order of files in $(O_OBJS) and $(OX_OBJS) is significant. All $(OX_OBJS) files come first, in the order listed, followed by all $(O_OBJS) files, in the order listed. Duplicates in the lists are allowed: the first instance will be linked into $(O_TARGET) @@ -680,9 +687,53 @@ The public interface of Rules.make consi O_OBJS += pci.o pci_iommu.o endif - Even if a subdirectory Makefile has an $(O_TARGET), the .config -
Re: test10-6: can't mount root partition
On Sat, Oct 28, 2000 at 10:03:00PM -0400 Frank Davis wrote: > I compiled 2.4.0-test10-6 finemodules and all, and for some reason I > can't mount my root partition on boot..I get a VFS kernel panic. > # > # Automatically generated make config: don't edit > # [..] > # > # ATA/IDE/MFM/RLL support > # > CONFIG_IDE=m > > # > # IDE, ATA and ATAPI Block devices > # > CONFIG_BLK_DEV_IDE=m How about compiling these into the Kernel so that it realy can find it's modules? Stefan -- friendly greetings from Chelmsford/Britain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test10-6: can't mount root partition
Hello, I compiled 2.4.0-test10-6 finemodules and all, and for some reason I can't mount my root partition on boot..I get a VFS kernel panic. I thought it might have something to do with devfs, but I disabled it, and it still doesn't work. I'm using loadlin 1.6a..I haven't tried a boot disk yet. I have attached my .config and output from the ver_linux script (kernel 2.3.36 boots fine from loadlin). The machine is a Dell Latitude CPi laptop, 64MB. -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux localhost.localdomain 2.3.36 #55 SMP Tue Jan 4 20:53:13 EST 2000 i686 unknown Kernel modules 2.3.19 Gnu C egcs-2.91.66 Gnu Make 3.77 Binutils 2.9.1.0.23 Linux C Library2.1.1 Dynamic linker ldd (GNU libc) 2.1.1 Procps 2.0.2 Mount 2.9o Net-tools 1.51 Console-tools 1999.03.02 Sh-utils 1.16 Modules Loaded nfsd # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_M686FXSR is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # CONFIG_NOHIGHMEM is not set # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y CONFIG_HIGHMEM=y CONFIG_X86_PAE=y CONFIG_MATH_EMULATION=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=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_NAMES=y # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=m CONFIG_CARDBUS=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # CONFIG_MTD=m # CONFIG_MTD_DOC1000 is not set # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOCPROBE is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_PMC551 is not set # CONFIG_MTD_MTDRAM is not set # # MTD drivers for mapped chips # CONFIG_MTD_CFI=m CONFIG_MTD_CFI_INTELEXT=m # CONFIG_MTD_CFI_AMDSTD is not set # CONFIG_MTD_JEDEC is not set # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set CONFIG_MTD_PHYSMAP=m CONFIG_MTD_PHYSMAP_START=800 CONFIG_MTD_PHYSMAP_LEN=400 # # Drivers for chip mappings # # CONFIG_MTD_MIXMEM is not set CONFIG_MTD_NORA=m # CONFIG_MTD_OCTAGON is not set # CONFIG_MTD_PNC2000 is not set # CONFIG_MTD_RPXLITE is not set # CONFIG_MTD_VMAX is not set # # User modules and translation layers for MTD devices # CONFIG_MTD_CHAR=m CONFIG_MTD_BLOCK=m CONFIG_FTL=m CONFIG_NFTL=m CONFIG_NFTL_RW=y # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=m CONFIG_ISAPNP=m # # Block devices # CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_XD=m CONFIG_PARIDE=m CONFIG_PARIDE_PARPORT=m # # Parallel IDE high-level drivers # CONFIG_PARIDE_PD=m CONFIG_PARIDE_PCD=m CONFIG_PARIDE_PF=m CONFIG_PARIDE_PT=m CONFIG_PARIDE_PG=m # # Parallel IDE protocol modules # # CONFIG_PARIDE_ATEN is not set # CONFIG_PARIDE_BPCK is not set # CONFIG_PARIDE_COMM is not set # CONFIG_PARIDE_DSTR is not set # CONFIG_PARIDE_FIT2 is not set # CONFIG_PARIDE_FIT3 is not set # CONFIG_PARIDE_EPAT is not set # CONFIG_PARIDE_EPIA is not set # CONFIG_PARIDE_FRIQ is not set # CONFIG_PARIDE_FRPW is not set # CONFIG_PARIDE_KBIC is not set # CONFIG_PARIDE_KTTI is not set # CONFIG_PARIDE_ON20 is not set # CONFIG_PARIDE_ON26 is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 #
Re: [ANNOUNCE] ide-patch for 2.2.18(pre)
Bartlomiej Zolnierkiewicz wrote: > > I have ported ide-patch to 2.2.18-17 and I'm now backporting > 2.4.0 changes. New VIA, SLC, OSB4 drivers and MANY other things > are already there.I hope that final 2.2.18-ide-patch will have > IDE functionality equal to this in 2.4.0-test10... > > Here is a snapshot (it's not thoroughly audited and tested): > http://republika.pl/bkz/ide.2.2.18-17.all.20001027.patch.bz2 > > And please cut that bullshit about ide-patch 2.2.x being unmantained. > I don't use 2.2.x kernels anymore so I don't do ide-patches for pre > kernels. But there will be patches for stable 2.2.x. (Although it's > a real pain - I hate doing backporting instead of new stuff). Can you say something about how well it patches (and behaves) with the corresponding RAID patch, e.g. http://www.kernel.org/pub/linux/kernel/people/mingo/raid-patches/raid-2.2.18-A2 -- Eyal Lebedinsky ([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/
oops with 2.4.0-test9, testing a module
Hi all, I am testing out a modem driver module that works fine on 2.2.14 and 2.2.16. On 2.4.0-test9 I can insmod it with no problem. When I open up minicom to test out some AT commands I get the kernel oops below right away, and the system hangs. System info: Kernel 2.4.0-test9, gcc version egcs-2.91.66 19990314 Pentium III 450, 128 MB RAM 2 IDE Hard drives Modem is a 56K speakerphone I rebooted and loaded the module again, then ran ksymoops. I am assuming the errors and warnings have something to do with the fact that I had to reboot, but the code looks fine out of ksymoops. If any other info is needed please ask. Here it is: ksymoops 2.3.4 on i686 2.4.0-test9. Options used -v vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /storage/_TS_OSless/Target/Modem/HCF_SPKPHL74/Linux/Serial/hcfspkph.o (specified) -m System.map (specified) Error (expand_objects): cannot stat(Sless/Target/Modem/HCF_SPKPHL74/Linux/Serial/hcfspkph.o) for hcfspkph Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(__usb_get_extra_descriptor) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_alloc_bus) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_alloc_dev) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_alloc_urb) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_bulk_msg) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_check_bandwidth) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_claim_bandwidth) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_clear_halt) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_connect) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_control_msg) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_deregister) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_deregister_bus) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_disconnect) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_driver_claim_interface) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_driver_release_interface) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_epnum_to_ep_desc) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_free_bus) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_free_dev) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_free_urb) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_get_class_descriptor) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_get_configuration) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_get_current_frame_number) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_get_descriptor) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_get_device_descriptor) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_get_protocol) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_get_report) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_get_string) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_ifnum_to_if) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_inc_dev_use) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_interface_claimed) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(usb_new_device) not found in vmlinux.
Re: [patch] kernel/module.c (plus gratuitous rant)
On Sat, Oct 28, 2000 at 01:15:58PM +0200, Dominik Kubla wrote: > Even simpler: "gcc -V 2.7.2.3" or "gcc -V 2.95.2" or whatever... Which was a nice idea, but it doesn't actually work. Changes in spec file format between versions makes this fall over. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] ide-patch for 2.2.18(pre)
On Sat, 28 Oct 2000, Bartlomiej Zolnierkiewicz wrote: >... > I don't use 2.2.x kernels anymore so I don't do ide-patches for pre > kernels. But there will be patches for stable 2.2.x. (Although it's > a real pain - I hate doing backporting instead of new stuff). I have modified your patch to apply cleanly against 2.2.18pre18. You can find this patch at http://www.fs.tum.de/~bunk/ide.2.2.18pre18.adrian.patch.bz2 cu, Adrian -- A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
panther ethernet and SCSI
Recently I got a "Professional Workstation" - a 486DX33 with 82596 on board ethernet and NCR(?) on board SCSI. It was not very difficult to get the 82596 to work (I put something that works on ftp.XX.kernel.org/pub/linux/kernel/people/aeb/lp486e.c comments are welcome) The 82596 itself is well-documented in Intel's 29021806.pdf but I have almost no information on the use of the I/O ports and do not know a good way to find the ethernet address. But there is also SCSI on this board - at boot time it prints Ballard Synergy CAMcore(R), Copyright 1991, 1.602 LP486E NCR SDMS if and only if SCSI is enabled in the BIOS setup. Does anybody have an idea how to make this do something? Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
[EMAIL PROTECTED] (Stephen Harris) said: > A lot of talk here has been about syslog and DNS blocking, but the > original message mentioned: > > > If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3, > > kernel 2.2.x), within a few minutes you will find your entire machine > > grinds to a halt. For example, nobody can log in. Great! Yet another way in which root can get the rope to shoot herself in the foot. Anything _really_ new? -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send 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: kqueue microbenchmark resul
> >In fact, if you did leave the read queued in a daemon using select() > >before, you'd keep looping endlessly taking all CPU and never idle > >because there would always be read data available. That would be a programming error on the part of the application. Any application using a level-triggered interface like select or poll must of course mask off events it is not interested in, to avoid getting them endlessly. That's just 'select 101'. > Also, level triggered notifications would also seem to cause > multiple thread wakeups and thundering herd problems when > there are multiple worker threads reading from the same queue. > > How does (?) kevent avoid this from happening? Easy - applications which have multiple threads reading from the same queue would use oneshot events instead of level-triggered events. Level-triggered events are only for applications where a single thread is reading from the queue. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kernel BUG at fs.c:567
kernel 2.4.0-test10-pre6, but this has been here as long as I can
remember.
starting wine triggers the bug, C: points to /win2k which is an NTFS
filesystem.
The offending code..
/* It's fscking broken. */
static int ntfs_get_block(struct inode *inode, long block, struct buffer_head *bh, int
create)
{
BUG();
return -1;
}
Heh. is there something else can be done there instead of just taking a crap
on itself? I can no longer read anything from /proc after this happens.
Oct 28 18:27:54 intolerance kernel: kernel BUG at fs.c:567!
Oct 28 18:27:54 intolerance kernel: invalid operand:
Oct 28 18:27:54 intolerance kernel: CPU:0
Oct 28 18:27:54 intolerance kernel: EIP:0010:[ntfs_get_block+20/32]
Oct 28 18:27:54 intolerance kernel: EFLAGS: 00210282
Oct 28 18:27:54 intolerance kernel: eax: 0018 ebx: cc95e2c0 ecx: c6bc2000
edx: cf974520
Oct 28 18:27:54 intolerance kernel: esi: edi: 000b ebp: 0800
esp: c6bc3dfc
Oct 28 18:27:54 intolerance kernel: ds: 0018 es: 0018 ss: 0018
Oct 28 18:27:54 intolerance kernel: Process wine (pid: 1502, stackpage=c6bc3000)
Oct 28 18:27:54 intolerance kernel: Stack: c0215e52 c0216278 0237 c012f904
c70f7340 cc95e2c0
Oct 28 18:27:54 intolerance kernel: c11c6170 c70f73dc
cc95e2c0
Oct 28 18:27:54 intolerance kernel:02a4 c70f7340 c0122263
c11c6170 c11c6170 c1480eb4
Oct 28 18:27:54 intolerance kernel: Call Trace: [tvecs+44350/74220]
[tvecs+45412/74220] [block_read_full_page+236/488] [add_to_p age_cache_unique+267/280]
[ntfs_readpage+15/20] [ntfs_get_block+0/32] [read_cluster_nonblocking+258/324]
Oct 28 18:27:54 intolerance kernel:[filemap_nopage+304/776]
[filemap_nopage+0/776] [do_no_page+80/176] [handle_mm_fault+ 231/340]
[do_page_fault+315/992] [do_page_fault+0/992] [old_mmap+192/240] [old_mmap+224/240]
Oct 28 18:27:54 intolerance kernel:[error_code+52/60]
Oct 28 18:27:54 intolerance kernel: Code: 0f 0b 83 c4 0c b8 ff ff ff ff c3 90 8b 44 24
08 68 90 fb 14
Please CC: responses, I'm not subscribed to the list.
--
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS in nfsd, affects all 2.2 and 2.4 kernels
> This problem that you are addressing is caused when solaris sends a > zero length write (I assume to implement the "access" system call, but > I haven't checked). more likely a long standing bug in Solaris that hasn't been stomped. Tony, you might let Sun know that you have a way to reproduce it at will, though there are Sun people on this alias who I'm sure will make it a high priority to stomp this one. :-) -mre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
vger.timpanogas.org down for hardware/2.2.18 upgrade
vger.timpanogas.org will be down for about 1 hour to upgrade to 2.2.18 and to add more mirroed storage for ISO image space. ftpshut has been set for 30 minutes, then the server will be down for about an hour. we apologize for any inconveniance and will have the system back up in about 1 hour. Thanks 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/
Re: [Fwd: No IRQ known for interrupt pin A of device 00:0f.0]
Remi Turk wrote: > > Ok, the problem is that you have an interrupt router table for your Ali > > 1533, but no interrupt router entry for your IDE device. That's why > > pci_enable_device is failing. > > > > Would you mind testing two kernel patches for me? Both of these changes > > should be attempted separately in 2.4.0-test10-pre6, and -without- > > Andre's change. > > > > The first change attempts to build an interrupt router entry for you, if > > none is available. I am most interested if this works. > > > > The second change simply ignores any pci_enable_device error returns, > > and assumes that the IDE subsystem will pick up the pieces. > > > > Remember, do not apply both of these changes at the same time... > > > > Thanks, > > > > Jeff > > The second patch (the one ignoring errors) doesn't seem to change > anything (except not giving the warning IIRC) > Also, dump_pirq and lspci -vv output didn't change. > > The first says the following at boot: > > PCI: PCI BIOS revision 2.10 entry at 0xf0560, last bus=1 > PCI: Using configuration type 1 > PCI: Probing PCI hardware > Unknown bridge resource 0: assuming transparent > PCI: Using IRQ router ALI [10b9/1533] at 00:07.0 > PCI: Found IRQ 14 for device 00:0f.0 > > dump_pirq output remains the same. > The lspci -vv output does change with the second patch: > > 00:0f.0 IDE interface: Acer Laboratories Inc. M5229 (rev c1) (prog-if > fa) > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 2 min, 4 max, 32 set > - Interrupt: pin A routed to IRQ 0 > + Interrupt: pin A routed to IRQ 14 > Region 4: I/O ports at d000 > > More info on request. > Hm, while running with the first patch (the one trying to build an interrupt router table for my chipset) my system locked solid for a few seconds while I was copying the kernel-source to another place and moved from one virtual screen to another in X. It happened just once, but I don't remember the last time I had this kind of latency. At the same time I noticed this in my kernel logs: localhost kernel: cdrom: open failed. I haven't done anything with my cdrom since the last reboot. localhost modprobe: modprobe: Can't locate module block-major-33 localhost modprobe: modprobe: Can't locate module block-major-33 localhost modprobe: modprobe: Can't locate module block-major-34 localhost modprobe: modprobe: Can't locate module block-major-34 localhost modprobe: modprobe: Can't locate module block-major-8 localhost last message repeated 15 times I only have hd[a-c] (timestamps removed to prevent irritating wrapping, they were all in the same minute) My dmesg is attached, just in case. -- Linux 2.4.0-test10-pre6-test1 #1 Sat Oct 28 23:04:32 CEST 2000 Linux version 2.4.0-test10-pre6-test1 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Sat Oct 28 23:04:32 CEST 2000 BIOS-provided physical RAM map: BIOS-e820: 000a @ (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0fefc000 @ 0010 (usable) BIOS-e820: 3000 @ 0fffc000 (ACPI data) BIOS-e820: 1000 @ 0000 (ACPI NVS) BIOS-e820: 0001 @ (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 c000 for 4096 bytes. On node 0 totalpages: 65532 zone(0): 4096 pages. zone(1): 61436 pages. zone(2): 0 pages. mapped APIC to e000 (01444000) Kernel command line: Initializing CPU#0 Detected 350.802 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 699.60 BogoMIPS Memory: 255780k/262128k available (1099k kernel code, 5964k reserved, 85k data, 184k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) VFS: Diskquotas version dquot_6.4.0 initialized CPU: L1 I Cache: 32K L1 D Cache: 32K (32 bytes/line) CPU: AMD-K6(tm) 3D processor stepping 00 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xf0560, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router ALI [10b9/1533] at 00:07.0 PCI: Found IRQ 14 for device 00:0f.0 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.13) Starting kswapd v1.8 Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus
Re: Linux 2.2.18pre18
On Sat, 28 Oct 2000, Alan Cox wrote: > Treat this one with care. The LRU corruption fix is one of those 'clearly > right but makes a mess if its not so clear as it seems' kind of fixes. > > Alan And one kitchen sink...sheesh Have you reconsidered the suspended backort of ATA by me that Bart is keeping up? > Must fix stuff left to do for 2.2.18final > - New megaraid patch > - Fix the ps/2 misdetect bug that has appeared > - Get to the bottom of the VM mystery if possible (should be solved) > > [S/390 stuff isnt trivial to merge so will have to wait] > > 2.2.18pre18 > o Fix off by one in net/ipv4/proc (Dave Miller) > o Move the fpu emu patch that got away(Dave Miller) > o K6 update for MTRR ability (Dave Jones) > o Fix raid1/vm deadlock (Marcelo Tosatti) > o Fix usb mouse userspace memory accesses (David Woodhouse) > o Fix xpdsl if compiled in (typo) (Arjan van de Ven) > o Rio fixes for modem handling. Fix a small (Patrick van de Lageweg) > generic serial bug > o IBMtr driver fixes for cable pulls, pcmcia (Burt Silverman, > behaviour etcMike Sullivan) > o Tidy up /dev/microcode messages (Daniel Roesen) > o Add arpfilter (Andi Kleen) > o IDE floppy updates for clik support, cleanups (Paul Bristow) > o Fix irongate handling on Alpha (Soohoon Lee) > o Fix HZ=100 assumption in aha152x.c (me) > o Fix power management handling in i810 audio (me) > (From an ALSA fix by Godmar Back) > o Put the NFS block default back to 4K(Trond Myklebust) > o Fix misleading comment in printk code (Riley Williams) > o Fix fbcon scroll back/paste bug (Herbert Xu) > o Fix rtc_lock for ide-probe, and hd.c(Richard Johnson) > o Backport of 2.4 PR_GET/SET_KEEPCAPS (Brian Brunswick) > (from Chris Evans 2.4 code) > o LRU list corruption fix (Andrea Arcangeli) > o Initial gcc 2.96+ support for kernel building (H J Lu) > | Not a recommended compiler for production kernels... > o ALI silence clearing fix(Ching-Ling Lee) > o Fix remaining old-style use of copy_strings (Solar Designer) > o Better pci_resource_start macro for 2.2 (Jeff Garzik) > o Fix nbd deadlock(Marcelo Tosatti) > > 2.2.18pre17 > o Move a few escaped m68k headers into the right (me) > directory > o Backport 2.4 AF_UNIX garbage collect speedups (Dave Miller) > o TCP fixes for NFS (Saadia Khan) > o Fix USB audio hangs (David Woodhouse) > o Sparc64 dcache and exec fixes (Dave Miller) > o Fix typing crap in divert.h (Jeff Garzik) > o Use pkt_type in diverter, add maintainer info (Dave Miller) > o Fix obscure NAT problem in FIB code (Dave Miller) > o Fix sk->allocation in TCP sendmsg (Marcelo Tossati) > o Elevator fixes (Andrea Arcangeli) > o Allow broken_suid on NFS root (Trond Myklebust) > o Fix net/ipv6/proc off by one bug(Dave Miller) > o Fix AGP oops on Alpha (Michal Jaegermann) > o MSR/CPUID init call fixes (Arjan van de Ven) > o CS4281 sound hang fixes (Thomas Woller) > o AX.25 comment updates, Joerg has moved email(Joerg Reuter) > > 2.2.18pre16 > o Finally get the m68k tree merged(Andrew McPherson >and a cast of many) > o Bring the sparc back in line, make it build (Anton Blanchard) > o USB Bluetooth fixes/docs(Greg Kroah-Hartman) > o Fix auth_null credentials bug (Hai-Pao Fan) > o Update cpu flag names (Dave Jones) > o Console 'quiet' boot option as in 2.4 (Rusty Russell) > o Make the sx serial driver work again(Patrick van de Lageweg) > o Fix negotation on the SYM53C1010(Gerard Roudier) > o Fix alpha loops per jiffy (Jay Estabrook) > o Fix pegasus to work with 2.2 kernels(Greg Kroah-Hartman) > o Update plusb driver for 2.2.x (Eric Ayers, >Deti Fliegl) > o Fix ohci to use __init (Greg Kroah-Hartman) > o /sbin/hotplug support for USB as in 2.4 (Greg Kroah-Hartman) > o Update ksymoops url (Keith Owens) > o Update the
Re: [Fwd: No IRQ known for interrupt pin A of device 00:0f.0]
Jeff Garzik wrote: > > Attached below is a message I just sent to someone else who is having > the same problem as you. Would it be possible for you to try the stuff > I suggest in the message as well? > > Thanks, > > Jeff > > Subject: Re: No IRQ known for interrupt pin A of device 00:0f.0 > Date: Sat, 28 Oct 2000 15:38:49 -0400 > From: Jeff Garzik <[EMAIL PROTECTED]> > Organization: MandrakeSoft > To: Burton Windle <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], Linus Torvalds <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > References: <[EMAIL PROTECTED]> > > Ok, the problem is that you have an interrupt router table for your Ali > 1533, but no interrupt router entry for your IDE device. That's why > pci_enable_device is failing. > > Would you mind testing two kernel patches for me? Both of these changes > should be attempted separately in 2.4.0-test10-pre6, and -without- > Andre's change. > > The first change attempts to build an interrupt router entry for you, if > none is available. I am most interested if this works. > > The second change simply ignores any pci_enable_device error returns, > and assumes that the IDE subsystem will pick up the pieces. > > Remember, do not apply both of these changes at the same time... > > Thanks, > > Jeff The second patch (the one ignoring errors) doesn't seem to change anything (except not giving the warning IIRC) Also, dump_pirq and lspci -vv output didn't change. The first says the following at boot: PCI: PCI BIOS revision 2.10 entry at 0xf0560, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router ALI [10b9/1533] at 00:07.0 PCI: Found IRQ 14 for device 00:0f.0 dump_pirq output remains the same. The lspci -vv output does change with the second patch: 00:0f.0 IDE interface: Acer Laboratories Inc. M5229 (rev c1) (prog-if fa) Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://www.tux.org/lkml/
Linux 2.2.18pre18
Treat this one with care. The LRU corruption fix is one of those 'clearly right but makes a mess if its not so clear as it seems' kind of fixes. Alan Must fix stuff left to do for 2.2.18final - New megaraid patch - Fix the ps/2 misdetect bug that has appeared - Get to the bottom of the VM mystery if possible (should be solved) [S/390 stuff isnt trivial to merge so will have to wait] 2.2.18pre18 o Fix off by one in net/ipv4/proc (Dave Miller) o Move the fpu emu patch that got away(Dave Miller) o K6 update for MTRR ability (Dave Jones) o Fix raid1/vm deadlock (Marcelo Tosatti) o Fix usb mouse userspace memory accesses (David Woodhouse) o Fix xpdsl if compiled in (typo) (Arjan van de Ven) o Rio fixes for modem handling. Fix a small (Patrick van de Lageweg) generic serial bug o IBMtr driver fixes for cable pulls, pcmcia (Burt Silverman, behaviour etcMike Sullivan) o Tidy up /dev/microcode messages (Daniel Roesen) o Add arpfilter (Andi Kleen) o IDE floppy updates for clik support, cleanups (Paul Bristow) o Fix irongate handling on Alpha (Soohoon Lee) o Fix HZ=100 assumption in aha152x.c (me) o Fix power management handling in i810 audio (me) (From an ALSA fix by Godmar Back) o Put the NFS block default back to 4K(Trond Myklebust) o Fix misleading comment in printk code (Riley Williams) o Fix fbcon scroll back/paste bug (Herbert Xu) o Fix rtc_lock for ide-probe, and hd.c(Richard Johnson) o Backport of 2.4 PR_GET/SET_KEEPCAPS (Brian Brunswick) (from Chris Evans 2.4 code) o LRU list corruption fix (Andrea Arcangeli) o Initial gcc 2.96+ support for kernel building (H J Lu) | Not a recommended compiler for production kernels... o ALI silence clearing fix(Ching-Ling Lee) o Fix remaining old-style use of copy_strings (Solar Designer) o Better pci_resource_start macro for 2.2 (Jeff Garzik) o Fix nbd deadlock(Marcelo Tosatti) 2.2.18pre17 o Move a few escaped m68k headers into the right (me) directory o Backport 2.4 AF_UNIX garbage collect speedups (Dave Miller) o TCP fixes for NFS (Saadia Khan) o Fix USB audio hangs (David Woodhouse) o Sparc64 dcache and exec fixes (Dave Miller) o Fix typing crap in divert.h (Jeff Garzik) o Use pkt_type in diverter, add maintainer info (Dave Miller) o Fix obscure NAT problem in FIB code (Dave Miller) o Fix sk->allocation in TCP sendmsg (Marcelo Tossati) o Elevator fixes (Andrea Arcangeli) o Allow broken_suid on NFS root (Trond Myklebust) o Fix net/ipv6/proc off by one bug(Dave Miller) o Fix AGP oops on Alpha (Michal Jaegermann) o MSR/CPUID init call fixes (Arjan van de Ven) o CS4281 sound hang fixes (Thomas Woller) o AX.25 comment updates, Joerg has moved email(Joerg Reuter) 2.2.18pre16 o Finally get the m68k tree merged(Andrew McPherson and a cast of many) o Bring the sparc back in line, make it build (Anton Blanchard) o USB Bluetooth fixes/docs(Greg Kroah-Hartman) o Fix auth_null credentials bug (Hai-Pao Fan) o Update cpu flag names (Dave Jones) o Console 'quiet' boot option as in 2.4 (Rusty Russell) o Make the sx serial driver work again(Patrick van de Lageweg) o Fix negotation on the SYM53C1010(Gerard Roudier) o Fix alpha loops per jiffy (Jay Estabrook) o Fix pegasus to work with 2.2 kernels(Greg Kroah-Hartman) o Update plusb driver for 2.2.x (Eric Ayers, Deti Fliegl) o Fix ohci to use __init (Greg Kroah-Hartman) o /sbin/hotplug support for USB as in 2.4 (Greg Kroah-Hartman) o Update ksymoops url (Keith Owens) o Update the changes doc about gcc(Petri Kaukasoina) o Fix AMD flag naming (Ulrich Windl) o Restore old block size on devices after a
Re: LVM snapshotting broken?
On Sat, 28 Oct 2000, Heinz J. Mauelshagen wrote: > > OK, good. I guess that means that the lvmutils (even the > > patched version in the RPM) are heavily broken ... > > As i mentioned before: i wasn't able to reproduce your problem on any of > my systems. It work just fine with 0.8final and in 0.9 as weel. > > Did anybody else beside Rik face a problem with snapshots _not_ > referring to the original logical volume they where created for? There's a missing item in the _data structure declaration_ in the header file that prevents userspace from passing the right LV argument to the kernel, resulting in the kernel always making a snapshot of LV #0. You may have written LVM, but that doesn't excuse you from checking your facts ;) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.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: patch: atapi dvd-ram support
On Sat, Oct 28 2000, Hisaaki Shibata wrote: > > > But I could not mkudf nor mkext2fs to my ATAPI 9.4GB new DVD-RAM drive. > > > > What do you mean? What happened? strace of mke2fs of mkudf would > > be nice to have. > > My system said it is not permited because it is read only. [snip] Ok, does /proc/sys/dev/cdrom/info list DVD-RAM as a capability? > And /proc/ide/hdc/media says "cdrom". Is it OK? Yes, that is fine. -- * 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: 2.2.17 & ASUS CD-S500/A (again)
On Sat, Oct 28 2000, Lorenzo Allegrucci wrote: > I've got this while trying to play an audio CD by cdplay. [snip] > NOTE: > 2.4.0-test9 works without problems. 2.2.18-pre-latest will do then, could you try that? -- * 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/
2.4.0-test10-pre6: Use of abs()
Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
both sides).
abs() is used at least in:
arch/i386/kernel/time.c
drivers/md/raid1.c
drivers/sound/sb_ess.c
gcc warns about use of a non-declared function each time.
No definition for the function is to be found (grep over all include/ comes
up clean, except for extern definitions in asm-{mips,ppc}; ditto for lib/).
Presumably gcc is using a builtin (it doesn't show up in System.map). Is
this the desired state of affairs? Should a include/linux/stdlib.h be
added, containing (for now, to be expanded later as needed, like
include/linux/stddef.h):
#ifndef _LINUX_STDLIB_H
#define _LINUX_STDLIB_H
extern int abs(int);
#endif
--
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
linux-2.4.0-test10-pre6: Trigraphs in drivers/pci/devlist.h
I understand you are in charge of this per MAINTAINERS, it not, I apologize for bothering you. Red Hat 7, i686, gcc-20001027 (from CVS) complains about '??)' trigraphs at lines 1278 and 6367. Should that be just '(?)', or perhaps 'xx'? (egcs-1.1.2 keeps quiet). [Yes, trigraphs are bletcherous. Perhaps disable the warning for good in Makefile: HOSTCFLAGS = -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer ] Thanks! -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send 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: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
A lot of talk here has been about syslog and DNS blocking, but the original message mentioned: > If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3, > kernel 2.2.x), within a few minutes you will find your entire machine > grinds to a halt. For example, nobody can log in. Has this been addressed (and I missed it) or did the question get diverted? If it has been addressed, just please mail me personally to save traffic on the list. Thanks! -- Stephen Harris [EMAIL PROTECTED] http://www.spuddy.org/ The truth is the truth, and opinion just opinion. But what is what? My employer pays to ignore my opinions; you get to do it for free. * Mow ! Call Spud the Cat on > 01708 442043 < for free Usenet access * - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.17 & ASUS CD-S500/A (again)
I've got this while trying to play an audio CD by cdplay.
hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdc: packet command error: error=0x54
ATAPI device hdc:
Error: Illegal request -- (Sense key=0x05)
Invalid command operation code -- (asc=0x20, ascq=0x00)
The failed "Play Audio TrackIndex" packet command was:
"48 00 00 00 01 01 00 0a 63 00 00 00 "
hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdc: packet command error: error=0x54
ATAPI device hdc:
Error: Illegal request -- (Sense key=0x05)
Invalid command operation code -- (asc=0x20, ascq=0x00)
The failed "Play Audio TrackIndex" packet command was:
"48 00 00 00 01 01 00 0a 01 00 00 00 "
cdplay: ioctl cdromplaytrkind
I can't play any CD under 2.2.17
2.2.17 bug or "Yet Another Bug Of S500/A" ? :-)
NOTE:
2.4.0-test9 works without problems.
--
Lorenzo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9 not Open Source
Alan Cox wrote: > > > In this case, Debian (or any organization who isn't big enough not to fear > > M-systems) may not ship the standard kernel because it has additional patent > > restrictions. > > Why. There are no distribution restrictions > > > There is a clear ability here for the author of the driver and m-systems to > > conspire to retroactively revoke anyones privilege to use, modify, or > > distribute the stock kernel because of this code. > > I fail to see how > Alan is right. The way it's worded, they could never show a case for "irreparable harm" to any sitting judge in the US. This means they could say "we've changed our minds, and revoke this persons or that person's license" but given it's been released with this language, no case for harm or damages, or even a petition for injunctive relief would have a snowball's change in hell of succeeding. If you release code under the GPL, you basically waive any rights to seek enforcement because in the US, you must be able to show "irreparable harm" from some parties use of the code. It's tough to do this if you've given the code away (which the GPL does) without a contractural requirement for "consideration" ($$$). The GPL in the strictest legal sense is the ultimate IP legal virus because it not only removes the basis for damages claims for use of present code released under it's terms, but since it covers derivative works, it's effect contaminates all future incarnations of the code. It's true with how this is worded, the party could come back and attempt to modify the scope, but they would be hard pressed to make a case for an injunction to halt someone's use of the code. :-) Jeff > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: No IRQ known for interrupt pin A of device 00:0f.0]
Jeff Garzik wrote: > > Remi Turk wrote: > > > > Jeff Garzik wrote: > > > > > > Ok, after fixing a bad interaction where the Web server was trying to > > > run dump_pirq as a CGI script, dump_pirq can be retrieved from > > > > > > http://gtf.org/garzik/kernel/files/dump_pirq > > > > :-) > > > > I just posted pcmcia-cs dump_pirq's output. > > Same thing :) I posted pcmcia_cs's dump_pirq as a convenience so > others wouldn't have to download and extract the tarball. > > Attached below is a message I just sent to someone else who is having > the same problem as you. Would it be possible for you to try the stuff > I suggest in the message as well? > > Thanks, > > Jeff > > -- > Jeff Garzik | "Mind if I drive?" -Sam > Building 1024 | "Not if you don't mind me clawing at the > MandrakeSoft| dash and shrieking like a cheerleader." > | -Max > > > > Subject: Re: No IRQ known for interrupt pin A of device 00:0f.0 > Date: Sat, 28 Oct 2000 15:38:49 -0400 > From: Jeff Garzik <[EMAIL PROTECTED]> > Organization: MandrakeSoft > To: Burton Windle <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], Linus Torvalds <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > References: <[EMAIL PROTECTED]> > > Ok, the problem is that you have an interrupt router table for your Ali > 1533, but no interrupt router entry for your IDE device. That's why > pci_enable_device is failing. > > Would you mind testing two kernel patches for me? Both of these changes > should be attempted separately in 2.4.0-test10-pre6, and -without- > Andre's change. > > The first change attempts to build an interrupt router entry for you, if > none is available. I am most interested if this works. > > The second change simply ignores any pci_enable_device error returns, > and assumes that the IDE subsystem will pick up the pieces. > > Remember, do not apply both of these changes at the same time... > > Thanks, > > Jeff It's compiling the first kernel now, but I don't think I'll have any results before tomorrow. What changes from Andre do you mean? -- Linux 2.4.0-test10-pre6 #1 Sat Oct 28 14:15:54 CEST 2000 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No IRQ known for interrupt pin A of device 00:0f.0
Jeff Garzik wrote: > > Remi Turk wrote: > > Uniform Multi-Platform E-IDE driver Revision: 6.31 > > ide: Assuming 33MHz system bus speed for PIO modes; override with > > idebus=xx > > ALI15X3: IDE controller on PCI bus 00 dev 78 > > PCI: No IRQ known for interrupt pin A of device 00:0f.0. Please try > > using pci=biosirq. > > test10-pre6 gives this warning? > > Can you post the output of dump_pirq, from the pcmcia_cs package? (if > you don't have it already, http://pcmcia-cs.sourceforge.net/) > Here it is: Interrupt routing table found at address 0xf0b40: Version 1.0, size 0x00a0 Interrupt router is device 00:07.0 PCI exclusive interrupt mask: 0x [] Compatible router: vendor 0x10b9 device 0x1533 Device 00:0c.0 (slot 1): INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:0b.0 (slot 2): INTA: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:0a.0 (slot 3): INTA: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:09.0 (slot 4): Multimedia audio controller INTA: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:0d.0 (slot 5): INTA: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:02.0 (slot 0): USB Controller INTA: link 0x59, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:01.0 (slot 0): PCI bridge INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Device 00:06.0 (slot 0): INTA: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTB: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTC: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] INTD: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12] Interrupt router at 00:07.0: AcerLabs Aladdin M1533 PCI-to-ISA bridge INT1 (link 1): irq 11 INT2 (link 2): unrouted INT3 (link 3): irq 5 INT4 (link 4): irq 10 INT5 (link 5): unrouted INT6 (link 6): unrouted INT7 (link 7): unrouted INT8 (link 8): unrouted Serial IRQ: [disabled] [quiet] [frame=21] [pulse=12] -- Linux 2.4.0-test10-pre6 #1 Sat Oct 28 14:15:54 CEST 2000 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0pre9 and an analog joystick
contact [EMAIL PROTECTED] On Wed 25-10-00 17:19:21, [EMAIL PROTECTED] wrote: > > > On Tue, 24 Oct 2000, Brian Gerst wrote: > > > [EMAIL PROTECTED] wrote: > > > > > > I just switched from 2.2.17pre9 to 2.4.0pre9, and my joystick won't work > > > anymore. It's an analog joystick connected to an AudioPCI sound card. I > > > can get it initialized, but I can not access it, it seems it does not map > > > it to js0 > > > > > > Oct 24 23:15:21 cr753963-a kernel: gameport0: NS558 ISA at 0x200 size 8 > > > speed 917 kHz > > > Oct 24 23:15:31 cr753963-a kernel: input0: Analog 2-axis 4-button joystick > > > at gameport0.0 [TSC timer, 463 MHz clock, 1193 ns res] > > > > > > and I can't get any further :[ > > > > > > Dave > > > > insmod joydev > > Ok, I can get it to work with modules, but it will not work if it's > directly compiled into the kernel, is this a known bug? > > Dave > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send 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: signal handlers not linked properly in do_fork()?
Date:Sat, 28 Oct 2000 14:44:03 -0400 (EDT) From: David Eger <[EMAIL PROTECTED]> I see nowhere else in do_fork() where sig is set, either. What gives? fork.c, around line 560: *p = *current 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: PROBLEM: DELL PERC/Megaraid RAID driver in Linux 2.2.18pre17 hang
I don't believe that v1.09 (as in Red Hat Linux 7) has this problem, but does have fixes over-and-above 1.07 (particularly, 1.07 and v1.08 touch user-space inappropriately, 1.09 fixes). If PeterJ can't get to it before 2.2.18final, Alan, would you consider putting in the v1.09 driver? Thanks, 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/
signal handlers not linked properly in do_fork()?
I've been looking at the code for do_fork() / copy_sighand() and am mystified by the following. It seems that copy_sighand() only sets the new task's sig member if it is not CLONEd from the parent. If the signal_struct is CLONEd from the parent, it increments the parent's signal_struct's reference count, but does not set the new task's sig member. I see nowhere else in do_fork() where sig is set, either. What gives? -David Eger - To unsubscribe from this list: send 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: LVM snapshotting broken?
On Fri, Oct 27, 2000 at 11:55:03AM -0200, Rik van Riel wrote: > On Fri, 27 Oct 2000, Andrea Arcangeli wrote: > > On Fri, Oct 27, 2000 at 11:32:06AM -0200, Rik van Riel wrote: > > > Have you checked if the CONTENT of the snapshot is indeed > > > the right LV and not the other one? > > > > laser:~ # mke2fs /dev/vg1/lv1 &>/dev/null > > laser:~ # mount /dev/vg1/lv1 /mnt > > laser:~ # >/mnt/ciao > > laser:~ # ls /mnt > > . .. ciao lost+found > > laser:~ # umount /mnt > > laser:~ # lvcreate -s -n lv1-snap /dev/vg1/lv1 -L 400M > > lvcreate -- INFO: using default snapshot chunk size of 64 KB > > lvcreate -- doing automatic backup of "vg1" > > lvcreate -- logical volume "/dev/vg1/lv1-snap" successfully created > > > > laser:~ # mount /dev/vg1/lv1 /mnt > > laser:~ # rm /mnt/ciao > > laser:~ # umount /mnt > > laser:~ # mount /dev/vg1/lv1-snap /mnt > > mount: block device /dev/vg1/lv1-snap is write-protected, mounting read-only > > laser:~ # ls /mnt/ > > . .. ciao lost+found > > laser:~ # > > OK, good. I guess that means that the lvmutils (even the > patched version in the RPM) are heavily broken ... As i mentioned before: i wasn't able to reproduce your problem on any of my systems. It work just fine with 0.8final and in 0.9 as weel. Did anybody else beside Rik face a problem with snapshots _not_ referring to the original logical volume they where created for? > > Andrea, could you send me the patches you use to make your > LVM utilities work? Then we'll be able to put together at > least one working LVM utilities version ;) > > Heinz, how about releasing a 0.8.1 version of the utilities > so that there is something WORKING out there? Not having > working LVM utilities available is an utter disgrace when > all the code to make it work is just available... I don't have any complaints so far about similar snapshot malfunctions you mentioned, Rik. That said it is overemphasis to say, that the LVM utilities are not working. IMHO Andreas Dilger's LVM 0.8 backport to kernel 2.2 should be o.k. for most of the cases. I'ld like to have 0.9 to do the integtration of the available patches which will be released in november. > > regards, > > Rik > -- > "What you're running that piece of shit Gnome?!?!" >-- Miguel de Icaza, UKUUG 2000 > > http://www.conectiva.com/ http://www.surriel.com/ -- Regards, Heinz -- The LVM guy -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Heinz Mauelshagen Sistina Software Inc. Senior Consultant/Developer Bartningstr. 12 64289 Darmstadt Germany [EMAIL PROTECTED] +49 6151 7103 86 FAX 7103 96 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - To unsubscribe from this list: send 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: No IRQ known for interrupt pin A of device 00:0f.0
Remi Turk wrote: > Uniform Multi-Platform E-IDE driver Revision: 6.31 > ide: Assuming 33MHz system bus speed for PIO modes; override with > idebus=xx > ALI15X3: IDE controller on PCI bus 00 dev 78 > PCI: No IRQ known for interrupt pin A of device 00:0f.0. Please try > using pci=biosirq. test10-pre6 gives this warning? Can you post the output of dump_pirq, from the pcmcia_cs package? (if you don't have it already, http://pcmcia-cs.sourceforge.net/) -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and shrieking like a cheerleader." | -Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9 not Open Source
> In this case, Debian (or any organization who isn't big enough not to fear > M-systems) may not ship the standard kernel because it has additional patent > restrictions. Why. There are no distribution restrictions > There is a clear ability here for the author of the driver and m-systems to > conspire to retroactively revoke anyones privilege to use, modify, or > distribute the stock kernel because of this code. I fail to see how - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9 not Open Source
On Sat, Oct 28, 2000 at 05:24:19PM +0100, Alan Cox wrote: > The authors of the NTFL layer dont place any additional restrictions on your > use of the code either. They are merely warning you that if you use it in > some ways you are going to get your ass kicked by a third party. WHats the > difference, do you want to be sued by M-Systems or sqaushed by Deutsche Telecon See section 7 of the GPL. This is similar sort of GPL violation that kept Debian from shipping KDE because QT was not GPL compatible and there is GPLed code linked to QT in KDE without obvious explicit permission for the authors of every piece of GPLed code in KDE. In this case, Debian (or any organization who isn't big enough not to fear M-systems) may not ship the standard kernel because it has additional patent restrictions. There is a clear ability here for the author of the driver and m-systems to conspire to retroactively revoke anyones privilege to use, modify, or distribute the stock kernel because of this code. It's nice that the potential patent violation is made clear (I'm sure there are patents that could potentially apply elsewhere in the kernel) but it doesn't change the fact that the patents fundamentally limit the 'freedom' of the kernel code. - To unsubscribe from this list: send 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: RTNL assert
There is even one more Andrew :-) Here is the full patch: --- ./net/ipv4/ip_gre.c.~1~ Thu Aug 24 18:48:54 2000 +++ ./net/ipv4/ip_gre.c Sat Oct 28 09:59:43 2000 @@ -1266,7 +1266,9 @@ #ifdef MODULE register_netdev(_fb_tunnel_dev); #else + rtnl_lock(); register_netdevice(_fb_tunnel_dev); + rtnl_unlock(); #endif inet_add_protocol(_protocol); --- ./net/ipv4/ipip.c.~1~ Thu Aug 24 19:15:47 2000 +++ ./net/ipv4/ipip.c Sat Oct 28 10:00:04 2000 @@ -894,7 +894,9 @@ #ifdef MODULE register_netdev(_fb_tunnel_dev); #else + rtnl_lock(); register_netdevice(_fb_tunnel_dev); + rtnl_unlock(); #endif inet_add_protocol(_protocol); --- ./net/ipv6/sit.c.~1~Mon Oct 9 21:36:50 2000 +++ ./net/ipv6/sit.cSat Oct 28 10:00:50 2000 @@ -829,7 +829,9 @@ #ifdef MODULE register_netdev(_fb_tunnel_dev); #else + rtnl_lock(); register_netdevice(_fb_tunnel_dev); + rtnl_unlock(); #endif inet_add_protocol(_protocol); return 0; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PATCH 2.4.0.10.6: video4linux API update, bttv mmap rewrite
Thought some people here might be interested in this too... Description
quoted below.
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft| dash and screaming like a cheerleader."
| -Max
> This patch, against 2.4.0-test10-pre6, updates bttv to use the new and
> groovy method of supporting mmap.
>
> Advantages:
> * Code more simple.
> * mmap now only limited to number of free pages in the system (busts vmalloc limits)
> * mmap no longer requires vmalloc, or remap_page_range.
>
> Disadvantages:
> * Requires videodev API update (new member: mmap_vma).
> * KNOWN BUG: If your gbufsize causes a frame to cross a page boundary,
> you lose. The code doesn't support this, and doesn't check for it
> either. Boom. (this is fixable though)
> * Totally untested. I don't own any bttv hardware.
>
Index: include/linux/videodev.h
===
RCS file: /cvsroot/gkernel/linux_2_4/include/linux/videodev.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 videodev.h
--- include/linux/videodev.h2000/10/22 19:36:11 1.1.1.1
+++ include/linux/videodev.h2000/10/28 07:31:20
@@ -32,6 +32,7 @@
int busy;
int minor;
devfs_handle_t devfs_handle;
+ int (*mmap_vma)(struct file *, struct vm_area_struct *, struct video_device *);
};
extern int videodev_init(void);
Index: drivers/media/video/bttv-driver.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/media/video/bttv-driver.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 bttv-driver.c
--- drivers/media/video/bttv-driver.c 2000/10/22 22:02:34 1.1.1.2
+++ drivers/media/video/bttv-driver.c 2000/10/28 07:31:24
@@ -142,16 +142,6 @@
return ret;
}
-static inline unsigned long uvirt_to_bus(unsigned long adr)
-{
-unsigned long kva, ret;
-
-kva = uvirt_to_kva(pgd_offset(current->mm, adr), adr);
- ret = virt_to_bus((void *)kva);
-MDEBUG(printk("uv2b(%lx-->%lx)", adr, ret));
-return ret;
-}
-
static inline unsigned long kvirt_to_bus(unsigned long adr)
{
unsigned long va, kva, ret;
@@ -163,79 +153,60 @@
return ret;
}
-/* Here we want the physical address of the memory.
- * This is used when initializing the contents of the
- * area and marking the pages as reserved.
+/*
+ * Alloc and free DMA pages for mmap(2)
*/
-static inline unsigned long kvirt_to_pa(unsigned long adr)
-{
-unsigned long va, kva, ret;
-
-va = VMALLOC_VMADDR(adr);
-kva = uvirt_to_kva(pgd_offset_k(va), va);
- ret = __pa(kva);
-MDEBUG(printk("kv2pa(%lx-->%lx)", adr, ret));
-return ret;
-}
-
-static void * rvmalloc(signed long size)
+
+static void free_dmabuffers(struct bttv *btv)
{
- void * mem;
- unsigned long adr, page;
+ unsigned int i;
- mem=vmalloc_32(size);
- if (mem)
- {
- memset(mem, 0, size); /* Clear the ram out, no junk to the user */
- adr=(unsigned long) mem;
- while (size > 0)
-{
- page = kvirt_to_pa(adr);
- mem_map_reserve(virt_to_page(__va(page)));
- adr+=PAGE_SIZE;
- size-=PAGE_SIZE;
- }
+ if (btv->page) {
+ for (i = 0; i < btv->n_pages; i++)
+ if (btv->page[i].cpuaddr)
+ pci_free_consistent (btv->dev, PAGE_SIZE,
+btv->page[i].cpuaddr,
+btv->page[i].handle);
+ memset(btv->page, 0, sizeof(btv->page) * btv->n_pages);
+ btv->n_pages = 0;
+ kfree(btv->page);
+ btv->page = NULL;
}
- return mem;
}
-static void rvfree(void * mem, signed long size)
+static int alloc_dmabuffers(struct bttv *btv)
{
-unsigned long adr, page;
-
- if (mem)
- {
- adr=(unsigned long) mem;
- while (size > 0)
-{
- page = kvirt_to_pa(adr);
- mem_map_unreserve(virt_to_page(__va(page)));
- adr+=PAGE_SIZE;
- size-=PAGE_SIZE;
- }
- vfree(mem);
- }
-}
+ unsigned int i;
+ if (btv->page) {
+ printk(KERN_ERR "bttv%d: Double alloc of DMA pages!\n", btv->nr);
+ return 0;
+ }
+ btv->n_pages = (gbuffers * gbufsize) >> PAGE_SHIFT;
+ if ((gbuffers * gbufsize) % PAGE_SIZE)
+ btv->n_pages++;
-/*
- * Create the giant waste of buffer space we need for now
- * until we get DMA to user space sorted out (probably 2.3.x)
- *
- *
No IRQ known for interrupt pin A of device 00:0f.0
Hi, I just saw this warning when booting: Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ALI15X3: IDE controller on PCI bus 00 dev 78 PCI: No IRQ known for interrupt pin A of device 00:0f.0. Please try using pci=biosirq. ALI15X3: chipset revision 193 ALI15X3: not 100% native mode: will probe irqs later Booting with pci=biosirq doesn't help. Both test10-pre5 and test10-pre6 give this warning. test9 didn't. Should I just ignore it or is it really a problem? (My system seems to work ok) lspci -vv: 00:00.0 Host bridge: Acer Laboratories Inc. M1541 (rev 04) Subsystem: Unknown device 10b9:1541 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- TAbort- SERR- Reset- FastB2B- 00:02.0 USB Controller: Acer Laboratories Inc. M5237 (rev 03) (prog-if 10) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://www.tux.org/lkml/
Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was: Strange performance behavior of 2.4.0-test9)
Andrew Morton wrote:
>
> I think it's more expedient at this time to convert
> acquire_fl_sem/release_fl_sem into lock_kernel/unlock_kernel
> (so we _can_ sleep) and to fix the above alleged deadlock
> via the creation of __posix_unblock_lock()
I agree with me. Could you please test the scalability
of this?
--- linux-2.4.0-test10-pre5/fs/locks.c Tue Oct 24 21:34:13 2000
+++ linux-akpm/fs/locks.c Sun Oct 29 03:34:15 2000
@@ -1706,11 +1706,25 @@
posix_unblock_lock(struct file_lock *waiter)
{
acquire_fl_sem();
+ __posix_unblock_lock(waiter);
+ release_fl_sem();
+}
+
+/**
+ * __posix_unblock_lock - stop waiting for a file lock
+ * @waiter: the lock which was waiting
+ *
+ * lockd needs to block waiting for locks.
+ * Like posix_unblock_lock(), except it doesn't
+ * acquire the file lock semaphore.
+ */
+void
+__posix_unblock_lock(struct file_lock *waiter)
+{
if (!list_empty(>fl_block)) {
locks_delete_block(waiter);
wake_up(>fl_wait);
}
- release_fl_sem();
}
static void lock_get_status(char* out, struct file_lock *fl, int id, char *pfx)
--- linux-2.4.0-test10-pre5/include/linux/fs.h Tue Oct 24 21:34:13 2000
+++ linux-akpm/include/linux/fs.h Sun Oct 29 03:32:00 2000
@@ -564,6 +564,7 @@
extern struct file_lock *posix_test_lock(struct file *, struct file_lock *);
extern int posix_lock_file(struct file *, struct file_lock *, unsigned int);
extern void posix_block_lock(struct file_lock *, struct file_lock *);
+extern void __posix_unblock_lock(struct file_lock *);
extern void posix_unblock_lock(struct file_lock *);
extern int __get_lease(struct inode *inode, unsigned int flags);
extern time_t lease_get_mtime(struct inode *);
--- linux-2.4.0-test10-pre5/kernel/ksyms.c Sun Oct 15 01:27:46 2000
+++ linux-akpm/kernel/ksyms.c Sun Oct 29 03:32:38 2000
@@ -221,6 +221,7 @@
EXPORT_SYMBOL(posix_lock_file);
EXPORT_SYMBOL(posix_test_lock);
EXPORT_SYMBOL(posix_block_lock);
+EXPORT_SYMBOL(__posix_unblock_lock);
EXPORT_SYMBOL(posix_unblock_lock);
EXPORT_SYMBOL(locks_mandatory_area);
EXPORT_SYMBOL(dput);
--- linux-2.4.0-test10-pre5/fs/lockd/svclock.c Tue Oct 24 21:34:13 2000
+++ linux-akpm/fs/lockd/svclock.c Sun Oct 29 03:32:22 2000
@@ -456,7 +456,7 @@
struct nlm_block**bp, *block;
dprintk("lockd: VFS unblock notification for block %p\n", fl);
- posix_unblock_lock(fl);
+ __posix_unblock_lock(fl);
for (bp = _blocked; (block = *bp); bp = >b_next) {
if (nlm_compare_locks(>b_call.a_args.lock.fl, fl)) {
svc_wake_up(block->b_daemon);
--- linux-2.4.0-test10-pre5/fs/fcntl.c Sun Oct 15 01:27:45 2000
+++ linux-akpm/fs/fcntl.c Sun Oct 29 03:35:47 2000
@@ -254,11 +254,15 @@
unlock_kernel();
break;
case F_GETLK:
+ lock_kernel();
err = fcntl_getlk(fd, (struct flock *) arg);
+ unlock_kernel();
break;
case F_SETLK:
case F_SETLKW:
+ lock_kernel();
err = fcntl_setlk(fd, cmd, (struct flock *) arg);
+ unlock_kernel();
break;
case F_GETOWN:
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: DELL PERC/Megaraid RAID driver in Linux 2.2.18pre17 hang
Yep - known problem. AMI have one more pre patch to sort it our Im going back to the older driver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9 not Open Source
> Now firstly, let's eliminate the ISDN red-herring from consideration > because the authors of the code do not place any additional restrictions > on the GPL whatsoever, they simply bring it to your attention that using > an un-certified ISDN stack may be illegal in some countries. The authors of the NTFL layer dont place any additional restrictions on your use of the code either. They are merely warning you that if you use it in some ways you are going to get your ass kicked by a third party. WHats the difference, do you want to be sued by M-Systems or sqaushed by Deutsche Telecon 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/
PROBLEM: DELL PERC/Megaraid RAID driver in Linux 2.2.18pre17 hangs on boot
LINUX KERNEL PROBLEM REPORT
[1.] Megaraid driver in Linux 2.2.18pre17 hangs on boot
[2.] Full description of the problem:
The Megaraid driver in Linux 2.2.18pre17 (labelling itself as "1.11") hangs
completely
on loading/boot on a DELL 6300, after detecting the DELL PERC adapter
("Found a...")
[3.] Keywords: dell, ami, megaraid, raid, scsi, driver
[4.] Kernel version: 2.2.18pre17
[5.] N/A
[6.] N/A
[7] Environment:
Red Hat 6.2
DELL PERC Megaraid firmware U.84 Firmware 1.63
DELL 6300
[X.] Other notes:
Megaraid Driver 1.09 from earlier kernels works on this system with
2.2.18pre17.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: question on SMP and read()/write()
> I've noticed that sys_read() and sys_write() don't grab the big kernel lock. > As file descriptors may be shared, must device drivers provide SMP safe > read() and write() methods ? Yes. This is true in 2.2 as well although the inode lock provides some protection on writes. - To unsubscribe from this list: send 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: [PROPOSED PATCH] ATM refcount + firestream
Brian Gerst wrote: > > With or without your patch, the network ioctls are unsafe, since they > don't currently do refcounting at all. Adding it in the layer above the > driver is the easier and cleaner solution. As long as the drivers use unregister_netdevice() then that's fairly easy to fix within the netdevice layer. Just do a dev_hold()/dev_put() within dev_ifsioc(). - To unsubscribe from this list: send 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: kernel BUG at slab.c:804!
I'd guess this is because of a bug that crept into test9, where a TD is now leaked ... you can get rid of the slab BUG warning by commenting out the line at the top of drivers/usb/usb-ohci.c that #defines OHCI_MEM_SLAB. That TD leak prevents the kmem_cache from getting freed, and hence prevents that module from getting reloaded. It was a mistake to leave that #defined at this time, though of course it _ought_ to be fine to do that. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was: Strange performance behavior of 2.4.0-test9)
Andrew Morton wrote: > --- linux-2.4.0-test10-pre5/fs/locks.c Tue Oct 24 21:34:13 2000 > +++ linux-akpm/fs/locks.c Sun Oct 29 02:31:10 2000 > @@ -125,10 +125,9 @@ > #include > #include > > -DECLARE_MUTEX(file_lock_sem); > - > -#define acquire_fl_sem() down(_lock_sem) > -#define release_fl_sem() up(_lock_sem) > +spinlock_t file_lock_lock = SPIN_LOCK_UNLOCKED; > +#define acquire_fl_lock() spin_lock(_lock_lock); > +#define release_fl_lock() spin_unlock(_lock_lock); It seems like better concurrency could be achieved with reader-writer locks. Some of the lock test routines simply scan the list, without modifying it. -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and screaming like a cheerleader." | -Max - To unsubscribe from this list: send 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: Tekram's TRM-1040S USCSI proc driver?
Hi Benson, On Fri, Oct 27, 2000 at 06:25:45PM -0600, Benson Chow wrote: > Anyone know if Tekram's DC315/DC395 SCSI driver will be incorporated > into the kernel distribution? I think their driver is GPL, or was there > some other reason it wasn't incorporated? > > Their source code is on their website... and newer sources can be found on my website as I am the maintainer of this driver: http://www.garloff.de/kurt/linux/dc395/ You find everyhting you need to compile a driver module (or to incorporate it into the kernel) for 2.2 and 2.4 kernels. > Just wonderring... (unfortunately I had a DC315 for a day but had to give > it up... it was the worst of the AHA2940A and DC390F that I already > had...) As Matthias pointed out correctly: I did not ask for inclusion into the mainstream kernel yet. There's a reason for this: The driver works only for 98% of the people. Then there is one percent with weird problems that I can't understand at all (PCI DMA errors or spontaneous reboots ...) And one percent, where the driver ends up aborting commands, not recovering and finally sometimes corrupting data. It's the latter that worries me and I do not want to push the driver into the kernel, as long as I do not understand and solved these issues. After all, it's not a sound driver that just fails to operate, but a SCSI driver which you entrust your data to. Sorry! Regards, -- Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security PGP signature
Linux-2.4.0-test9 not Open Source
I've been looking at the MTD (memory technology device) additions to the
linux 2.4.0 kernels. In particular I'm very interested in the DiskOnChip
2000 and NFTL drivers. However, as terribly useful as this driver is, was
I the only one who caught the following notice at the top of the driver
source:
/*
The contents of this file are distributed under the GNU Public
Licence version 2 ("GPL"). The legal note below refers only to the
_use_ of the code in some jurisdictions, and does not in any way
affect the copying, distribution and modification of this code,
which is permitted under the terms of the GPL.
Section 0 of the GPL says:
"Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope."
You may copy, distribute and modify this code to your hearts'
content - it's just that in some jurisdictions, you may only _use_
it under the terms of the licence below. This puts it in a similar
situation to the ISDN code, which you may need telco approval to
use, and indeed any code which has uses that may be restricted in
law. For example, certain malicious uses of the networking stack
may be illegal, but that doesn't prevent the networking code from
being under GPL.
In fact the ISDN case is worse than this, because modification of
the code automatically invalidates its approval. Modificiation,
unlike usage, _is_ one of the rights which is protected by the
GPL. Happily, the law in those places where approval is required
doesn't actually prevent you from modifying the code - it's just
that you may not be allowed to _use_ it once you've done so - and
because usage isn't addressed by the GPL, that's just fine.
[EMAIL PROTECTED]
6/7/0
LEGAL NOTE: The NFTL format is patented by M-Systems. They have
granted a licence for its use with their DiskOnChip products:
"M-Systems grants a royalty-free, non-exclusive license under
any presently existing M-Systems intellectual property rights
necessary for the design and development of NFTL-compatible
drivers, file systems and utilities to use the data formats with,
and solely to support, M-Systems' DiskOnChip products"
A signed copy of this agreement from M-Systems is kept on file by
Red Hat UK Limited. In the unlikely event that you need access to it,
please contact [EMAIL PROTECTED] for assistance. */
Now firstly, let's eliminate the ISDN red-herring from consideration
because the authors of the code do not place any additional restrictions
on the GPL whatsoever, they simply bring it to your attention that using
an un-certified ISDN stack may be illegal in some countries.
Now that we've cleared *that* up, let's look at the rest of the NFTL
restriction. I've already brought this to the attention, of course, of
RMS and ESR.
Richard believes that this violates the GPL because it places additional
restrictions not found in the GPL.
In any case, it seems pretty obvious that this restriction violates
section 6 of the Open Source Definition which states:
"The license must not restrict anyone from making use of the program in
a specific field of endeavor"
In this case, the field of endeavor is to use it with another vendor's
product.
In any case, as terribly useful as this driver is (I'm working on a system
that needs the Disk-On-Chip/NTFL support) I am also conerned with the
stock Linux kernel getting tainted with non-Open Source code.
Comments welcome and appreciated.
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: [PROPOSED PATCH] ATM refcount + firestream
Philipp Rumpf wrote:
>
> On Sat, Oct 28, 2000 at 09:55:21AM -0400, Brian Gerst wrote:
> > Yes, but they can be called (and sleep) with module refcount == 0. This
> > is because the file descripter used to perform the ioctl isn't directly
> > associated with the network device, thereby not incrementing the
> > refcount on open.
>
> According to my proposal, it is perfectly safe to call a function in a module
> while the module's use count is 0. This function would typically look like this:
>
> foo()
> {
> MOD_INC_USE_COUNT;
>
> copy_*_user() (or anything else that sleeps);
>
> MOD_DEC_USE_COUNT;
>
> return bar;
> }
>
> The only difference to the "old" module scheme is that the above currently isn't
> safe on SMP systems.
This will only work while the kernel is not preemptable. Once the
kernel thread can be rescheduled, all bets are off.
With or without your patch, the network ioctls are unsafe, since they
don't currently do refcounting at all. Adding it in the layer above the
driver is the easier and cleaner solution.
--
Brian Gerst
-
To unsubscribe from this list: send 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] Re: Negative scalability by removal of lock_kernel()?(Was: Strange performance behavior of 2.4.0-test9)
On Sun, Oct 29, 2000 at 02:46:14AM +1100, Andrew Morton wrote: > [EMAIL PROTECTED] wrote: > > > > Change the following two macros: > > acquire_fl_sem()->lock_kernel() > > release_fl_sem()->unlock_kernel() > > then > > 5192 Req/s @8cpu is got. It is same as test8 within fluctuation. > > hmm.. BKL increases scalability. News at 11. > > The big question is: why is Apache using file locking so > much? Is this normal behaviour for Apache? It serializes accept() to avoid the thundering herd from the wake-all semantics. With the 2.4 stack that is probably not needed anymore (it was in 2.2), it may just work to remove the file locking (it should always be correct, just on 2.2 it may be slower to remove it) > Because if so, the file locking code will be significantly > bad for the scalability of Apache on SMP (of all things!). > It basically grabs a big global lock for _anything_. It > looks like it could be a lot more granular. iirc everybody who looked at the code agrees that it needs a rewrite badly. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New VM problem
James Lewis Nance <[EMAIL PROTECTED]> writes: > On an unrelated note, is it possible for a process in 2.4 to see more > than 2G of address space? They seem to be limited to 2G for me. I > was hoping that the HIMEM stuff had removed that limit. You have 3GB user space address space. 1 GB is still reserved for the kernel and you cannot break the 4GB limit for one process. But you can have multiple processes using their own <3GB chunk of memory. Greetings Christoph - To unsubscribe from this list: send 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] Re: Negative scalability by removal of lock_kernel()?(Was: Strange performance behavior of 2.4.0-test9)
[EMAIL PROTECTED] wrote:
>
> Change the following two macros:
> acquire_fl_sem()->lock_kernel()
> release_fl_sem()->unlock_kernel()
> then
> 5192 Req/s @8cpu is got. It is same as test8 within fluctuation.
hmm.. BKL increases scalability. News at 11.
The big question is: why is Apache using file locking so
much? Is this normal behaviour for Apache?
Because if so, the file locking code will be significantly
bad for the scalability of Apache on SMP (of all things!).
It basically grabs a big global lock for _anything_. It
looks like it could be a lot more granular.
>
> I put the patch to change all occurrence of semaphore "file_lock_sem"
> into spinlock variable "file_lock_lock".
Unfortunately this is deadlocky - in several places functions
which can sleep are called when file_lock_lock is held.
More unfortunately I think we _already_ have a deadlock in
the file locking:
locks_wake_up_blocks() is always called with file_lock_sem held.
locks_wake_up_blocks() calls waiter->fl_notify(), which is really
nlmsvc_notify_blocked()
nlmsvc_notify_blocked() calls posix_unblock_lock()
posix_unblock_lock() calls acquire_fl_sem()
Can someone please confirm this?
Anyway, here is a modified version of your patch which
fixes everything.
But I'm not sure that it should be applied. I think it's
more expedient at this time to convert acquire_fl_sem/release_fl_sem
into lock_kernel/unlock_kernel (so we _can_ sleep) and to fix the
above alleged deadlock via the creation of __posix_unblock_lock() as in
this patch.
--- linux-2.4.0-test10-pre5/fs/lockd/clntlock.c Tue Oct 24 21:34:13 2000
+++ linux-akpm/fs/lockd/clntlock.c Sun Oct 29 00:39:15 2000
@@ -168,10 +168,10 @@
* reclaim is in progress */
lock_kernel();
lockd_up();
- down(_lock_sem);
/* First, reclaim all locks that have been granted previously. */
restart:
+ spin_lock(_lock_lock);
tmp = file_lock_list.next;
while (tmp != _lock_list) {
struct file_lock *fl = list_entry(tmp, struct file_lock, fl_link);
@@ -181,12 +181,13 @@
fl->fl_u.nfs_fl.state != host->h_state &&
(fl->fl_u.nfs_fl.flags & NFS_LCK_GRANTED)) {
fl->fl_u.nfs_fl.flags &= ~ NFS_LCK_GRANTED;
+ spin_unlock(_lock_lock);
nlmclnt_reclaim(host, fl);
goto restart;
}
tmp = tmp->next;
}
- up(_lock_sem);
+ spin_unlock(_lock_lock);
host->h_reclaiming = 0;
wake_up(>h_gracewait);
--- linux-2.4.0-test10-pre5/fs/locks.c Tue Oct 24 21:34:13 2000
+++ linux-akpm/fs/locks.c Sun Oct 29 02:31:10 2000
@@ -125,10 +125,9 @@
#include
#include
-DECLARE_MUTEX(file_lock_sem);
-
-#define acquire_fl_sem() down(_lock_sem)
-#define release_fl_sem() up(_lock_sem)
+spinlock_t file_lock_lock = SPIN_LOCK_UNLOCKED;
+#define acquire_fl_lock() spin_lock(_lock_lock);
+#define release_fl_lock() spin_unlock(_lock_lock);
int leases_enable = 1;
int lease_break_time = 45;
@@ -352,29 +351,27 @@
#endif
/* Allocate a file_lock initialised to this type of lease */
-static int lease_alloc(struct file *filp, int type, struct file_lock **flp)
+static struct file_lock *lease_alloc(struct file *filp, int type)
{
struct file_lock *fl = locks_alloc_lock(1);
- if (fl == NULL)
- return -ENOMEM;
-
- fl->fl_owner = current->files;
- fl->fl_pid = current->pid;
+ if (fl != NULL) {
+ fl->fl_owner = current->files;
+ fl->fl_pid = current->pid;
- fl->fl_file = filp;
- fl->fl_flags = FL_LEASE;
- if (assign_type(fl, type) != 0) {
- locks_free_lock(fl);
- return -EINVAL;
+ fl->fl_file = filp;
+ fl->fl_flags = FL_LEASE;
+ if (assign_type(fl, type) != 0) {
+ locks_free_lock(fl);
+ fl = NULL;
+ } else {
+ fl->fl_start = 0;
+ fl->fl_end = OFFSET_MAX;
+ fl->fl_notify = NULL;
+ fl->fl_insert = NULL;
+ fl->fl_remove = NULL;
+ }
}
- fl->fl_start = 0;
- fl->fl_end = OFFSET_MAX;
- fl->fl_notify = NULL;
- fl->fl_insert = NULL;
- fl->fl_remove = NULL;
-
- *flp = fl;
- return 0;
+ return fl;
}
/* Check if two locks overlap each other.
@@ -431,6 +428,9 @@
/* Wake up processes blocked waiting for blocker.
* If told to wait then schedule the processes until the block list
* is empty, otherwise empty the block list ourselves.
+ *
+ * waiter->fl_notify() is not allowed to block. Otherwise
+ * we could deadlock on file_lock_lock - AKPM.
*/
static void locks_wake_up_blocks(struct file_lock *blocker, unsigned
Re: question on SMP and read()/write()
On Saturday 28 October 2000 16:43, you wrote: > > I've noticed that sys_read() and sys_write() don't grab the big kernel > > lock. As file descriptors may be shared, must device drivers provide SMP > > safe read() and write() methods ? > > no. FD's refer to files; block drivers don't, and the nontrivial > code between sys_* and drivers deals with this sort of thing. Sure block drivers need not do this, but how about drivers for character devices ? It seems that sys_read() calls a function provided by the f_op table without any locking. Isn't this the function a driver for a character device must provide to the VFS ? TIA Oliver - To unsubscribe from this list: send 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: [PROPOSED PATCH] ATM refcount + firestream
On Sat, Oct 28, 2000 at 09:55:21AM -0400, Brian Gerst wrote:
> Yes, but they can be called (and sleep) with module refcount == 0. This
> is because the file descripter used to perform the ioctl isn't directly
> associated with the network device, thereby not incrementing the
> refcount on open.
According to my proposal, it is perfectly safe to call a function in a module
while the module's use count is 0. This function would typically look like this:
foo()
{
MOD_INC_USE_COUNT;
copy_*_user() (or anything else that sleeps);
MOD_DEC_USE_COUNT;
return bar;
}
The only difference to the "old" module scheme is that the above currently isn't
safe on SMP systems.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
question on SMP and read()/write()
Hi, I've noticed that sys_read() and sys_write() don't grab the big kernel lock. As file descriptors may be shared, must device drivers provide SMP safe read() and write() methods ? TIA Oliver - To unsubscribe from this list: send 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: PLIP driver in 2.2.xx kernels
> I have a question - Why does the PLIP driver does consume so much CPU ? > I tried it today, and when i did ping -s 16000 dst_ip, the kernel consumed > about 50% of the CPU time ( /proc/cpuinfo and /proc/interrupts follow). > Any ideas ? It has to bang on the parallel port controller the hard way, there is no useful hardware support on a basic parallel port for the kind of abuse needed for PLIP - To unsubscribe from this list: send 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: atapi dvd-ram support
Thanks, Axboe
> > But I could not mkudf nor mkext2fs to my ATAPI 9.4GB new DVD-RAM drive.
>
> What do you mean? What happened? strace of mke2fs of mkudf would
> be nice to have.
My system said it is not permited because it is read only.
execve("/sbin/mke2fs", ["/sbin/mke2fs", "/dev/hdc"], [/* 19 vars */]) = 0
brk(0) = 0x804dd80
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40013000
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=19214, ...}) = 0
old_mmap(NULL, 19214, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
close(3)= 0
open("/lib/libext2fs.so.2", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=83284, ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2146\0"..., 4096) = 4096
old_mmap(NULL, 71696, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40019000
mprotect(0x4002a000, 2064, PROT_NONE) = 0
old_mmap(0x4002a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1) =
0x4002a000
close(3)= 0
open("/lib/libcom_err.so.2", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=8057, ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\230\t\0"..., 4096) = 4096
And /proc/ide/hdc/media says "cdrom". Is it OK?
Best Regards,
--
W [EMAIL PROTECTED]
|O-O| Hisaaki Shibata
0(mmm)0 P-mail: 070-5419-3233IRC: #luky
~http://his.luky.org/ last update:2000.3.12
-
To unsubscribe from this list: send 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: RTNL assert
Andrew Morton wrote: > > "Stephen E. Clark" wrote: > > > > When I configure in Tunneling I get the following error message. Is this > > normal? This with 2.4test9pre5 > > > > GRE over IPv4 tunneling driver > > RTNL: assertion failed at devinet.c(775):inetdev_event > > The rtnetlink lock needs to be taken around > register_netdevice(). There should be a function > which does these three common steps, but there isn't. > > --- linux-2.4.0-test10-pre5/net/ipv4/ip_gre.c Sat Sep 9 16:19:30 2000 > +++ linux-akpm/net/ipv4/ip_gre.cSat Oct 28 21:44:23 2000 > @@ -1266,7 +1266,9 @@ > #ifdef MODULE > register_netdev(_fb_tunnel_dev); > #else > + rtnl_lock(); > register_netdevice(_fb_tunnel_dev); > + rtnl_unlock(); > #endif > > inet_add_protocol(_protocol); > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ Thanks Andrew, I also get the same error if I try to configure in normal IPV4 tunneling. I guess it needs the same kind of patch. Oct 27 14:46:59 joker kernel: IPv4 over IPv4 tunneling driver Oct 27 14:46:59 joker kernel: RTNL: assertion failed at devinet.c(775):inetdev_event Oct 27 14:46:59 joker kernel: GRE over IPv4 tunneling driver Oct 27 14:46:59 joker kernel: RTNL: assertion failed at devinet.c(775):inetdev_event Steve - To unsubscribe from this list: send 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: Tekram's TRM-1040S USCSI proc driver?
On Fri, 27 Oct 2000, Benson Chow wrote: > Anyone know if Tekram's DC315/DC395 SCSI driver will be incorporated > into the kernel distribution? I think their driver is GPL, or was there > some other reason it wasn't incorporated? The driver will not be included until its maintainer, currently Kurt Garloff, says it's ready for inclusion. -- Matthias Andree - To unsubscribe from this list: send 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: [PROPOSED PATCH] ATM refcount + firestream
Philipp Rumpf wrote: > > On Sat, Oct 28, 2000 at 09:37:28AM -0400, Brian Gerst wrote: > > Philipp Rumpf wrote: > > > - you can't copy_(from|to)_user in the module exit function (which would > > > be copies from/to rmmod anyway) > > > > Unfortunately, you need to be able to use copy_*_user() from the network > > ioctls, and this is the center of the current issue. > > You misunderstood. The network ioctls aren't module_exit functions, so > copy_*_user in them is fine. Yes, but they can be called (and sleep) with module refcount == 0. This is because the file descripter used to perform the ioctl isn't directly associated with the network device, thereby not incrementing the refcount on open. -- Brian Gerst - To unsubscribe from this list: send 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: [PROPOSED PATCH] ATM refcount + firestream
On Sat, Oct 28, 2000 at 09:37:28AM -0400, Brian Gerst wrote: > Philipp Rumpf wrote: > > - you can't copy_(from|to)_user in the module exit function (which would > > be copies from/to rmmod anyway) > > Unfortunately, you need to be able to use copy_*_user() from the network > ioctls, and this is the center of the current issue. You misunderstood. The network ioctls aren't module_exit functions, so copy_*_user in them is fine. Philipp Rumpf - To unsubscribe from this list: send 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: [PROPOSED PATCH] ATM refcount + firestream
Philipp Rumpf wrote:
>
> On Fri, Oct 27, 2000 at 10:49:53PM +1100, Andrew Morton wrote:
> > Look, this modules stuff is really bad. Phillip Rumpf proposed
> > a radical alternative a while back which I felt was not given
>
> While it might be a "radical alternative", it doesn't require any changes
> to the subsystems that have been fixed so far. At this time, applying the
> patch would basically fix the rest of the subsystems as well (if the
> drivers use MOD_{INC,DEC}_USE_COUNT, that is).
>
> > sufficient consideration. The idea was to make sys_delete_module()
> > grab all the other CPUs and leave them spinning on a flag while
> > the unload was proceeding. This was very similar to
> > arch/i386/kernel/apm.c:apm_power_off().
>
> The idea here is other CPUs don't have to deal with the kernel going
> through a number of inconsistent states while a module is unloaded. At
> any point in time, for any module, exactly one of the following is true:
>
> 1. you're in the module_exit function
> 2. the module is (being) loaded
> 3. the module isn't loaded.
>
> > As far as I can recall, the only restriction was that you are
> > not allowed to call module functions when the module refcount
> > is zero if those functions can call schedule().
>
> There are other restrictions which shouldn't really matter:
>
> - you can't schedule() and hope you end up on a particular CPU (you can
> use smp_call_function though)
>
> - you can't copy_(from|to)_user in the module exit function (which would
> be copies from/to rmmod anyway)
Unfortunately, you need to be able to use copy_*_user() from the network
ioctls, and this is the center of the current issue.
--
Brian Gerst
-
To unsubscribe from this list: send 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: [PROPOSED PATCH] ATM refcount + firestream
On Fri, Oct 27, 2000 at 10:49:53PM +1100, Andrew Morton wrote:
> Look, this modules stuff is really bad. Phillip Rumpf proposed
> a radical alternative a while back which I felt was not given
While it might be a "radical alternative", it doesn't require any changes
to the subsystems that have been fixed so far. At this time, applying the
patch would basically fix the rest of the subsystems as well (if the
drivers use MOD_{INC,DEC}_USE_COUNT, that is).
> sufficient consideration. The idea was to make sys_delete_module()
> grab all the other CPUs and leave them spinning on a flag while
> the unload was proceeding. This was very similar to
> arch/i386/kernel/apm.c:apm_power_off().
The idea here is other CPUs don't have to deal with the kernel going
through a number of inconsistent states while a module is unloaded. At
any point in time, for any module, exactly one of the following is true:
1. you're in the module_exit function
2. the module is (being) loaded
3. the module isn't loaded.
> As far as I can recall, the only restriction was that you are
> not allowed to call module functions when the module refcount
> is zero if those functions can call schedule().
There are other restrictions which shouldn't really matter:
- you can't schedule() and hope you end up on a particular CPU (you can
use smp_call_function though)
- you can't copy_(from|to)_user in the module exit function (which would
be copies from/to rmmod anyway)
> prumpf, please dig out that patch.
attached (rediff against test10-pre6, it seems to work).
diff -urN linux/arch/i386/mm/extable.c linux-prumpf/arch/i386/mm/extable.c
--- linux/arch/i386/mm/extable.cWed Nov 10 08:31:37 1999
+++ linux-prumpf/arch/i386/mm/extable.c Sat Oct 28 06:14:43 2000
@@ -30,26 +30,30 @@
return 0;
}
+extern struct rw_semaphore module_mutex;
+
unsigned long
search_exception_table(unsigned long addr)
{
- unsigned long ret;
+ unsigned long ret = 0;
#ifndef CONFIG_MODULES
/* There is only the kernel to search. */
ret = search_one_table(__start___ex_table, __stop___ex_table-1, addr);
- if (ret) return ret;
#else
/* The kernel is the last "module" -- no need to treat it special. */
struct module *mp;
+
+ down_read(_mutex);
for (mp = module_list; mp != NULL; mp = mp->next) {
if (mp->ex_table_start == NULL)
continue;
ret = search_one_table(mp->ex_table_start,
mp->ex_table_end - 1, addr);
- if (ret) return ret;
+ if (ret) break;
}
+ up_read(_mutex);
#endif
- return 0;
+ return ret;
}
diff -urN linux/include/linux/smp.h linux-prumpf/include/linux/smp.h
--- linux/include/linux/smp.h Tue Sep 26 14:31:51 2000
+++ linux-prumpf/include/linux/smp.hSat Oct 28 06:14:43 2000
@@ -71,6 +71,9 @@
#define MSG_RESCHEDULE 0x0003 /* Reschedule request from master CPU*/
#define MSG_CALL_FUNCTION 0x0004 /* Call function on all other CPUs */
+extern int freeze_other_cpus(void);
+extern void melt_other_cpus(void);
+
#else
/*
@@ -86,6 +89,8 @@
#define cpu_number_map(cpu)0
#define smp_call_function(func,info,retry,wait)({ 0; })
#define cpu_online_map 1
+#define freeze_other_cpus()0
+#define melt_other_cpus() do { } while(0)
#endif
#endif
diff -urN linux/kernel/module.c linux-prumpf/kernel/module.c
--- linux/kernel/module.c Sat Oct 28 05:03:26 2000
+++ linux-prumpf/kernel/module.cSat Oct 28 06:14:43 2000
@@ -37,6 +37,11 @@
ex_table_end: __stop___ex_table
};
+/* module_mutex protects module_list - if you can down_read() it, modules
+ * won't be added/removed, but their usecount, flags aso still might change.
+ */
+
+DECLARE_RWSEM(module_mutex);
struct module *module_list = _module;
static long get_mod_name(const char *user_name, char **buf);
@@ -105,7 +110,6 @@
if (!capable(CAP_SYS_MODULE))
return -EPERM;
- lock_kernel();
if ((namelen = get_mod_name(name_user, )) < 0) {
error = namelen;
goto err0;
@@ -114,32 +118,40 @@
error = -EINVAL;
goto err1;
}
+ lock_kernel();
+ down_write(_mutex);
if (find_module(name) != NULL) {
error = -EEXIST;
- goto err1;
+ goto err2;
}
if ((mod = (struct module *)module_map(size)) == NULL) {
error = -ENOMEM;
- goto err1;
+ goto err2;
}
memset(mod, 0, sizeof(*mod));
mod->size_of_struct = sizeof(*mod);
- mod->next = module_list;
mod->name = (char *)(mod + 1);
mod->size = size;
memcpy((char*)(mod+1), name, namelen+1);
put_mod_name(name);
+
PLIP driver in 2.2.xx kernels
I have a question - Why does the PLIP driver does consume so much CPU ? I tried it today, and when i did ping -s 16000 dst_ip, the kernel consumed about 50% of the CPU time ( /proc/cpuinfo and /proc/interrupts follow). Any ideas ? shtajga:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 548.545 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 psn mmx fxsr xmm bogomips: 1094.45 shtajga:~# cat /proc/interrupts CPU0 0: 32765032 XT-PIC timer 1: 227971 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 42658190 XT-PIC serial 4: 518726307 XT-PIC serial 7: 45966 XT-PIC parport0 8: 1 XT-PIC rtc 9: 15292 XT-PIC eth0 10: 21984776 XT-PIC eth1 11:1534661 XT-PIC sm200 12: 498413 XT-PIC PS/2 Mouse 13: 1 XT-PIC fpu 14: 18221483 XT-PIC ide0 15: 8 XT-PIC ide1 NMI: 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM-global-2.2.18pre17-7
>The Becker's driver from ftp://ftp.scyld.com/pub/network/eepro100.c cures >the error messages, but the network still stalls, and worse yet, seems to >stall forever (as opposed to few minutes with 2.2.18pre17 driver). this eepro100.c works for me asus/dual piii-800 133mhz/768ram ecc/mylex-170/2x18Go thanks for your help. Octave - To unsubscribe from this list: send 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.0test5 make dep errors
On Fri, 27 Oct 2000 13:01:32 +0200, Markus hennig <[EMAIL PROTECTED]> wrote: >config.c:311: #error "HiSax: No cards configured" >su.c:75: asm/oplib.h: No such file or directory >su.c:77: asm/ebus.h: No such file or directory >newport.c:11: asm/gfx.h: No such file or directory >newport.c:12: asm/ng1.h: No such file or directory >tcsyms.c:7: asm/dec/tc.h: No such file or directory >zorro.c:20: asm/amigahw.h: No such file or directory All (unfortunately) normal because make dep scans all source before any generated .h files are created. Ignore, will be fixed in 2.5. >/usr/src/linux/Rules.make:145: target `_subdir_sched' given more than >once in the same rule. Annoying but AFAIK it is harmless. Also to be fixed in 2.5. - To unsubscribe from this list: send 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: RTNL assert
"Stephen E. Clark" wrote: > > When I configure in Tunneling I get the following error message. Is this > normal? This with 2.4test9pre5 > > GRE over IPv4 tunneling driver > RTNL: assertion failed at devinet.c(775):inetdev_event The rtnetlink lock needs to be taken around register_netdevice(). There should be a function which does these three common steps, but there isn't. --- linux-2.4.0-test10-pre5/net/ipv4/ip_gre.c Sat Sep 9 16:19:30 2000 +++ linux-akpm/net/ipv4/ip_gre.cSat Oct 28 21:44:23 2000 @@ -1266,7 +1266,9 @@ #ifdef MODULE register_netdev(_fb_tunnel_dev); #else + rtnl_lock(); register_netdevice(_fb_tunnel_dev); + rtnl_unlock(); #endif inet_add_protocol(_protocol); - To unsubscribe from this list: send 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: [drm:drm_release] *ERROR* Process 256 dead
On Mon, Oct 23, 2000 at 11:22:53PM -0400, Burton Windle wrote: > Sorry if this is user-error, but after about 20min of using > 2.4.0-test10-pre5, my Debian Woody system dropped out of X with this > message in syslog: > > [drm:drm_release] *ERROR* Process 256 dead, freeing lock for context 1 > > I've never seen this before; I had been using test10-pre4 for several days > without error. > > Is this a kernel bugglet/error, or X? Could you please send me the /var/log/XFree86.0.log from the crash, as well as your /etc/X11/XF86Config-4? Thanks. Zephaniah E. Hull. (The Debian 3Dfx guy, who generally does not do X, but gets to anyways) > > -- > Burton Windle [EMAIL PROTECTED] > Linux: the "grim reaper of innocent orphaned children." > from /usr/src/linux/init/main.c:1384 - To unsubscribe from this list: send 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] fix ambiguous PTRACE_SYSCALL tracing
Linus,
This patch allows a (ptrace) parent to unambiguously distinguish between a
child ptrace stop following a PTRACE_SYSCALL due to a system call and a ptrace
stop due to delivery of a SIGTRAP.
Currently, when PTRACE_SYSCALL is being used, it's not possible to tell for
certain why a particular ptrace stop happens. The workaround is to check the
"wait channel" of the stopped process, but this is ugly and slow.
This patch is of benefit to all users of PTRACE_SYSCALL (strace, SUBTERFUGUE,
etc).
The new functionality is enabled on a per-child basis by the ptrace'ing
parent, and is disabled by default, thus preserving full backward
compatibility with existing versions of strace.
--Mike
P.S. Even if you disallow the patch, you may want to look at the first
chunk. I believe this change was missed when the ptrace flag field was added
recently.
diff -aur linux/arch/i386/kernel/ptrace.c linux-2.4.0-test9/arch/i386/kernel/ptrace.c
--- linux/arch/i386/kernel/ptrace.c Fri Sep 22 14:25:19 2000
+++ linux-2.4.0-test9/arch/i386/kernel/ptrace.c Thu Oct 19 23:20:58 2000
@@ -351,7 +351,7 @@
ret = -EIO;
if ((unsigned long) data > _NSIG)
break;
- child->ptrace &= ~(PT_PTRACED|PT_TRACESYS);
+ child->ptrace = 0;
child->exit_code = data;
write_lock_irq(_lock);
REMOVE_LINKS(child);
@@ -451,6 +451,15 @@
break;
}
+ case PTRACE_SETOPTIONS: {
+ if (data & PTRACE_O_TRACESYSGOOD)
+ child->ptrace |= PT_TRACESYSGOOD;
+ else
+ child->ptrace &= ~PT_TRACESYSGOOD;
+ ret = 0;
+ break;
+ }
+
default:
ret = -EIO;
break;
@@ -467,7 +476,10 @@
if ((current->ptrace & (PT_PTRACED|PT_TRACESYS)) !=
(PT_PTRACED|PT_TRACESYS))
return;
- current->exit_code = SIGTRAP;
+ /* the 0x80 provides a way for the tracing parent to distinguish
+ between a syscall stop and SIGTRAP delivery */
+ current->exit_code = SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
+ ? 0x80 : 0);
current->state = TASK_STOPPED;
notify_parent(current, SIGCHLD);
schedule();
diff -aur linux/include/asm-i386/ptrace.h linux-2.4.0-test9/include/asm-i386/ptrace.h
--- linux/include/asm-i386/ptrace.h Wed Jun 21 22:59:38 2000
+++ linux-2.4.0-test9/include/asm-i386/ptrace.h Thu Oct 19 23:12:35 2000
@@ -49,6 +49,11 @@
#define PTRACE_GETFPXREGS 18
#define PTRACE_SETFPXREGS 19
+#define PTRACE_SETOPTIONS 21
+
+/* options set using PTRACE_SETOPTIONS */
+#define PTRACE_O_TRACESYSGOOD 0x0001
+
#ifdef __KERNEL__
#define user_mode(regs) ((VM_MASK & (regs)->eflags) || (3 & (regs)->xcs))
#define instruction_pointer(regs) ((regs)->eip)
-
To unsubscribe from this list: send 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] Make agpsupport work with modversions
On Sat, 28 Oct 2000 11:02:04 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote: >> of get_module_symbol this weekend. The inter-object registration code >> will allow two objects to pass data to each other, it will not matter >> whether the objects are both modules, one module and one built in (in >> either order) or both built in. When modules are involved there will >> be full module locking. > >Dont forget that one of the objects may not even be present, or may be >loaded later. How could I forget it? You have defined the heart of the problem, either object might be built into the kernel, might be a module or might not even be there, in any case the load order is undefined. That is why existing code is kludging things by using get_module_symbol(). inter_module_register, unregister, get, put will solve the inter object problem but using a clean interface that works with symbol versions. - To unsubscribe from this list: send 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] Make agpsupport work with modversions
> Linus wants get_module_symbol removed. > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg08791.html Looks to me like Linus asks if some stuff can go away. I don't see a Linus comment on the rest of the discussion about why removing it is bad at all. And by Linus own rules. Its too late for 2.4 unless you can make Ted agree its a critical fix 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: [PATCH] Make agpsupport work with modversions
> of get_module_symbol this weekend. The inter-object registration code > will allow two objects to pass data to each other, it will not matter > whether the objects are both modules, one module and one built in (in > either order) or both built in. When modules are involved there will > be full module locking. Dont forget that one of the objects may not even be present, or may be loaded later. - To unsubscribe from this list: send 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] Make agpsupport work with modversions
On Sat, 28 Oct 2000 05:40:28 -0400 (EDT), Alan Cox <[EMAIL PROTECTED]> wrote: >> cc list trimmed. Nobody has come up with a "must have" reason for >> get_module_symbol and that interface is broken as designed. I will be > >Nobody has come up with a 'must break existing sane code' reason either. Existing code is not sane, it does not work with symbol versions. The only code left in the kernel that uses get_module_symbol is agp, drm and mtd, all of which I will be fixing at the same time. >> will allow two objects to pass data to each other, it will not matter >> whether the objects are both modules, one module and one built in (in >> either order) or both built in. When modules are involved there will >> be full module locking. > >You have no consensus on this. None at all. It is also past the 2.4test >point for making this change. Linus wants get_module_symbol removed. http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg08791.html - To unsubscribe from this list: send 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] Make agpsupport work with modversions
> cc list trimmed. Nobody has come up with a "must have" reason for > get_module_symbol and that interface is broken as designed. I will be Nobody has come up with a 'must break existing sane code' reason either. > will allow two objects to pass data to each other, it will not matter > whether the objects are both modules, one module and one built in (in > either order) or both built in. When modules are involved there will > be full module locking. You have no consensus on this. None at all. It is also past the 2.4test point for making this change. 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: pcmcia in test10pre6
Jonathan Hudson wrote: > In article <[EMAIL PROTECTED]>, > "Jeff V. Merkey" <[EMAIL PROTECTED]> writes: > > JVM> Grab the pcmcia off sourceforge. It seems to build and work. The stuff > JVM> in 2.4 at present is still somewhat broken. I worked on this until 2:00 > JVM> last night getting it to build with 2.4. > > Couldn't get 3.1.21 to build (you using something later from CVS ?). [ > CONFIG_X86_L1_CACHE_SHIFT not defined in the right places]. > > Droping the test5 modules/drivers into the pcmcia modules directory > works fine. 10-6 includes and DH pcmcia simply don't get along, for some reason several of the client drivers in the pcmcia package don't compile due to the above not being defined. I hacked it in for my copy simply because I needed it right then and there. I -don't- have an acceptable patch. What I have is a gross include-until-it-works. -d -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Obviously-correct patch to 2.2.17
Hi Alan. This patch simply corrects a couple of comments in the said file to reflect what the code actually does rather than (presumably) what the code used to do at some time in the distant past. In my case, I've been working on a patch for the kernel that uses these facilities, and was getting confused because of the discrepancy between what the comments say and what actually happens. It wasn't until I realised that the comments were just plain wrong that I was able to sort the thing out, so I'm submitting this patch to prevent others having the same problem. Incidentally, the code as it stands actually simplifies the patch I was working on considerably, and I regard this as a useful feature as a result. I don't have the latest 2.4-pre kernel to hand to check, but it's quite likely that this patch can also be applied to that with the same results. Best wishes from Riley. * Copyright (C) 2000, Memory Alpha Systems. * All rights and wrongs reserved. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * http://www.memalpha.cx/Linux/Kernel/ --- linux-2.2.17/kernel/printk.c~ Wed Oct 27 01:53:42 1999 +++ linux-2.2.17/kernel/printk.cSat Oct 28 10:01:20 2000 @@ -109,12 +109,12 @@ * Commands to do_syslog: * * 0 -- Close the log. Currently a NOP. * 1 -- Open the log. Currently a NOP. * 2 -- Read from the log. - * 3 -- Read up to the last 4k of messages in the ring buffer. + * 3 -- Read all messages remaining in the ring buffer. - * 4 -- Read and clear last 4k of messages in the ring buffer + * 4 -- Read and clear all messages remaining in the ring buffer * 5 -- Clear ring buffer. * 6 -- Disable printk's to console * 7 -- Enable printk's to console * 8 -- Set level of messages printed to console */
Re: patch: atapi dvd-ram support
On Sat, Oct 28 2000, Andre Hedrick wrote: > > This is not necessary, the ide-cd driver will set the read-only > > flag appropriately depending on the device type detected. > > This may not be the best option as the default. > If a dvd-ram is used for backup you may not always want it in RW mode. > Just a thought. Just mount it ro then? -- * 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: patch: atapi dvd-ram support
On Sat, 28 Oct 2000, Jens Axboe wrote: > This is not necessary, the ide-cd driver will set the read-only > flag appropriately depending on the device type detected. This may not be the best option as the default. If a dvd-ram is used for backup you may not always want it in RW mode. Just a thought. Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send 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: atapi dvd-ram support
On Fri, Oct 27 2000, Andre Hedrick wrote: > hdparm -r0 /dev/hdc [snip] > That is how it is DONE! This is not necessary, the ide-cd driver will set the read-only flag appropriately depending on the device type detected. -- * 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: patch: atapi dvd-ram support
On Sat, Oct 28 2000, Hisaaki Shibata wrote:
> I did patch 2.2.17 tree with dvd-ram-2217p17.diff.bz2.
>
> At that time, following patch is rejected.
> I think these lines should be removed from patchs.
>
> @@ -1329,7 +1369,7 @@
>static
> void cdrom_sleep (int time)
> {
> - current->state = TASK_INTERRUPTIBLE;
> + __set_current_state(TASK_INTERRUPTIBLE);
> schedule_timeout(time);
> }
>
> After removing these, I could make bzImage.
Weird, should not reject. Oh well.
> But I could not mkudf nor mkext2fs to my ATAPI 9.4GB new DVD-RAM drive.
What do you mean? What happened? strace of mke2fs of mkudf would
be nice to have.
--
* 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: [PATCH] Make agpsupport work with modversions
Keith Owens wrote:
>
> I will be adding generic inter-object registration code and removing
> all vestiges of get_module_symbol this weekend.
While you're there, why not eradicate sys_get_kernel_syms()?
Also, I've been sitting on (and using) this sys_init_init_module()
bugfix for two months. The explanation is at
http://www.uwsg.iu.edu/hypermail/linux/kernel/0008.3/0379.html
Perhaps now is a good time to merge it?
--- linux-2.4.0-test10-pre5/kernel/module.c Tue Oct 24 21:34:13 2000
+++ linux-akpm/kernel/module.c Wed Oct 25 22:11:46 2000
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
/*
* Originally by Anonymous (as far as I know...)
@@ -151,7 +152,7 @@
sys_init_module(const char *name_user, struct module *mod_user)
{
struct module mod_tmp, *mod;
- char *name, *n_name;
+ char *name, *n_name, *name_tmp = 0;
long namelen, n_namelen, i, error;
unsigned long mod_user_size;
struct module_ref *dep;
@@ -185,6 +186,12 @@
/* Hold the current contents while we play with the user's idea
of righteousness. */
mod_tmp = *mod;
+ name_tmp = kmalloc(strlen(mod->name) + 1, GFP_KERNEL); /* Where's kstrdup()?
+*/
+ if (name_tmp == NULL) {
+ error = -ENOMEM;
+ goto err1;
+ }
+ strcpy(name_tmp, mod->name);
error = copy_from_user(mod, mod_user, sizeof(struct module));
if (error) {
@@ -281,9 +288,10 @@
to make the I and D caches consistent. */
flush_icache_range((unsigned long)mod, (unsigned long)mod + mod->size);
- /* Update module references. */
mod->next = mod_tmp.next;
mod->refs = NULL;
+
+ /* Sanity check the module's dependents */
for (i = 0, dep = mod->deps; i < mod->ndeps; ++i, ++dep) {
struct module *o, *d = dep->dep;
@@ -294,14 +302,21 @@
goto err3;
}
- for (o = module_list; o != _module; o = o->next)
- if (o == d) goto found_dep;
+ /* Scan the current modules for this dependency */
+ for (o = module_list; o != _module && o != d; o = o->next)
+ ;
- printk(KERN_ERR "init_module: found dependency that is "
+ if (o != d) {
+ printk(KERN_ERR "init_module: found dependency that is "
"(no longer?) a module.\n");
- goto err3;
-
- found_dep:
+ goto err3;
+ }
+ }
+
+ /* Update module references. */
+ for (i = 0, dep = mod->deps; i < mod->ndeps; ++i, ++dep) {
+ struct module *d = dep->dep;
+
dep->ref = mod;
dep->next_ref = d->refs;
d->refs = dep;
@@ -335,10 +350,12 @@
put_mod_name(n_name);
err2:
*mod = mod_tmp;
+ strcpy((char *)mod->name, name_tmp);/* We know there is room for this */
err1:
put_mod_name(name);
err0:
unlock_kernel();
+ kfree(name_tmp);
return error;
}
-
To unsubscribe from this list: send 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] a buglet in fbcon_getxy
This is probably responsible for
http://bugs.debian.org/72378
The patch should apply cleanly for both 2.2 and 2.4 test.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Index: drivers/video/fbcon.c
===
RCS file: /home/gondor/herbert/src/CVS/debian/kernel-source/drivers/video/fbcon.c,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 fbcon.c
--- drivers/video/fbcon.c 2000/09/04 17:39:22 1.1.1.5
+++ drivers/video/fbcon.c 2000/10/28 04:50:14
@@ -1806,12 +1806,13 @@
y += softback_lines;
ret = pos + (conp->vc_cols - x) * 2;
} else if (conp->vc_num == fg_console && softback_lines) {
- unsigned long offset = (pos - softback_curr) / 2;
+ unsigned long offset = pos - softback_curr;
+ if (pos < softback_curr)
+ offset += softback_end - softback_buf;
+ offset /= 2;
x = offset % conp->vc_cols;
y = offset / conp->vc_cols;
- if (pos < softback_curr)
- y += (softback_end - softback_buf) / conp->vc_size_row;
ret = pos + (conp->vc_cols - x) * 2;
if (ret == softback_end)
ret = softback_buf;
Re: kqueue microbenchmark resul
>In fact, if you did leave the read queued in a daemon using select() >before, you'd keep looping endlessly taking all CPU and never idle >because there would always be read data available. Also, level triggered notifications would also seem to cause multiple thread wakeups and thundering herd problems when there are multiple worker threads reading from the same queue. How does (?) kevent avoid this from happening? Mark -- ... recursive make suxx! [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: kqueue microbenchmark resul
In fact, if you did leave the read queued in a daemon using select() before, you'd keep looping endlessly taking all CPU and never idle because there would always be read data available. Also, level triggered notifications would also seem to cause multiple thread wakeups and thundering herd problems when there are multiple worker threads reading from the same queue. How does (?) kevent avoid this from happening? Mark -- ... recursive make suxx! [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] a buglet in fbcon_getxy
This is probably responsible for
http://bugs.debian.org/72378
The patch should apply cleanly for both 2.2 and 2.4 test.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Index: drivers/video/fbcon.c
===
RCS file: /home/gondor/herbert/src/CVS/debian/kernel-source/drivers/video/fbcon.c,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 fbcon.c
--- drivers/video/fbcon.c 2000/09/04 17:39:22 1.1.1.5
+++ drivers/video/fbcon.c 2000/10/28 04:50:14
@@ -1806,12 +1806,13 @@
y += softback_lines;
ret = pos + (conp-vc_cols - x) * 2;
} else if (conp-vc_num == fg_console softback_lines) {
- unsigned long offset = (pos - softback_curr) / 2;
+ unsigned long offset = pos - softback_curr;
+ if (pos softback_curr)
+ offset += softback_end - softback_buf;
+ offset /= 2;
x = offset % conp-vc_cols;
y = offset / conp-vc_cols;
- if (pos softback_curr)
- y += (softback_end - softback_buf) / conp-vc_size_row;
ret = pos + (conp-vc_cols - x) * 2;
if (ret == softback_end)
ret = softback_buf;
Re: [PATCH] Make agpsupport work with modversions
Keith Owens wrote:
I will be adding generic inter-object registration code and removing
all vestiges of get_module_symbol this weekend.
While you're there, why not eradicate sys_get_kernel_syms()?
Also, I've been sitting on (and using) this sys_init_init_module()
bugfix for two months. The explanation is at
http://www.uwsg.iu.edu/hypermail/linux/kernel/0008.3/0379.html
Perhaps now is a good time to merge it?
--- linux-2.4.0-test10-pre5/kernel/module.c Tue Oct 24 21:34:13 2000
+++ linux-akpm/kernel/module.c Wed Oct 25 22:11:46 2000
@@ -6,6 +6,7 @@
#include linux/smp_lock.h
#include asm/pgalloc.h
#include linux/init.h
+#include linux/slab.h
/*
* Originally by Anonymous (as far as I know...)
@@ -151,7 +152,7 @@
sys_init_module(const char *name_user, struct module *mod_user)
{
struct module mod_tmp, *mod;
- char *name, *n_name;
+ char *name, *n_name, *name_tmp = 0;
long namelen, n_namelen, i, error;
unsigned long mod_user_size;
struct module_ref *dep;
@@ -185,6 +186,12 @@
/* Hold the current contents while we play with the user's idea
of righteousness. */
mod_tmp = *mod;
+ name_tmp = kmalloc(strlen(mod-name) + 1, GFP_KERNEL); /* Where's kstrdup()?
+*/
+ if (name_tmp == NULL) {
+ error = -ENOMEM;
+ goto err1;
+ }
+ strcpy(name_tmp, mod-name);
error = copy_from_user(mod, mod_user, sizeof(struct module));
if (error) {
@@ -281,9 +288,10 @@
to make the I and D caches consistent. */
flush_icache_range((unsigned long)mod, (unsigned long)mod + mod-size);
- /* Update module references. */
mod-next = mod_tmp.next;
mod-refs = NULL;
+
+ /* Sanity check the module's dependents */
for (i = 0, dep = mod-deps; i mod-ndeps; ++i, ++dep) {
struct module *o, *d = dep-dep;
@@ -294,14 +302,21 @@
goto err3;
}
- for (o = module_list; o != kernel_module; o = o-next)
- if (o == d) goto found_dep;
+ /* Scan the current modules for this dependency */
+ for (o = module_list; o != kernel_module o != d; o = o-next)
+ ;
- printk(KERN_ERR "init_module: found dependency that is "
+ if (o != d) {
+ printk(KERN_ERR "init_module: found dependency that is "
"(no longer?) a module.\n");
- goto err3;
-
- found_dep:
+ goto err3;
+ }
+ }
+
+ /* Update module references. */
+ for (i = 0, dep = mod-deps; i mod-ndeps; ++i, ++dep) {
+ struct module *d = dep-dep;
+
dep-ref = mod;
dep-next_ref = d-refs;
d-refs = dep;
@@ -335,10 +350,12 @@
put_mod_name(n_name);
err2:
*mod = mod_tmp;
+ strcpy((char *)mod-name, name_tmp);/* We know there is room for this */
err1:
put_mod_name(name);
err0:
unlock_kernel();
+ kfree(name_tmp);
return error;
}
-
To unsubscribe from this list: send 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: atapi dvd-ram support
On Sat, Oct 28 2000, Hisaaki Shibata wrote:
I did patch 2.2.17 tree with dvd-ram-2217p17.diff.bz2.
At that time, following patch is rejected.
I think these lines should be removed from patchs.
@@ -1329,7 +1369,7 @@
static
void cdrom_sleep (int time)
{
- current-state = TASK_INTERRUPTIBLE;
+ __set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(time);
}
After removing these, I could make bzImage.
Weird, should not reject. Oh well.
But I could not mkudf nor mkext2fs to my ATAPI 9.4GB new DVD-RAM drive.
What do you mean? What happened? strace of mke2fs of mkudf would
be nice to have.
--
* 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: patch: atapi dvd-ram support
On Fri, Oct 27 2000, Andre Hedrick wrote: hdparm -r0 /dev/hdc [snip] That is how it is DONE! This is not necessary, the ide-cd driver will set the read-only flag appropriately depending on the device type detected. -- * 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: patch: atapi dvd-ram support
On Sat, 28 Oct 2000, Jens Axboe wrote: This is not necessary, the ide-cd driver will set the read-only flag appropriately depending on the device type detected. This may not be the best option as the default. If a dvd-ram is used for backup you may not always want it in RW mode. Just a thought. Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send 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: atapi dvd-ram support
On Sat, Oct 28 2000, Andre Hedrick wrote: This is not necessary, the ide-cd driver will set the read-only flag appropriately depending on the device type detected. This may not be the best option as the default. If a dvd-ram is used for backup you may not always want it in RW mode. Just a thought. Just mount it ro then? -- * 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/
Obviously-correct patch to 2.2.17
Hi Alan. This patch simply corrects a couple of comments in the said file to reflect what the code actually does rather than (presumably) what the code used to do at some time in the distant past. In my case, I've been working on a patch for the kernel that uses these facilities, and was getting confused because of the discrepancy between what the comments say and what actually happens. It wasn't until I realised that the comments were just plain wrong that I was able to sort the thing out, so I'm submitting this patch to prevent others having the same problem. Incidentally, the code as it stands actually simplifies the patch I was working on considerably, and I regard this as a useful feature as a result. I don't have the latest 2.4-pre kernel to hand to check, but it's quite likely that this patch can also be applied to that with the same results. Best wishes from Riley. * Copyright (C) 2000, Memory Alpha Systems. * All rights and wrongs reserved. +--+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this feature, but I bet someone | | else has already done so and is just about to release their patch. | +--+ * http://www.memalpha.cx/Linux/Kernel/ --- linux-2.2.17/kernel/printk.c~ Wed Oct 27 01:53:42 1999 +++ linux-2.2.17/kernel/printk.cSat Oct 28 10:01:20 2000 @@ -109,12 +109,12 @@ * Commands to do_syslog: * * 0 -- Close the log. Currently a NOP. * 1 -- Open the log. Currently a NOP. * 2 -- Read from the log. - * 3 -- Read up to the last 4k of messages in the ring buffer. + * 3 -- Read all messages remaining in the ring buffer. - * 4 -- Read and clear last 4k of messages in the ring buffer + * 4 -- Read and clear all messages remaining in the ring buffer * 5 -- Clear ring buffer. * 6 -- Disable printk's to console * 7 -- Enable printk's to console * 8 -- Set level of messages printed to console */
Re: pcmcia in test10pre6
Jonathan Hudson wrote: In article [EMAIL PROTECTED], "Jeff V. Merkey" [EMAIL PROTECTED] writes: JVM Grab the pcmcia off sourceforge. It seems to build and work. The stuff JVM in 2.4 at present is still somewhat broken. I worked on this until 2:00 JVM last night getting it to build with 2.4. Couldn't get 3.1.21 to build (you using something later from CVS ?). [ CONFIG_X86_L1_CACHE_SHIFT not defined in the right places]. Droping the test5 modules/drivers into the pcmcia modules directory works fine. 10-6 includes and DH pcmcia simply don't get along, for some reason several of the client drivers in the pcmcia package don't compile due to the above not being defined. I hacked it in for my copy simply because I needed it right then and there. I -don't- have an acceptable patch. What I have is a gross include-until-it-works. -d -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President - To unsubscribe from this list: send 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] Make agpsupport work with modversions
cc list trimmed. Nobody has come up with a "must have" reason for get_module_symbol and that interface is broken as designed. I will be Nobody has come up with a 'must break existing sane code' reason either. will allow two objects to pass data to each other, it will not matter whether the objects are both modules, one module and one built in (in either order) or both built in. When modules are involved there will be full module locking. You have no consensus on this. None at all. It is also past the 2.4test point for making this change. 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: [PATCH] Make agpsupport work with modversions
On Sat, 28 Oct 2000 05:40:28 -0400 (EDT), Alan Cox [EMAIL PROTECTED] wrote: cc list trimmed. Nobody has come up with a "must have" reason for get_module_symbol and that interface is broken as designed. I will be Nobody has come up with a 'must break existing sane code' reason either. Existing code is not sane, it does not work with symbol versions. The only code left in the kernel that uses get_module_symbol is agp, drm and mtd, all of which I will be fixing at the same time. will allow two objects to pass data to each other, it will not matter whether the objects are both modules, one module and one built in (in either order) or both built in. When modules are involved there will be full module locking. You have no consensus on this. None at all. It is also past the 2.4test point for making this change. Linus wants get_module_symbol removed. http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg08791.html - To unsubscribe from this list: send 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] Make agpsupport work with modversions
of get_module_symbol this weekend. The inter-object registration code will allow two objects to pass data to each other, it will not matter whether the objects are both modules, one module and one built in (in either order) or both built in. When modules are involved there will be full module locking. Dont forget that one of the objects may not even be present, or may be loaded later. - To unsubscribe from this list: send 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] Make agpsupport work with modversions
Linus wants get_module_symbol removed. http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg08791.html Looks to me like Linus asks if some stuff can go away. I don't see a Linus comment on the rest of the discussion about why removing it is bad at all. And by Linus own rules. Its too late for 2.4 unless you can make Ted agree its a critical fix 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/
