* Re: "bio too big" error
From: Wil Reichert @ 2002-12-11 13:40 UTC (permalink / raw)
To: Greg KH; +Cc: Andrew Morton, Jens Axboe, linux-kernel
In-Reply-To: <20021211051100.GA13718@kroah.com>
> Did you try the dm patches that were just posted to lkml today?
Just subscribed today, missed 'em. You're refering to
http://people.sistina.com/~thornber/patches/2.5-stable/2.5.50/2.5.50-dm-2.tar.bz2 ?
They result in:
darwin:~# /etc/init.d/lvm2 start
Initializing LVM: device-mapper: device /dev/discs/disc4/disc too small
for target
device-mapper: internal error adding target to table
device-mapper: destroying table
device-mapper ioctl cmd 2 failed: Invalid argument
Couldn't load device 'cheese_vg-blah'.
0 logical volume(s) in volume group "cheese_vg" now active
lvm2.
Guess I'll give 2.5.51 w/ the dm patches a shot.
Wil
^ permalink raw reply
* Re: [Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
From: Keith Whitwell @ 2002-12-11 13:40 UTC (permalink / raw)
To: Dave Jones
Cc: Nicolas ASPERT, Margit Schubert-While, linux-kernel, faith,
dri-devel
In-Reply-To: <20021211140504.D11689@suse.de>
[-- Attachment #1: Type: text/plain, Size: 393 bytes --]
Dave Jones wrote:
> On Wed, Dec 11, 2002 at 12:45:49PM +0000, Keith Whitwell wrote:
> > In any case I don't think the string in the informational is very useful --
> > it's a potentially inaccurate translation of state from *another* module, so
> > I'm just removing the lot.
>
> Cool, that gets my vote too 8-)
>
> Dave
>
Here's the changes I've committed to dri cvs.
Keith
[-- Attachment #2: drm-agp-info.diff --]
[-- Type: text/plain, Size: 3831 bytes --]
? diff
Index: drmP.h
===================================================================
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drmP.h,v
retrieving revision 1.54
diff -u -r1.54 drmP.h
--- drmP.h 3 Dec 2002 00:43:47 -0000 1.54
+++ drmP.h 11 Dec 2002 13:29:18 -0000
@@ -488,7 +488,6 @@
typedef struct drm_agp_head {
agp_kern_info agp_info;
- const char *chipset;
drm_agp_mem_t *memory;
unsigned long mode;
int enabled;
Index: drm_agpsupport.h
===================================================================
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_agpsupport.h,v
retrieving revision 1.9
diff -u -r1.9 drm_agpsupport.h
--- drm_agpsupport.h 22 Aug 2002 19:35:31 -0000 1.9
+++ drm_agpsupport.h 11 Dec 2002 13:29:18 -0000
@@ -260,60 +260,6 @@
return NULL;
}
head->memory = NULL;
- switch (head->agp_info.chipset) {
- case INTEL_GENERIC: head->chipset = "Intel"; break;
- case INTEL_LX: head->chipset = "Intel 440LX"; break;
- case INTEL_BX: head->chipset = "Intel 440BX"; break;
- case INTEL_GX: head->chipset = "Intel 440GX"; break;
- case INTEL_I810: head->chipset = "Intel i810"; break;
-
- case INTEL_I815: head->chipset = "Intel i815"; break;
-#if LINUX_VERSION_CODE >= 0x02040f /* KERNEL_VERSION(2,4,15) */
- case INTEL_I820: head->chipset = "Intel i820"; break;
-#endif
- case INTEL_I840: head->chipset = "Intel i840"; break;
-#if LINUX_VERSION_CODE >= 0x02040f /* KERNEL_VERSION(2,4,15) */
- case INTEL_I845: head->chipset = "Intel i845"; break;
-#endif
- case INTEL_I850: head->chipset = "Intel i850"; break;
-
- case VIA_GENERIC: head->chipset = "VIA"; break;
- case VIA_VP3: head->chipset = "VIA VP3"; break;
- case VIA_MVP3: head->chipset = "VIA MVP3"; break;
- case VIA_MVP4: head->chipset = "VIA MVP4"; break;
- case VIA_APOLLO_KX133: head->chipset = "VIA Apollo KX133";
- break;
- case VIA_APOLLO_KT133: head->chipset = "VIA Apollo KT133";
- break;
-
- case VIA_APOLLO_PRO: head->chipset = "VIA Apollo Pro";
- break;
- case SIS_GENERIC: head->chipset = "SiS"; break;
- case AMD_GENERIC: head->chipset = "AMD"; break;
- case AMD_IRONGATE: head->chipset = "AMD Irongate"; break;
- case ALI_GENERIC: head->chipset = "ALi"; break;
- case ALI_M1541: head->chipset = "ALi M1541"; break;
-
-#if LINUX_VERSION_CODE >= 0x020402
- case ALI_M1621: head->chipset = "ALi M1621"; break;
- case ALI_M1631: head->chipset = "ALi M1631"; break;
- case ALI_M1632: head->chipset = "ALi M1632"; break;
- case ALI_M1641: head->chipset = "ALi M1641"; break;
- case ALI_M1647: head->chipset = "ALi M1647"; break;
- case ALI_M1651: head->chipset = "ALi M1651"; break;
-#endif
-
-#if LINUX_VERSION_CODE >= 0x020406
- case SVWRKS_HE: head->chipset = "Serverworks HE";
- break;
- case SVWRKS_LE: head->chipset = "Serverworks LE";
- break;
- case SVWRKS_GENERIC: head->chipset = "Serverworks Generic";
- break;
-#endif
-
- default: head->chipset = "Unknown"; break;
- }
#if LINUX_VERSION_CODE <= 0x020408
head->cant_use_aperture = 0;
head->page_mask = ~(0xfff);
@@ -321,13 +267,12 @@
head->cant_use_aperture = head->agp_info.cant_use_aperture;
head->page_mask = head->agp_info.page_mask;
#endif
-
- DRM_INFO("AGP %d.%d on %s @ 0x%08lx %ZuMB\n",
- head->agp_info.version.major,
- head->agp_info.version.minor,
- head->chipset,
- head->agp_info.aper_base,
- head->agp_info.aper_size);
+
+ DRM_DEBUG("AGP %d.%d, aperture @ 0x%08lx %ZuMB\n",
+ head->agp_info.version.major,
+ head->agp_info.version.minor,
+ head->agp_info.aper_base,
+ head->agp_info.aper_size);
}
return head;
}
^ permalink raw reply
* Re: [PATCH] dm.c - device-mapper I/O path fixes
From: Denis Vlasenko @ 2002-12-11 18:19 UTC (permalink / raw)
To: Joe Thornber; +Cc: Kevin Corry, Linus Torvalds, Kernel Mailing List, lvm-devel
In-Reply-To: <20021211121915.GB20782@reti>
On 11 December 2002 10:19, Joe Thornber wrote:
> dec_pending(): only bother spin locking if io->error is going to be
> updated. [Kevin Corry]
>
> --- diff/drivers/md/dm.c 2002-12-11 12:00:29.000000000 +0000
> +++ source/drivers/md/dm.c 2002-12-11 12:00:34.000000000 +0000
> @@ -238,10 +238,11 @@
> static spinlock_t _uptodate_lock = SPIN_LOCK_UNLOCKED;
> unsigned long flags;
>
> - spin_lock_irqsave(&_uptodate_lock, flags);
> - if (error)
> + if (error) {
> + spin_lock_irqsave(&_uptodate_lock, flags);
> io->error = error;
> - spin_unlock_irqrestore(&_uptodate_lock, flags);
> + spin_unlock_irqrestore(&_uptodate_lock, flags);
> + }
>
> if (atomic_dec_and_test(&io->io_count)) {
> if (atomic_dec_and_test(&io->md->pending))
This seems pointless, end result:
spin_lock_irqsave(&_uptodate_lock, flags);
io->error = error;
spin_unlock_irqrestore(&_uptodate_lock, flags);
BTW, the function we are looking at:
static inline void dec_pending(struct dm_io *io, int error)
^^^^^^
is too big for inlining.
--
vda
^ permalink raw reply
* Re: patch for aty128fb.c
From: James Simmons @ 2002-12-11 14:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-kernel
In-Reply-To: <15863.9692.239964.520652@argo.ozlabs.ibm.com>
Applied :-)
^ permalink raw reply
* RE: Is this going to be true ?
From: Rik van Riel @ 2002-12-11 13:41 UTC (permalink / raw)
To: Joseph D. Wagner; +Cc: 'Serge Kuznetsov', linux-kernel
In-Reply-To: <001801c2a0a9$02613f40$2e863841@joe>
On Tue, 10 Dec 2002, Joseph D. Wagner wrote:
> > Research Firm: Microsoft Will Use Linux by 2004:
> > [trim]
>
> Over Bill Gates' dead body. The Microsoft Corporation is of the genuine
> belief that Microsoft Windows is the operating system of the future.
Wait a moment, didn't they say that OS/2 was the operating
system of the future ?
And what about that overly complex internet thingy, that'd
never take off, people would use MSN instead.
We have always been at war with Oceania.
> The following scenarios are far more likely.
They'll have no choice but to follow their customers around.
A corporation can't exist without clients.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://guru.conectiva.com/
Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a>
^ permalink raw reply
* Error compiling iptables-1.2.7a
From: Rob Sterenborg @ 2002-12-11 13:36 UTC (permalink / raw)
To: 'Netfilter (netfilter@lists.netfilter.org)'
[-- Attachment #1: Type: text/plain, Size: 3240 bytes --]
Hi,
I tried to compile :
- kernel-2.4.20
- Patched with POM-20021208
- iptables-1.2.7a
Compiling the kernel is no problem.
When executing KERNEL_DIR=/data/download/kernel/linux-2.4.20 make, I get
this error :
ld -shared -o extensions/libipt_quota.so extensions/libipt_quota_sh.o
cc -O2 -Wall -Wunused -I/data/download/kernel/linux-2.4.20/include
-Iinclude/ -DIPTABLES_VERSION=\"1.2.7a\" -fPIC -o
extensions/libipt_ROUTE_sh.o -c extensions/libipt_ROUTE.c
extensions/libipt_ROUTE.c: In function `parse':
extensions/libipt_ROUTE.c:61: structure has no member named `if_name'
extensions/libipt_ROUTE.c:64: structure has no member named `if_name'
extensions/libipt_ROUTE.c:66: structure has no member named `if_name'
extensions/libipt_ROUTE.c:66: structure has no member named `if_name'
extensions/libipt_ROUTE.c:66: structure has no member named `if_name'
extensions/libipt_ROUTE.c:67: structure has no member named `if_index'
extensions/libipt_ROUTE.c:80: structure has no member named `if_name'
extensions/libipt_ROUTE.c:81: structure has no member named `if_index'
extensions/libipt_ROUTE.c:86: structure has no member named `if_index'
extensions/libipt_ROUTE.c: In function `print':
extensions/libipt_ROUTE.c:119: structure has no member named `if_name'
extensions/libipt_ROUTE.c:120: structure has no member named `if_name'
extensions/libipt_ROUTE.c:122: structure has no member named `if_index'
make: *** [extensions/libipt_ROUTE_sh.o] Error 1
extensions/libipt_ROUTE.c says :
[Line 61]
if (strlen(optarg) > sizeof(route_info->if_name) - 1)
exit_error(PARAMETER_PROBLEM,
"Maximum interface name length %u",
sizeof(route_info->if_name) - 1);
[Line 47]
struct ipt_route_target_info *route_info =
(struct ipt_route_target_info*)(*target)->data;
[Line 12]
#include <linux/netfilter_ipv4/ipt_ROUTE.h>
[root@testfw extensions]# locate ipt_ROUTE.h
/data/download/kernel/linux-2.4.20/include/linux/netfilter_ipv4/ipt_ROUTE.h
/data/download/kernel/linux-2.4.20/include/linux/netfilter_ipv4/ipt_ROUTE.h
says :
struct ipt_route_target_info {
char ifname[IPT_ROUTE_IFNAMSIZ];
unsigned int ipto;
};
I changed
"char ifname[IPT_ROUTE_IFNAMSIZ];" into
"char if_name[IPT_ROUTE_IFNAMSIZ];"
and now it only complains about not having an "if_index" member :
ld -shared -o extensions/libipt_quota.so extensions/libipt_quota_sh.o
cc -O2 -Wall -Wunused -I/data/download/kernel/linux-2.4.20/include
-Iinclude/ -DIPTABLES_VERSION=\"1.2.7a\" -fPIC -o
extensions/libipt_ROUTE_sh.o -c extensions/libipt_ROUTE.c
extensions/libipt_ROUTE.c: In function `parse':
extensions/libipt_ROUTE.c:67: structure has no member named `if_index'
extensions/libipt_ROUTE.c:81: structure has no member named `if_index'
extensions/libipt_ROUTE.c:86: structure has no member named `if_index'
extensions/libipt_ROUTE.c: In function `print':
extensions/libipt_ROUTE.c:122: structure has no member named `if_index'
make: *** [extensions/libipt_ROUTE_sh.o] Error 1
Now my experimenting stops : I sure don't know anything about some if_index.
I just checked out the latest POM and ipt_route_target_info still has the
same structure.
Is this something that should be corrected or what am I doing wrong ?
Rob
[-- Attachment #2: Type: text/html, Size: 5501 bytes --]
^ permalink raw reply
* Re: ax25 kernel problem sometimes accur
From: mvw @ 2002-12-11 13:36 UTC (permalink / raw)
To: linux-hams
In-Reply-To: <20021211133016.A14287@linux-mips.org>
Gents,
> [snip] AX.25 is about the worst protocol design
> I've ran over in my life
That's not encouraging. Is it really that bad?
Asking becuase TCP/IP over ax.25 is the one thing that can rescue packet,
I think. For instance, the fact I can get my provate email in and out when
ADSL and cable are down is a real benefit. The fact I can driva all around
town and pick up mail with a radio connection, free of charge, is also
very beneficial. I can have nmy servers send mail via radio with problem
reports when prob;lems occur. Emergency use. The list of useful 1200 bps
applications goes on!
But that asusmes the protocol is solid. My 2.0 kernel running old ax.25
stuff has been up 4 years now without dropping a packet. Are we saying
nowadays it's worse? Should I can my 2.4.20 kernel with ax.25?
Sorry for dropping in in the middle!
Michael VA3MVW
^ permalink raw reply
* Re: grub and 2.5.50
From: Stefan Reinauer @ 2002-12-11 13:43 UTC (permalink / raw)
To: Matt Young; +Cc: Linux Kernel Mailing List
In-Reply-To: <200212091640.35716.wz6b@arrl.net>
* Matt Young <wz6b@arrl.net> [021210 01:40]:
> These grub commands work with SUSE 2.4.19-4GB:
>
> kernel (hd0,0)/bzImage root=/dev/hda3 vga=791
> initrd (hd0,0)/initrd
>
> But with 2.5.50 the kernel panics after Freeing the initrd memory with
> "Unable te mount root FS, please correct the root= cammand line"
> I have compiled with the required file systems (EXT2,EXT3,REISERFS).
Did you also compile in support for the root device itself (i.e. ide or
scsi driver). These are loaded via the initrd normally on SuSE, which
will not work, if you did not install newer modutils..
Stefan
--
The x86 isn't all that complex - it just doesn't make a lot of
sense. -- Mike Johnson, Leader of 80x86 Design at AMD
Microprocessor Report (1994)
^ permalink raw reply
* [PATCH] mmap.c (do_mmap_pgoff) 'repatched'.
From: DervishD @ 2002-12-11 13:23 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux-kernel, davem
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
Hi Alan :))
The patch I sent you for mmap.c, correcting a corner case,
namely the case where the requested size on a call to 'mmap()' was
greater than SIZE_MAX-PAGE_SIZE, because the size was incorrectly
page-aligned to size '0', does nothing if TASK_SIZE is the full
address space for the task. This happens, for example, under sparc64.
This new patch covers this case and works even if TASK_SIZE is
very huge. My patch was completed by David S. Miller <davem@redhat.com>
and now should work for all cases.
The patch is against your 2.4.20-ac1 tree. If you have any doubt,
please tell.
Thanks ;)
Raúl
[-- Attachment #2: mmap.c.diff --]
[-- Type: text/plain, Size: 827 bytes --]
--- linux/mm/mmap.c.orig 2002-12-11 14:08:39.000000000 +0100
+++ linux/mm/mmap.c 2002-12-11 14:09:54.000000000 +0100
@@ -473,10 +473,6 @@
}
-/*
- * NOTE: in this function we rely on TASK_SIZE being lower than
- * SIZE_MAX-PAGE_SIZE at least. I'm pretty sure that it is.
- */
unsigned long do_mmap_pgoff(struct file * file, unsigned long addr, unsigned long len,
unsigned long prot, unsigned long flags, unsigned long pgoff)
@@ -493,14 +489,14 @@
if (file && (!file->f_op || !file->f_op->mmap))
return -ENODEV;
- if (!len)
+ if (len == 0)
return addr;
+
+ len = PAGE_ALIGN(len);
- if (len > TASK_SIZE)
+ if (len > TASK_SIZE || len == 0)
return -EINVAL;
- len = PAGE_ALIGN(len); /* This cannot be zero now */
-
/* offset overflow? */
if ((pgoff + (len >> PAGE_SHIFT)) < pgoff)
return -EINVAL;
^ permalink raw reply
* Re: [TRIVIAL PATCH] FBDEV: Small impact patch for fbdev
From: James Simmons @ 2002-12-11 14:36 UTC (permalink / raw)
To: Petr Vandrovec
Cc: Linux Fbdev development list, Linux Kernel Mailing List, adaplas
In-Reply-To: <A042D564F44@vcnet.vc.cvut.cz>
> > int fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
> > {
> > int xoffset = var->xoffset;
> > int yoffset = var->yoffset;
> > int err;
> >
> > if (xoffset < 0 || yoffset < 0 || info->fbops->fb_pan_display ||
>
> I'm probably missing something important, but do not you want
> !info->fbops->fb_pan_display
> instead?
Oops. Typo to the screen. That wasn't commited :-)
^ permalink raw reply
* Re: O2 VICE support
From: Christoph Hellwig @ 2002-12-11 13:38 UTC (permalink / raw)
To: ilya; +Cc: linux-mips, ralf
In-Reply-To: <20021210191120.GE609@gateway.total-knowledge.com>
On Tue, Dec 10, 2002 at 11:11:20AM -0800, ilya@theIlya.com wrote:
> RCS file: /home/cvs/linux/arch/mips64/kernel/ioctl32.c,v
> retrieving revision 1.26
> diff -u -r1.26 ioctl32.c
> --- arch/mips64/kernel/ioctl32.c 12 Nov 2002 15:26:11 -0000 1.26
> +++ arch/mips64/kernel/ioctl32.c 10 Dec 2002 17:02:29 -0000
> @@ -55,6 +57,10 @@
>
> #include <linux/rtc.h>
>
> +#ifdef CONFIG_O2_VICE
> +#include <linux/vice.h>
> +#endif
Just include the header unconditionally.
> static int w_long(unsigned int fd, unsigned int cmd, unsigned long arg)
> @@ -827,6 +968,12 @@
> COMPATIBLE_IOCTL(TIOCGSERIAL)
> COMPATIBLE_IOCTL(TIOCSSERIAL)
> COMPATIBLE_IOCTL(TIOCSERGETLSR)
> +#ifdef CONFIG_O2_VICE
> +COMPATIBLE_IOCTL(VICE_IOCTL_MAP_DMA)
> +COMPATIBLE_IOCTL(VICE_IOCTL_MSP_RUN)
> +COMPATIBLE_IOCTL(VICE_IOCTL_BSP_RUN)
> +COMPATIBLE_IOCTL(VICE_IOCTL_DO_DMA)
> +#endif
Dito. COMPATIBLE_IOCTL() isn't a big burgden, so it doesn't harm to get
rid of the ifdefs.
> +source drivers/char/o2vice/Kconfig
I think it should be in drivers/media/vice (i.e. it's one of the media
devices, and I don't think you need the o2, especially as you don't
use it e.g. in the header name).
> --- /dev/null Sun Jul 17 16:46:18 1994
> +++ drivers/char/o2vice/Makefile Thu Sep 12 00:12:16 2002
> @@ -0,0 +1,21 @@
> +#
> +# drivers/char/o2vice/Makefile
> +#
> +# Makefile for the O2 VICE Engine driver.
> +#
> +
> +SUB_DIRS :=
> +MOD_SUB_DIRS := $(SUB_DIRS)
> +ALL_SUB_DIRS := $(SUB_DIRS)
> +
> +#O_TARGET := vice.o
> +
> +obj-y :=
> +obj-m :=
> +obj-n :=
> +obj- :=
This is 2.2 crap. Just get rid of it..
> +
> +obj-$(CONFIG_O2_VICE) += main.o msp.o bsp.o dma.o
> +#obj-$(CONFIG_O2_VICE_DBG) += vicedebug.o
> +
> +include $(TOPDIR)/Rules.make
The include isn't needed anymore either in 2.5.
> +#include <linux/ioctl.h> /* needed for the _IOW etc stuff used later */
> +#ifdef __KERNEL__
> +#include <asm/pci.h>
> +#endif
> +#include <linux/types.h> /* size_t */
> +
> +#ifndef __KERNEL__
> +typedef __u64 u64;
> +typedef __u32 u32;
> +typedef __u16 u16;
> +#endif /* __KERNEL */
Urgg. Usually kernel headers aren't supposed to be used in userspace.
If you want to use a copy anyway it should be done with much less burden
on the kernel code.
> +#ifdef VICE_DEBUG
> +# define DPRINTK(fmt, args...) printk( KERN_DEBUG "vice: " fmt, ## args)
> +#else
> +# define DPRINTK(fmt, args...) /* not debugging: nothing */
> +#endif
> +
> +#define PDEBUG DPRINTK
Just use pr_debug?
> +
> +#ifndef VICE_MAJOR
> +#define VICE_MAJOR 240 /* dynamic major by default */
> +#endif
Comment doesn't match code.
> +/*
> + * Prototypes for shared functions
> + */
> +ssize_t vice_read (struct file *filp, char *buf, size_t count,
> + loff_t *f_pos);
> +ssize_t vice_write (struct file *filp, const char *buf, size_t count,
> + loff_t *f_pos);
> +loff_t vice_llseek (struct file *filp, loff_t off, int whence);
> +int vice_ioctl (struct inode *inode, struct file *filp,
> + unsigned int cmd, unsigned long arg);
Exported file operations are usually a very bad sign. But it looks like
you could just make them static anyway :)
> +/*
> + * VICE ioctl commands
> + */
> +#ifdef __KERNEL__
> +#define VICE_IOCTL_MAGIC 0x96
> +#define VICE_IOCTL_MAP_DMA _IOR(VICE_IOCTL_MAGIC,1,unsigned long)
> +#define VICE_IOCTL_MSP_RUN _IOR(VICE_IOCTL_MAGIC,2,msp_run)
> +#define VICE_IOCTL_BSP_RUN _IOR(VICE_IOCTL_MAGIC,3,bsp_run)
> +#define VICE_IOCTL_DO_DMA _IOWR(VICE_IOCTL_MAGIC,4,dma_run)
> +#else
> +#define VICE_IOCTL_MAP_DMA 0x40089601
> +#define VICE_IOCTL_MSP_RUN 0x400c9602
> +#define VICE_IOCTL_BSP_RUN 0x400c9603
> +#define VICE_IOCTL_DO_DMA 0xc00c9604
> +#endif
Ummm..
> +static inline int vice_dma_mem_init(vice_dev *vice)
> +{
> + int i;
> + for (i=0; i<64*2;i++){
> + if(!(vice->dma_kmem[i]=pci_alloc_consistent(0,VICE_PAGE_SIZE,&(vice->dma_mem[i])))) {
> + DPRINTK("failed at page# %i\n",i);
> + return -ENOMEM;
> + }
> + }
> + return 0;
Please adopt to Documentation/CodingStyle
> + DPRINTK("Falling asleep\n");
> + while(vice->msp_status==VICE_RES_STATUS_INPROGRESS) {
> + interruptible_sleep_on(&wq);
sleep_on is racy. You should at least use wait_even, but it doesn't look
like vice->msp_status is atomically updated anyway.
> --- /dev/null Sun Jul 17 16:46:18 1994
> +++ drivers/char/o2vice/Makefile Thu Sep 12 00:12:16 2002
The diff seems to include the same hunk twice..
> +/* In vice_open, the fop_array is used according to TYPE(dev) */
> +int vice_open(struct inode *inode, struct file *filp)
> +{
> + vice_dev *vice=vice_device; /* device information */
> + int res;
> +
> + MOD_INC_USE_COUNT; /* Before we maybe sleep */
Please set .owner in the file_operations instead.
> +
> + if(vice->is_open)
> + return -EBUSY;
This seems pretty racy.
> +
> + if (!filp->private_data) {
> + filp->private_data = vice_device;
> + }
filp->private_data can't be set.
> +ssize_t vice_read(struct file * filp, char *buf, size_t count, loff_t * f_pos)
> +{
> + printk(KERN_WARNING
> + "Processing bit streams through reading/writing is not supported yet\n");
> + return -ENOSYS;
> +}
> +
> +ssize_t vice_write(struct file * filp, const char *buf, size_t count,
> + loff_t * f_pos)
> +{
> + printk(KERN_WARNING
> + "Processing bit streams through reading/writing is not supported (yet)\n");
> + return -ENOSYS;
> +}
What about just not implementing the methods instead?
> +static void vice_vma_open(struct vm_area_struct *vma)
> +{ MOD_INC_USE_COUNT; }
> +
> +static void vice_vma_close(struct vm_area_struct *vma)
> +{ MOD_DEC_USE_COUNT; }
This is silly. You get a reference for vma->vm_file as long as you
have any mmaps. That's enough for the refcounting.
> +static struct vm_operations_struct vice_vm_ops = {
> + open: vice_vma_open,
> + close: vice_vma_close,
> + nopage: vice_vma_nopage,
> +};
Please use C99-initializers (i.e. .foo = bar)
> +void vice_cleanup_module(void)
> +{
> +#ifndef CONFIG_DEVFS_FS
> + /* cleanup_module is never called if registering failed */
> + unregister_chrdev(vice_major, "vice");
> +#endif
Umm, just because someone makes the mistake of enabling devfs he
doesn't have to use it.. :)
> +#ifndef VICE_DEBUG
> + EXPORT_NO_SYMBOLS; /* otherwise, leave global symbols visible */
> +#endif
EXPORT_NO_SYMBOLS is a noop on 2.5
^ permalink raw reply
* Re: HDSP 9652 - a couple of small (?) issues
From: Paul Davis @ 2002-12-11 13:38 UTC (permalink / raw)
To: Mark Knecht; +Cc: Alsa-Devel, PlanetCCRMA
In-Reply-To: <1039581753.1681.7.camel@Godzilla>
>1) I am unable to turn down the volume with alsamixer. All the way up or
>down, the volume is always very loud. Has anyone else seen this? Is
>there some other tool which will actually control the volume?
the mixer is (currently) disabled on the 9652-hdsp. i have asked RME
to send me the commands to reset it and the new register information
on how to access it (its not the same as the regular hdsp). i will
prod them again this morning.
--p
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: IBM spamms me with error messages
From: Pavel Machek @ 2002-12-11 13:47 UTC (permalink / raw)
To: Matti Aarnio; +Cc: kernel list
In-Reply-To: <20021210224325.GE32122@mea-ext.zmailer.org>
Hi!
> > I replied to some mail on l-k and IBM spammed me with 20+ error
> > messages. Now it is apparently going to do that again.
>
> Still/again ?
Hehe, I replied to this, and got error, again.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
^ permalink raw reply
* Re: acpi on a Samsung V20 with mandrake 9.0
From: Derek Broughton @ 2002-12-11 13:43 UTC (permalink / raw)
To: ACPI Development - Sourceforge
In-Reply-To: <200212111241.gBBCfgw08025@cnes.fr>
> I am not an expert of acpi, so excuse me if my questions are basic.
> (but there is no acpi-users mailing list, just an acpi-devel one...)
There is: acpi-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org (which really should be called
acpi-users, as it is strictly peer support).
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: PWM on the MPC850
From: Wolfgang Denk @ 2002-12-11 13:43 UTC (permalink / raw)
To: Donald MacArthur; +Cc: linuxppc-embedded
In-Reply-To: <NDBBIHDFKLJKGJJGMFJOOEILCGAA.dmacarth@ufl.edu>
In message <NDBBIHDFKLJKGJJGMFJOOEILCGAA.dmacarth@ufl.edu> you wrote:
>
> Does have any information regarding generating RC spec PWM signals using the
> MPC850
> that does not bog down the processor? Also does anyone know how to expand
You can, to a certain degree, use the RISC timers to set up a couple
of PWM channels that run with zero CPU load (just some load on the
CPM). See the PWM driver (arch/ppc/8xx_io/pwm_8xx.c) in our kernel
source tree.
But be warned: do NOT use any of the port B pins for I/O in such a
setup. There is a race condition within all MPC8xx CPUs.
> the number
> of RS232 ports for the MPS850 from two to 2+.
Add one or more external UARTs? This has been done before (for
example, we have a design with 2 x octal UARTs on a MPC8xx system).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
An age is called Dark not because the light fails to shine, but
because people refuse to see it. -- James Michener, "Space"
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: patch for aty128fb.c
From: James Simmons @ 2002-12-11 14:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-kernel
In-Reply-To: <15863.9692.239964.520652@argo.ozlabs.ibm.com>
> Currently it can only put one rage 128 chip to sleep, but that is ok
> for now since I've never seen a laptop with two rage 128 chips yet. :)
> The generic device model will ultimately give us a better way to
> handle sleep/wakeup.
Actually I started to looking into doing that. I noticed struct
pci_driver having a resume and suspend function. Is this related? I just
started to looking into the new PM code.
^ permalink raw reply
* IBM Spam
From: Richard B. Johnson @ 2002-12-11 13:53 UTC (permalink / raw)
To: Linux kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 325 bytes --]
Here is the untouched 'raw' mail sent from
--HAA31602.1039614205/mailhub.rchland.ibm.com
... any time I reply to anybody on the linux-kernel list.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 2311 bytes --]
^ permalink raw reply
* Re: [PATCH] Notifier for significant events on i386
From: Corey Minyard @ 2002-12-11 13:57 UTC (permalink / raw)
To: vamsi; +Cc: Stephen Hemminger, Kernel List, lkcd-devel, ak, vamsi_krishna
In-Reply-To: <20021211165153.A17546@in.ibm.com>
Vamsi Krishna S . wrote:
>Andi,
>
>Isn't this a problem on x86_64 too? What is there to prevent a
>handler from being removed from the notifier list while it
>is being used to call the handler on another CPU?
>
>I am considering using a RCU-based list for notifier chains.
>Corey has done some work on these lines to add NMI notifier
>chain, I think it should be generalised on for all notifiers.
>
>Thoughts? Comments?
>
>
This is probably a good idea. I won't be able to work on it for a
while, but you can grab
my patch at http://sourceforge.net/projects/openipmi/, look under the
2.5 releases for
the most current linux-nmi-2.5.xx-vyy.diff.
-Corey
^ permalink raw reply
* Re: IBM spamms me with error messages
From: Richard B. Johnson @ 2002-12-11 13:58 UTC (permalink / raw)
To: Pavel Machek; +Cc: Matti Aarnio, kernel list
In-Reply-To: <20021211134730.GD3575@atrey.karlin.mff.cuni.cz>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 695 bytes --]
On Wed, 11 Dec 2002, Pavel Machek wrote:
> Hi!
>
> > > I replied to some mail on l-k and IBM spammed me with 20+ error
> > > messages. Now it is apparently going to do that again.
> >
> > Still/again ?
>
> Hehe, I replied to this, and got error, again.
>
> Pavel
>
> --
> Casualities in World Trade Center: ~3k dead inside the building,
> cryptography in U.S.A. and free speech in Czech Republic.
You are not the only one. I will probably get spammed again. Here's
the complete raw mail from their last spam.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 2311 bytes --]
^ permalink raw reply
* [parisc-linux] another kernel compilation error
From: Tim Kemna @ 2002-12-11 13:51 UTC (permalink / raw)
To: parisc-linux
In-Reply-To: <20021211063321.GB10185@systemhalted>
Hi,
I'm trying to compile a kernel, version 2.4.20-pa13. But I get the following
error:
ld -T /usr/src/linux-2.4.20-pa13/arch/parisc/vmlinux.lds
arch/parisc/kernel/hea
d.o init/main.o init/version.o init/do_mounts.o \
--start-group \
arch/parisc/kernel/pdc_cons.o arch/parisc/kernel/process.o
arch/parisc/lib/lib.a
arch/parisc/mm/mm.o arch/parisc/kernel/kernel.o arch/parisc/hpux/hpux.o
kernel/
kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/parisc/kernel/init_task.o \
drivers/char/char.o drivers/block/block.o drivers/misc/misc.o
drivers/net/net.o
drivers/media/media.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o
drivers/vid
eo/video.o drivers/gsc/gscbus.o arch/parisc/math-emu/math.o \
net/network.o \
`gcc -print-libgcc-file-name`
/usr/src/linux-2.4.20-pa13/arch/parisc/lib/lib.a /
usr/src/linux-2.4.20-pa13/lib/lib.a \
--end-group \
-o vmlinux
ld: arch/parisc/kernel/kernel.o(.text.show_trace+0x58): fixing
R_PARISC_DPREL21L
ld: arch/parisc/kernel/kernel.o(.text.timer_interrupt+0x88): fixing
R_PARISC_DPR
EL21L
ld: arch/parisc/kernel/kernel.o(.text.timer_interrupt+0x94): fixing
R_PARISC_DPR
EL21L
drivers/char/char.o: In function `hp_diva_check':
drivers/char/char.o(.text.hp_diva_check+0x60): undefined reference to
`rs_interr
upt'
make: *** [vmlinux] Error 1
What am I doing wrong?
Greetings,
Tim
^ permalink raw reply
* Re: IBM spamms me with error messages
From: Matti Aarnio @ 2002-12-11 14:03 UTC (permalink / raw)
To: Richard B. Johnson; +Cc: Pavel Machek, Matti Aarnio, kernel list
In-Reply-To: <Pine.LNX.3.95.1021211085722.20098A-101000@chaos.analogic.com>
I would not call these "spam", they are merely undesirable
behaviour of GW-MTAs in between the Internet, and some other
oddball network. A pestilance they definitely are...
On Wed, Dec 11, 2002 at 08:58:21AM -0500, Richard B. Johnson wrote:
> You are not the only one. I will probably get spammed again. Here's
> the complete raw mail from their last spam.
>
> Cheers,
> Dick Johnson
/Matti Aarnio
^ permalink raw reply
* Re: [PATCH] dm.c - device-mapper I/O path fixes
From: Kevin Corry @ 2002-12-11 13:16 UTC (permalink / raw)
To: Denis Vlasenko, Joe Thornber
Cc: Linus Torvalds, Kernel Mailing List, lvm-devel
In-Reply-To: <200212111330.gBBDTTa06416@Port.imtp.ilyichevsk.odessa.ua>
On Wednesday 11 December 2002 12:19, Denis Vlasenko wrote:
> On 11 December 2002 10:19, Joe Thornber wrote:
> > dec_pending(): only bother spin locking if io->error is going to be
> > updated. [Kevin Corry]
> >
> > --- diff/drivers/md/dm.c 2002-12-11 12:00:29.000000000 +0000
> > +++ source/drivers/md/dm.c 2002-12-11 12:00:34.000000000 +0000
> > @@ -238,10 +238,11 @@
> > static spinlock_t _uptodate_lock = SPIN_LOCK_UNLOCKED;
> > unsigned long flags;
> >
> > - spin_lock_irqsave(&_uptodate_lock, flags);
> > - if (error)
> > + if (error) {
> > + spin_lock_irqsave(&_uptodate_lock, flags);
> > io->error = error;
> > - spin_unlock_irqrestore(&_uptodate_lock, flags);
> > + spin_unlock_irqrestore(&_uptodate_lock, flags);
> > + }
> >
> > if (atomic_dec_and_test(&io->io_count)) {
> > if (atomic_dec_and_test(&io->md->pending))
>
> This seems pointless, end result:
>
> spin_lock_irqsave(&_uptodate_lock, flags);
> io->error = error;
> spin_unlock_irqrestore(&_uptodate_lock, flags);
Are you saying the "if (error)" part is pointless? If so, I have to disagree.
A bio may be split into several sub-bio's. When each of those split bio's
completes, they are going to call this function. But if only one of those
split bio's has an error, then the error might get lost without that "if"
statement.
However, it might be a good idea to consider how bio's keep track of errors.
When a bio is created, it is marked UPTODATE. Then, if any part of a bio
takes an error, the UPTODATE flag is turned off. When the whole bio
completes, if the UPTODATE flag is still on, there were no errors during the
i/o. Perhaps the "error" field in "struct dm_io" could be modified to use
this method of error tracking? Then we could change dec_pending() to be
something like:
if (error)
clear_bit(DM_IO_UPTODATE, &io->error);
with a "set_bit(DM_IO_UPTODATE, &ci.io->error);" in __bio_split().
--
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/
^ permalink raw reply
* Modifying Source Ip on input/prerouting
From: Stephane Jourdois @ 2002-12-11 13:58 UTC (permalink / raw)
To: netfilter
Hello all,
I would need to be able to modify the source ip on input GRE paquets.
This is because I'm trying to setup a pptp tunnel, via a router that
doesn't NAT correctly the GRE.
The client receives GRE, but replies with it's own local ip, then my
server cannot receive the answers... If I could just change the source
ip on those paquets, that would be perfect...
Thanks for your help,
--
/// Stephane Jourdois /"\ ASCII RIBBON CAMPAIGN \\\
((( Ingénieur développement \ / AGAINST HTML MAIL )))
\\\ 6, av. George V X ///
\\\ 75008 Paris / \ +33 6 8643 3085 ///
^ permalink raw reply
* Re: PPTP+NAT+MASQ anyone?
From: Martin Josefsson @ 2002-12-11 14:03 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk; +Cc: Netfilter mailinglist
In-Reply-To: <200212111249.53924.roy@karlsbakk.net>
On Wed, 2002-12-11 at 12:49, Roy Sigurd Karlsbakk wrote:
> > > I've tried all the ones I can find.
> > > When trying to apply the pptp-conntrack-nat.patch, I get errors applying
> > > it. Do I need to hand patch this thing? I've tried with 2.4.{18,19,20}
> >
> > Did you run './runme pending' first like the documentation tells you?
>
> yes. I get this error message when trying to patch 2.4.{19|20}.
2.4.19 + all the pending stuff
Testing patch extra/pptp-conntrack-nat.patch...
Placed new Config.in line
Placed new Configure.help entry
Placed new Makefile line
Placed new Makefile line
Placed new ip_conntrack.h line
Placed new ip_conntrack.h line
Placed new ip_conntrack.h line
Placed new ip_conntrack.h line
Placed new ip_conntrack.h line
Placed new ip_conntrack.h line
Placed new ip_conntrack.h line
Placed new ip_conntrack.h line
Patch extra/pptp-conntrack-nat.patch applied cleanly.
works fine.
IIRC the pptp patch doesn't apply if you've applied tcp-windowtracking
patch, that patch is quite invasive.
I just tried applying _all_ patches that come before the pptp patch in
p-o-m to 2.4.19 and then applying the pptp patch, no problem, worked
fine.
--
/Martin
Never argue with an idiot. They drag you down to their level, then beat
you with experience.
^ permalink raw reply
* Re: IBM spamms me with error messages
From: Keith Owens @ 2002-12-11 14:12 UTC (permalink / raw)
To: kernel list
In-Reply-To: <20021211133509.GC3575@atrey.karlin.mff.cuni.cz>
On Wed, 11 Dec 2002 14:35:12 +0100,
Pavel Machek <pavel@suse.cz> wrote:
>> > I replied to some mail on l-k and IBM spammed me with 20+ error
>> > messages. Now it is apparently going to do that again.
>>
>> Still/again ?
>
>It seems to happen after I group-reply to message on the list. Being
>subscribed and quiet does not seem to trigger it. When I do
>group-reply, I do get pair of error messages, then another pair of
>same error messages, and it continues like that.
>
>This time it "only" sent two pairs of error messages...
<aol>Me too</aol>. I have blocked 32.97.182.0/24 at my firewall, let
IBM eat their own garbage messages.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.