Re: PATCH 2.4.0.10.3: pc_keyb and q40_keyb cleanup
Andrea Arcangeli wrote: > > On Sun, Oct 15, 2000 at 03:48:55PM -0400, Jeff Garzik wrote: > > Changes: > > * both: we know we are in an interrupt, so > > s/spin_lock_irqsave/spin_lock/ > > There request_irq is not called passing the SA_INTERRUPT flag so the irq > handler is recalled with irqs enabled and in turn irqsave is necessary. hmmm. Can you elaborate on this a bit? I didn't know that bit about !SA_INTERRUPT, but why is irqsave necessary in these drivers? I don't see handle_kbd_event() being called from a timer or anything special like that.. -- Jeff Garzik| The difference between laziness and Building 1024 | prioritization is the end result. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0.10.3: pc_keyb and q40_keyb cleanup
Andrea Arcangeli wrote: > Timer, bottomhalves (softirq) and tasklets (and softnet) are always > recalled with irq enabled. So if it would be called by timer/tasklet/bhhandler > it should use irq version of the spinlocks too if it needs to run with irq > locally disabled. > > One thing you could safely change in keyboard_interrupt is to remove the save > part of the spinlock by using spin_lock_irq (we don't need to save anything > since keyboard_interrupt is only recalled as an irq handler). I understand SA_INTERRUPT, my question in the previous e-mail was more basic: keyboard_interrupt calls handle_kbd_event with local interrupts disabled. Why are local interrupts disabled? -- Jeff Garzik| The difference between laziness and Building 1024 | prioritization is the end result. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0.10.3: pc_keyb and q40_keyb cleanup
Andrea Arcangeli wrote: > On Mon, Oct 16, 2000 at 09:31:42PM -0400, Jeff Garzik wrote: > >[..] Why are local interrupts disabled [in pc_keyb.c]? > > To avoid to deadlock on the kbd_controller_lock in SMP or to race in UP. > > Both irq handler and normal kernel context (open/close) will play with the keyb > controller at around address 0x6x and accesses are serialized via the > kbd_controller_lock. Well, the -spin lock- exists for serialization. My question is Why does pc_keyb irq handler disable local irqs for this case? What is the race/deadlock that exists with spin_lock in the irq handler, but does not exist with spin_lock_irqsave in the irq handler? For UP, using spin_lock_irqsave in user context, and spin_lock in the irq handler, irqs are disabled for user context, and user context is disabled while the irq handler is running, so no race, and no additional synchronization needed. For SMP, using spin_lock_irqsave in user context, and spin_lock in the irq handler, the irq handler and user context need only to spin_lock to protect the kbd controller. If the above two paragraphs are correct... then why was my patch incorrect? Sorry that I'm a bit slow here, but I just don't see why s/spin_lock_irqsave/spin_lock/ is wrong... Jeff -- Jeff Garzik| The difference between laziness and Building 1024 | prioritization is the end result. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0.10.3: pc_keyb and q40_keyb cleanup
Andrea Arcangeli wrote: > > On Tue, Oct 17, 2000 at 05:26:23AM -0400, Jeff Garzik wrote: > > Well, the -spin lock- exists for serialization. My question is Why > > does pc_keyb irq handler disable local irqs for this case? What is the > > race/deadlock that exists with spin_lock in the irq handler, but does > > not exist with spin_lock_irqsave in the irq handler? > > As said the save part isn't necessary. > > This is a trace of the deadlock: > > irq 2 runs > keyboard_interrupt > irqs are been left enabled > spin_lock() > here irq 12 runs > keyboard_interrupt > here doesn't matter if irqs are enabled or disabled of course > spin_lock() -> dealdock Thanks a bunch Andrea. That's the piece I was looking for -- I didn't know that two different irqs were calling the same code. Learn something new every day :) I wonder if q40_keyb has the same thing to worry about -- Jeff Garzik| The difference between laziness and Building 1024 | prioritization is the end result. MandrakeSoft | - To unsubscribe from this list: send 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 submissions
Rik van Riel wrote: > On Tue, 6 Mar 2001, Kurt Garloff wrote: > > On Tue, Mar 06, 2001 at 02:22:58PM -0300, Rik van Riel wrote: > > > probably even out of linux-kernel ... > > > > No. I want to see experimental stuff on l-k. That's what it's meant for. > > Putting the experimental stuff which isn't on l-k at the > moment would probably triple the volume of this list, if > not more ... > > I'm pretty sure most people already find l-k traffic too > heavy to keep up. If you want to read all the experimental > stuff of all the subsystems, why not subscribe to the > mailing lists of those subsystems ? Every patch doesn't need to go to lkml, but keeping linux-kernel folks updated on experimental issues is always IMHO a good idea. Otherwise, interested folks who don't have time to find out about and subscribe to 1000 other lists are kept informed. Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Forcible removal of modules
John Fremlin wrote: > Why not set up the device driver to handle PM events itself. See > Documentation/pm.txt under Driver Interface. For PCI drivers, you implement the ::suspend and ::remove hooks. > I have a race free version of pm_send_all if you want it. Is this the same thing that is in 2.4.3-pre3? -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.4.3 and new aic7xxx
Linus Torvalds wrote: > I suspect it's easier to just make the PCI layer call the probe function > in that order, instead of working around it in your driver. That seems like a really good idea, especially in light of the fact that some drivers are doing (have to do?) -reverse- order PCI scanning. I would prefer to sort the list at probe not boot time. That makes it easy to reverse the order on the fly, depending on what the driver requests at runtime. It's SMP-friendly, because I can grab a private copy of the PCI device list, sort it, and scan it. You don't have to re-sort at every pci_insert_device, for hotplug machines. The only potential downside is I need to check and see if the bootmem case needs to be handled, when making a private copy of the pci devices list for sorting. -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RFC: fix ethernet device initialization
Jeff Garzik wrote: > Our API already supports a solution -- setup the device, then call > register_netdev. The patch below adds a helper, alloc_etherdev, to > eliminate duplicate code in drivers. Ethernet device initialization, > after the patch, should now look like > > dev = alloc_etherdev(sizeof(struct netdev_private)); > ... initialize device ... > ... set up net_device struct members ... > rc = register_netdevice(dev); > if (rc) /* handle error */ > netif_start_queue(dev); Think-o in my example: netif_start_queue occurs in dev->open(), not in the probe phase. Simply ignore that line in the example and you are ok. Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.4.3 and new aic7xxx
"Justin T. Gibbs" wrote: > How often is the list manipulated? My guess is not very often. Modified very infrequently... at boot, and for each hotplug insertion or removal. It's not even read very often. > You can allow people to read the list without taking a spinlock and > only acquire the spinlock on list manipulations. Inserting an > element can be performed atomically so there isn't an SMP issue > so long as you don't allow more than one processor to insert at > the same time. This would allow you to perform insertion sort > meaning that everything from /proc to device drivers auto-magically > sees the devices in the order they were probed. I was just thinking the same thing. list_splice and an insertion sort can be used instead of all that allocation crap. > For hot plug devices > you might want to insert them at the end to follow the "order probed" > motif. hmmm.. Is there a reason why this would be -needed-? It wouldn't be hard to implement, but I would rather not have drivers dealing with a list whose normal state is defined as "mostly sorted"... -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] RFC: fix ethernet device initialization
People from time to time point out a wart in ethernet initialization:
The net_device is allocated and registered to the system in
init_etherdev, which is usually one of the first things an ethernet
driver probe function does. The net_device's final members are setup at
some time between then and the exit of the probe function. There is
never a clear point where the net device is available to the system for
use.
Our API already supports a solution -- setup the device, then call
register_netdev. The patch below adds a helper, alloc_etherdev, to
eliminate duplicate code in drivers. Ethernet device initialization,
after the patch, should now look like
dev = alloc_etherdev(sizeof(struct netdev_private));
... initialize device ...
... set up net_device struct members ...
rc = register_netdevice(dev);
if (rc) /* handle error */
netif_start_queue(dev);
This makes the ethernet driver look and behave similar to other APIs in
the kernel, and presents a nice and atomic
present-this-netdev-to-the-system operation.
It should be noted that there is a net_device::init function. IIRC in
the last discussion of this issue, ::init() was mentioned as a possible
solution. I agree that init() can be used, but I do not like the idea
of using init as a probe function, as the ISA drivers do it. This means
the ethernet device has the potential of holdling rtnl_lock for a long
time, and staying in the probe function, inside register_netdevice, for
a long time. And... I agree that init() can be used as a constructor
for filling in dev->xxx and dev->priv->xxx values, but I think doing so
is pointless: you must fill in certain values before your "constructor"
is called, just so your constructor has enough information to operate.
Patch description:
* Add alloc_etherdev, alloc_trdev, alloc_hippi_dev, alloc_fcdev, ...
* Use declarator macros to create init_etherdev, init_trdev, etc., and
remove duplicate code.
* Move net_init EXPORT_SYMBOL from net/netsyms.c to net_init.c.
* Convert drivers/net/8139too.c to use alloc_etherdev, as an example.
Final word, mostly PCI drivers need this change. ISA drivers use the
net_device::init constructor approach. IMHO they shouldn't stay in
register_netdevice so long, but that is a wart. This patch fixes a bug,
the huge span of time between init_etherdev and the indeterminant point
in the future when the net device is ready for use.
Comments?
--
Jeff Garzik | "You see, in this world there's two kinds of
Building 1024 | people, my friend: Those with loaded guns
MandrakeSoft | and those who dig. You dig." --Blondie
Index: drivers/net/8139too.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/8139too.c,v
retrieving revision 1.1.1.29
diff -u -r1.1.1.29 8139too.c
--- drivers/net/8139too.c 2001/03/05 23:46:05 1.1.1.29
+++ drivers/net/8139too.c 2001/03/07 20:58:24
@@ -647,11 +647,43 @@
(RX_DMA_BURST << RxCfgDMAShift);
+static void __rtl8139_cleanup_dev (struct net_device *dev)
+{
+ struct rtl8139_private *tp;
+ struct pci_dev *pdev;
+
+ assert (dev != NULL);
+ assert (dev->priv != NULL);
+
+ tp = dev->priv;
+ assert (tp->pci_dev != NULL);
+ pdev = tp->pci_dev;
+
+#ifndef USE_IO_OPS
+ if (tp->mmio_addr)
+ iounmap (tp->mmio_addr);
+#endif /* !USE_IO_OPS */
+
+ /* it's ok to call this even if we have no regions to free */
+ pci_release_regions (pdev);
+
+#ifndef RTL8139_NDEBUG
+ /* poison memory before freeing */
+ memset (dev, 0xBC,
+ sizeof (struct net_device) +
+ sizeof (struct rtl8139_private));
+#endif /* RTL8139_NDEBUG */
+
+ kfree (dev);
+
+ pci_set_drvdata (pdev, NULL);
+}
+
+
static int __devinit rtl8139_init_board (struct pci_dev *pdev,
-struct net_device **dev_out,
-void **ioaddr_out)
+struct net_device **dev_out)
{
- void *ioaddr = NULL;
+ void *ioaddr;
struct net_device *dev;
struct rtl8139_private *tp;
u8 tmp8;
@@ -663,20 +695,19 @@
DPRINTK ("ENTER\n");
assert (pdev != NULL);
- assert (ioaddr_out != NULL);
- *ioaddr_out = NULL;
*dev_out = NULL;
- /* dev zeroed in init_etherdev */
- dev = init_etherdev (NULL, sizeof (*tp));
+ /* dev and dev->priv zeroed in alloc_etherdev */
+ dev = alloc_etherdev (sizeof (*tp));
if (dev == NULL) {
- printk (KERN_ERR PFX "unable to alloc new ethernet\n");
+ printk (KERN_ERR PFX "Unable to alloc new net device\n");
DPRINTK ("EXIT, returning -ENOMEM\n");
Re: [PATCH] RFC: fix ethernet device initialization
Oh, it should be noted that since this is intended as a stable 2.4 series change. The patch does not change any existing APIs, only adds a function. Existing 2.4 drivers are free to continue using init_etherdev... This bug, which I fix, isn't causing oops AFAIK, just exporting ugliness to user space etc. -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: filesystem for initrd
Art Boulatov wrote: > I'm in the process of creating a custom "system partition" > for out Linux servers, which is actually an initial ramdisk, > coming from hd or network on boot > to load necessary drivers and perform important checks > before the real filesystems get mounted, > and I did not find any info on > what filesystems can I use > for initrd, are there any restrictions? > Mostly interested in cramfs, > due to it's compression. Any filesystem which works with a normal block device, such as a hard drive, will work with a ramdisk. Read ramdisk.txt and initrd.txt in the linux/Documentation directory, in your Linux kernel source tree. cramfs is nice but still read-only at the moment... You might be able to get away with stacking ramfs on top of that. If not, it shouldn't be hard to modify cramfs so that it allows fs modifications... just stick the updated pages in RAM until the file is unlinked or the fs is unmounted. -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RFC: fix ethernet device initialization
Jes Sorensen wrote: > I don't like the way you declare all the code in obscure macros in > there. > > +#define DECLARE_CHG_MTU(suffix,low,high) \ > + static int suffix##_change_mtu(struct net_device *dev, int new_mtu) \ > .. > > All it does is to make the code harder to read and debug for little/no > gain. I disagree, but you probably knew that when you saw the code :) These macros are not used inside code, they declare entire functions. These functions are 100% duplicated across 2-4 protocols. Duplicated code means bugs in some portions of the code and no others, more difficult to maintain, etc. I even proved this point while developing the patch -- one of the functions was missing an EXPORT_xxx symbol. Using a standard macro automatically fixed this, a small oversight that had been in the kernel probably for over a year. -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: List of recent (2.4.0 to 2.4.2-ac18) CONFIG options needing Configure.help text.
Keith Owens wrote: > > On Sat, 10 Mar 2001 23:03:19 -0700, > Steven Cole <[EMAIL PROTECTED]> wrote: > >With the 2.4.0 kernel, there were 476 CONFIG options which had > >no help entry in Configure.help. With 2.4.2-ac18, this number is now 547, > >which has been kept this low with 54 options getting Configure.help text. > > If any of these CONFIG_ options are always derived (i.e. the user never > sees them on a config menu) then please add the suffix _DERIVED to such > options. They still need to start with CONFIG_ to suit the kernel > build dependency generator so we cannot change the start of the name. > Appending _DERIVED will make it obvious that the options require no > help text. Yow. That is very cumbersome. Can't you just keep a list somewhere, instead of making such options longer? -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hotplug and interrupt context
Andreas Bombe wrote: > > I couldn't trace that down to be 100% sure and it's better to conform to > design than implementation, so I'll ask: > > Do the probe and remove functions of a pci_driver have to be able to > work in interrupt context? (i.e. GFP_ATOMIC and stuff) No, no interrupt context to worry about. It would really suck if you couldn't sleep in pci_driver::probe :) For CardBus, it calls schedule_task .. -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Rename all derived CONFIG variables
Keith Owens wrote: > > In 2.4.2-ac18 there are 130 CONFIG options that are always derived from > other options, the user has no control over them. It is useful for the > kernel build process to know which variables are derived and which > variables the user can control. There are also 6 CONFIG options that > are not used anywhere. > > ftp://ftp.ocs.com.au/pub/2.4.2-ac18-config_derived.gz > > is a 583,904 byte (unzipped) 114,291 (gzipped) patch which removes the > unused variables and renames the 130 derived variables from CONFIG_FOO > to CONFIG_FOO_DERIVED. The affected variables are :- Not only do I think that CONFIG_xxx_DERIVED needlessly extends the name of derived vars, but your patch does not belong in a stable series. Derived CONFIG_xxx vars are likely to be referenced in source. Changing those vars in the middle of a stable series pointlessly breaks external source code. I hope vendors don't start applying this patch... Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-ac18 fix for Alpha machines
Matti Aarnio wrote:
>
> The linkage of vmlinux fails with lacking code for bust_spinlocks(),
> thus I cloned the i386 one as is -- which apparently is not really
> processor specific...
>
> --- arch/alpha/mm/fault.c~ Sun Mar 11 11:49:23 2001
> +++ arch/alpha/mm/fault.c Sun Mar 11 14:46:39 2001
> @@ -231,3 +231,39 @@
> }
> #endif
> }
> +
> +extern spinlock_t timerlist_lock;
> +
> +/*
> + * Unlock any spinlocks which will prevent us from getting the
> + * message out (timerlist_lock is acquired through the
> + * console unblank code)
> + */
> +void bust_spinlocks(int yes)
> +{
> + spin_lock_init(&timerlist_lock);
> + if (yes) {
> + oops_in_progress = 1;
> +#ifdef CONFIG_SMP
> + global_irq_lock = 0;/* Many serial drivers do __global_cli() */
can you say untested-on-smp :)
global_irq_lock is a spinlock.
> +#endif
> + } else {
> + int loglevel_save = console_loglevel;
> + unblank_screen();
need to include vt_kern.h for unblank_screen proto
> +void do_BUG(const char *file, int line)
> +{
> + bust_spinlocks(1);
> + printk("kernel BUG at %s:%d!\n", file, line);
> +}
hmm, is this necessary? The patch I sent to Alan is missing this.
Don't forget to CC Richard Henderson, the Alpha maintainer, on
patches... Attached are the two patches I sent to Alan and Richard
earlier today. The first is my version of the bust_spinlock fix. The
second is an unrelated fix which was needed for our build, and may be
helpful to some seeing "get_wchan_stack" warnings or errors.
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
--- linux/arch/alpha/mm/fault.c.origSun Mar 11 22:44:41 2001
+++ linux/arch/alpha/mm/fault.c Sun Mar 11 22:51:04 2001
@@ -24,9 +24,36 @@
#include
#include
#include
+#include
#include
#include
+
+extern spinlock_t timerlist_lock;
+void bust_spinlocks(int yes)
+{
+spin_lock_init(&timerlist_lock);
+if (yes) {
+oops_in_progress = 1;
+#ifdef CONFIG_SMP
+ spin_lock_init(&global_irq_lock);/* Many serial drivers do
+__global_cli() */
+#endif
+} else {
+int loglevel_save = console_loglevel;
+unblank_screen();
+oops_in_progress = 0;
+/*
+ * OK, the message is on the console. Now we call printk()
+ * without oops_in_progress set so that printk will give klogd
+ * a poke. Hold onto your hats...
+ */
+console_loglevel = 15; /* NMI oopser may have shut the
+console up */
+printk(" ");
+console_loglevel = loglevel_save;
+}
+}
+
+
extern void die_if_kernel(char *,struct pt_regs *,long, unsigned long *);
--- linux/fs/proc/array.c.orig Sun Mar 11 22:42:37 2001
+++ linux/fs/proc/array.c Sun Mar 11 22:43:26 2001
@@ -271,6 +271,7 @@
extern int get_wchan_stack(struct task_struct *p, unsigned long *stack, int max);
inline char *task_stack(struct task_struct *p, char *buffer)
{
+#ifdef CONFIG_X86
unsigned long stack[64];
int i;
int cnt = get_wchan_stack(p, stack, 64);
@@ -278,6 +279,7 @@
buffer += sprintf(buffer, "Stack[%d]: %lx\n",
i, stack[i]);
}
+#endif
return buffer;
}
Re: PATCH - compile fix for 3c509.c in 2.4.3-pre3
On Tue, 13 Mar 2001, Neil Brown wrote: > in 2.4.3-pre3, drivers/net/3c509.c will not compile ifdef CONFIG_ISAPNP. > > The following patches fixes the error. I suspect that 3c515.c has > the same problem, but I didn't need to fix that to get my kernel to > build... so I didn't. 3c509 and 3c515 fixes already sent to him, twice no less :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Modular versus non-modular ISAPNP (was Re: PATCH - compile fix for 3c509.c in 2.4.3-pre3)
Neil Brown wrote: > On Monday March 12, [EMAIL PROTECTED] wrote: > > On Tue, 13 Mar 2001, Neil Brown wrote: > > > in 2.4.3-pre3, drivers/net/3c509.c will not compile ifdef CONFIG_ISAPNP. > > > > > > The following patches fixes the error. I suspect that 3c515.c has > > > the same problem, but I didn't need to fix that to get my kernel to > > > build... so I didn't. > > 3c509 and 3c515 fixes already sent to him, twice no less :) > Drat... I didn't remember seeing it go by on linux-kernel, but maybe I > didn't pay enough attention next time I'll wait till the same > problem appears in two pre releases before patching... (re cc'd to lkml...) My fault on that one, I didn't send it to lkml... BTW if you noticed, this problem was undetected initially due to differences between CONFIG_ISAPNP and CONFIG_ISAPNP_MODULE in the source. It is highly recommended to always compile with CONFIG_ISAPNP=y due to these differences. If you grep around for CONFIG_ISAPNP versus CONFIG_ISAPNP_MODULE, you'll see that many drivers are woefully unprepared for isapnp support compiled as a module. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Modular versus non-modular ISAPNP
Ion Badulescu wrote: > > On Mon, 12 Mar 2001 22:02:12 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > It is highly recommended to always compile with CONFIG_ISAPNP=y due to > > these differences. If you grep around for CONFIG_ISAPNP versus > > CONFIG_ISAPNP_MODULE, you'll see that many drivers are woefully > > unprepared for isapnp support compiled as a module. > > Another entry for the Kernel Janitor's List, perhaps? Yep.. grep for CONFIG_ISAPNP, look at the code, and evaluate it to make sure that isapnp works for that drivers regardless of whether CONFIG_ISAPNP -or- CONFIG_ISAPNP_MODULE is defined. Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac20
Michal Jaegermann wrote: > > On Tue, Mar 13, 2001 at 04:36:18AM +, Alan Cox wrote: > ... > > > > 2.4.2-ac20 > ... > > o Fix Alpha build (Jeff Garzik) > > Now I see (at least on Alpha) a constant wailing: > > /linux-2.4.2ac/include/linux/binfmts.h:45: warning: `struct > mm_struct' declared inside parameter list > /linux-2.4.2ac/include/linux/binfmts.h:45: warning: its scope is > only this definition or declaration, which is probably not what you want > > Is this somehow related? Nope, I saw that before the patch. My patch was, in any case, to a single .c file, not a header file, so it wouldn't spew like that. It compiled and booted, I moved on :) So solve that warning you probably need to shuffle the delicate balance of includes around so that linux/sched.h, where mm_struct is defined, is included before binfmts.h. Or have binfmt.h include sched.h (which should work... but its all kinds of nested nastiness) -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
New unaligned-accessed arch flag?
Instead of putting arch-specific ifdefs in drivers, would it be reasonable to add a per-arch flag UNALIGNED_PROFITABLE? Arch-specific ifdefs all over the default rx_copybreak values in net drivers are the example I have in mind, but it seems like it would be good knowledge that can be easily exposed to the rest of the kernel. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: [OOPS] 8139too
> i686 2.4.2 UP+kdb+lm_sensors+pcmcia
> after APM laptop suspend to disk
> 8139too is build-in, not pcmcia
> I often get hangups after suspend-to-disk if I'm connected to a hub/switch.
> This is the first oops I've actually seen and copied it by hand:
Philipp,
Does the attached patch solve the problem?
Modifying the interrupt handler may not be necessary, but it's there
just in case. (that's the first chunk of the patch)
Regards,
Jeff
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
Index: drivers/net/8139too.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/8139too.c,v
retrieving revision 1.1.1.29.10.1
diff -u -r1.1.1.29.10.1 8139too.c
--- drivers/net/8139too.c 2001/03/13 05:12:53 1.1.1.29.10.1
+++ drivers/net/8139too.c 2001/03/16 13:01:08
@@ -2028,10 +2028,12 @@
rtl8139_weird_interrupt (dev, tp, ioaddr,
status, link_changed);
- if (status & (RxOK | RxUnderrun | RxOverflow | RxFIFOOver)) /* Rx
interrupt */
+ if (netif_running (dev) &&
+ status & (RxOK | RxUnderrun | RxOverflow | RxFIFOOver)) /* Rx
+interrupt */
rtl8139_rx_interrupt (dev, tp, ioaddr);
- if (status & (TxOK | TxErr)) {
+ if (netif_running (dev) &&
+ status & (TxOK | TxErr)) {
spin_lock (&tp->lock);
rtl8139_tx_interrupt (dev, tp, ioaddr);
spin_unlock (&tp->lock);
@@ -2262,6 +2264,9 @@
void *ioaddr = tp->mmio_addr;
unsigned long flags;
+ if (!netif_running (dev))
+ return;
+
netif_device_detach (dev);
spin_lock_irqsave (&tp->lock, flags);
@@ -2282,6 +2287,8 @@
{
struct net_device *dev = pci_get_drvdata (pdev);
+ if (!netif_running (dev))
+ return;
netif_device_attach (dev);
rtl8139_hw_start (dev);
}
Re: Kernel 2.4.2and 8139too
Brian May wrote: > However, I have just put a 8139 based card into my Linux 2.4.2 > system. At one stage, these lines were logged: > > Mar 15 09:42:56 snoopy kernel: eth0: Abnormal interrupt, status 0020. > Mar 15 09:43:04 snoopy kernel: eth0: Abnormal interrupt, status 2020. > Mar 15 10:06:52 snoopy kernel: eth0: Abnormal interrupt, status 0020. > Mar 15 10:06:58 snoopy kernel: eth0: Abnormal interrupt, status 2020. > > The card seems to be reliable apart from these messages. It could be > that I was playing around with the network cable or something at the > time... However, any messages "Abnormal interrupt" make me slightly > nervous. They are logged at the kernel debug level, but nobody seems to notice this fact. Oh well. The messages are for debugging only and informational. They occur whenever an Rx or Tx error occurs. The latest version of 8139too hides this message behind RTL8139_DEBUG. Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 120 potential dereference to invalid pointers errors forlinux 2.4.1
ivers/net/smc9194.c:1356:smc_rcv: ERROR:NULL:1341:1356: >Using NULL ptr "skb" illegally! set by 'dev_alloc_skb':1341 Seems to be fixed already in my 2.4.3-pre4-based tree. > [BUG] init_etherdev can return NULL if dev is NULL > /u2/acc/oses/linux/2.4.1/drivers/net/sunhme.c:2838:happy_meal_pci_init: >ERROR:NULL:2806:2838: Using unknown ptr "dev" illegally! set by 'init_etherdev':2806 Fixed. > [BUG] dev could be NULL, then init_trdev will call init_netdev to allocate a new >device. > /u2/acc/oses/linux/2.4.1/drivers/net/tokenring/ibmtr.c:405:ibmtr_probe1: >ERROR:NULL:304:405: Using unknown ptr "dev" illegally! set by 'init_trdev':304 > > Start ---> > dev = init_trdev(dev,0); As with 3c515, this is a false positive. 'dev' is never NULL when passed to init_trdev, so the call always succeeds. > [BUG] dev_alloc_skb can return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/tokenring/lanstreamer.c:1429:streamer_arb_cmd: >ERROR:NULL:1386:1429: Using unknown ptr "mac_frame" illegally! set by >'dev_alloc_skb':1386 Seems to be fixed already in my 2.4.3-pre4 tree. > [BUG] dev_alloc_skb can return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/tokenring/olympic.c:1276:olympic_arb_cmd: >ERROR:NULL:1258:1276: Using unknown ptr "mac_frame" illegally! set by >'dev_alloc_skb':1258 Fixed. > [BUG] init_trdev can return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/tokenring/olympic.c:219:olympic_scan: >ERROR:NULL:217:219: Using unknown ptr "dev" illegally! set by 'init_trdev':217 Fixed. > [BUG] kmalloc can return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/tokenring/olympic.c:226:olympic_scan: >ERROR:NULL:212:226: Using unknown ptr "olympic_priv" illegally! set by 'kmalloc':212 Seems to be fixed already in my 2.4.3-pre4 tree. > [BUG] dev_alloc_skb can return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/tokenring/smctr.c:3956:smctr_process_rx_packet: >ERROR:NULL:3955:3956: Using unknown ptr "skb" illegally! set by 'dev_alloc_skb':3955 Seems to be fixed already in my 2.4.3-pre4 tree. > [BUG] dev_alloc_skb can return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/tokenring/smctr.c:4633:smctr_rx_frame: >ERROR:NULL:4630:4633: Using unknown ptr "skb" illegally! set by 'dev_alloc_skb':4630 Fixed. > [BUG] dev_alloc_skb can return NULL > >/u2/acc/oses/linux/2.4.1/drivers/net/tokenring/tms380tr.c:2167:tms380tr_rcv_status_irq: > ERROR:NULL:2149:2167: Using NULL ptr "skb" illegally! set by 'dev_alloc_skb':2149 Seems to be fixed already in my 2.4.3-pre4 tree. > [BUG] dev_alloc_skb can return NULL > >/u2/acc/oses/linux/2.4.1/drivers/net/tokenring/tms380tr.c:2172:tms380tr_rcv_status_irq: > ERROR:NULL:2149:2172: Using NULL ptr "skb" illegally! set by 'dev_alloc_skb':2149 Fixed. > [BUG] kmalloc can return NULL > /u2/acc/oses/linux/2.4.1/drivers/pci/setup-res.c:166:pdev_sort_resources: >ERROR:NULL:165:166: Using unknown ptr "tmp" illegally! set by 'kmalloc':165 > > Start ---> > tmp = kmalloc(sizeof(*tmp), GFP_KERNEL); > Error ---> > tmp->next = ln; > tmp->res = r; > - > [BUG] kmalloc can return NULL > /u2/acc/oses/linux/2.4.1/drivers/pcmcia/bulkmem.c:231:setup_erase_request: >ERROR:NULL:230:231: Using unknown ptr "busy" illegally! set by 'kmalloc':230 > > Start ---> > busy = kmalloc(sizeof(erase_busy_t), GFP_KERNEL); > Error ---> This sizeof() construct may be a special case for your checker, but it's a common one for the kernel... It definitely doesn't de-reference a pointer. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 28 potential interrupt errors
Junfeng Yang wrote: > [BUG] error path > > /u2/acc/oses/linux/2.4.1/drivers/net/appletalk/cops.c:776:cops_rx: >ERROR:INTR:763:804: Interrupts inconsistent, severity `20':804 Fixed. Request: can the checker check for skb's being freed correctly? The rules: If an skb is in interrupt context, call dev_kfree_skb_irq. If an skb might be in interrupt context, call dev_kfree_skb_any. If an skb is not in interrupt context, call dev_kfree_skb. I also found and fixed an error of this sort on cops.c as well. > [BUG] error path. this bug is interesting > > >/u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/wavelan_cs.c:2561:wavelan_get_wireless_stats: > ERROR:INTR:2528:2561: Interrupts inconsistent, severity `20':2561 > > /* Disable interrupts & save flags */ > Start ---> > spin_lock_irqsave (&lp->lock, flags); > > if(lp == (net_local *) NULL) > return (iw_stats *) NULL; Fixed. I dunno WTF the programmer was thinking here... Your de-ref checker should have caught this too: check 'lp' for NULL after de-referencing lp->lock. > [BUG] error path > > /u2/acc/oses/linux/2.4.1/drivers/net/tokenring/smctr.c:3655:smctr_open_tr: >ERROR:INTR:3594:3661: Interrupts inconsistent, severity `20':3661 Seems to be fixed already. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Where to find -pre releases?
"George R. Kasica" wrote: > Where in the ftp sites should I find the 2.4.3 -pre kernels? The > instructions from freshmeat are not correct and I just can't remember > the location... ftp://ftp.??.kernel.org/pub/linux/kernel/testing/ ?? == country code: us, de, dk, uk, ... Maybe I'm blind, but I didn't find an answer to this in the FAQ at http://www.tux.org/lkml/ Richard Gooch, FAQ maintainer, is CC'd. Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Q: "kapm-idled" and CPU usage
The message quoted below is from a MandrakeSoft co-worker and friend, in a thread discussing APM's kernel thread, and how the idle function uses CPU time. This thread was in response to yet another Bugzilla bug report about kapm-idled using CPU time. Several months ago, kapmd was renamed to kapm-idled in an attempt to signal users that it was a special process, and that its CPU time wasn't "real CPU time." This hasn't silenced the bug reports and confusion. Is there some way to hack the scheduler statistics so that idle processes are special cases, which do not accumulate CPU time nor contribute to the load average? I agree that it's not pretty to special case idle function process(es), but those idle functions in turn are causing an incorrect picture of the system state to be presented to userland. Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. Guillaume Cottenceau wrote: > On the other hand, you'll agree Jeff that it needs some fixing: it's > fucking up many statistics such as load average and instant cpu usage, and > is very confusing for people.. > > On another side, what I don't understand is that its cpu usage is not > constant, which makes people things it's sort of a bug: for example my > machine is up 1 day, 18:33 with 2.4.2-15mdk, kapm-ideld is reported to > have consumed 1355m, but currently it's staying at 0.0% of cpu. Sometimes > it gets bigger, sometimes it gets lower. Rather confusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA serial CardBus support vanished in 2.4.3-pre3 and later
Alessandro Suardi wrote: > > Sorry to repost the issue but I got no reply... > > 2.4.3-pre3 and synced-up versions of the -ac series remove support for > PCMCIA serial CardBus. In drivers/char/pcmcia the Makefile and Config.in > files are modified to exclude serial_cb and the serial_cb.c file itself > is removed by the patch. As a net result, my Xircom modem port becomes > invisible to the kernel and I can't dial out through it. > > As a temporary measure I backed out the changes in drivers/char/pcmcia > and my 2.4.3-pre4 kernel seems happy (in fact I am dialing out through > said Xircom modem). > > Did I miss some announcement for replacement features for serial_cb or > did a bad patch slip in ? Neither. serial.c does serial_cb's job now. It looks like serial.c needs to scan for modems as well as serial ports, and tytso agrees with me on that. We just need to check and see if winmodems reports themselves as real modems before fixing this. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA serial CardBus support vanished in 2.4.3-pre3 and later
On Tue, 20 Mar 2001, Alessandro Suardi wrote: > Jeff Garzik wrote: > > Neither. serial.c does serial_cb's job now. It looks like serial.c > > needs to scan for modems as well as serial ports, and tytso agrees with > > me on that. We just need to check and see if winmodems reports > > themselves as real modems before fixing this. > OK, thanks. I assume you mean "serial.c should do serial_cb's job now", > since it doesn't :) If you want me to test patches etc. just let me know. Re-CC'd to linux-kernel, hope you don't mind. Anyone interested in testing patches, this simple change is what needs testing on various PCI and CardBus modems: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg34097.html (since it's a web archive, you may have to hack the patch in manually...) It seems straightforward enough, and both tytso and I think the change is ok, but (at tytso's suggestion) I'm going to test some various winmodem and other use cases because assuring ourselves that it is good enough for a general rule... Regards, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: modules_install does not install acpi with linux-2.4.2
"Juergen Rose,K17,0331-9772437,030-2425483" wrote: > if I try 'make modules_install' with linux-2.4.2 I get: > ... > mkdir -p /lib/modules/2.4.2/kernel/drivers/acpi/ > cp common.o dispatcher.o events.o hardware.o interpreter.o namespace.o > parser.o resources.o tables.o os.o acpi_ksyms.o driver.o cmbatt.o cpu.o > ec.o acpi_ksyms.o sys.o table.o power.o > /lib/modules/2.4.2/kernel/drivers/acpi/ > cp: common.o: No such file or directory ... > cp: tables.o: No such file or directory > make[2]: *** [_modinst__] Error 1 > make[2]: Leaving directory `/usr/src_laptop450/linux-2.4.2/drivers/acpi' > In .config I find with respect to ACPI only > CONFIG_ACPI=m > > Who can help me? Doctor says: don't do that. :) I don't know how you managed CONFIG_ACPI=m, because the configuration system doesn't allow it. "dep_bool" means only Y or N, and we see the CONFIG_ACPI entry in arch/i386/config.in is correct: [jgarzik@rum linux_2_4]$ egrep -rw 'CONFIG_PM|CONFIG_ACPI' arch [...edited output...] arch/arm/config.in: bool 'Power Management support' CONFIG_PM arch/i386/config.in:bool 'Power Management support' CONFIG_PM arch/i386/config.in: dep_bool ' ACPI support' CONFIG_ACPI $CONFIG_PM arch/i386/defconfig:CONFIG_PM=y arch/ia64/config.in: define_bool CONFIG_PM y arch/ia64/config.in: define_bool CONFIG_ACPI y So the solution is not build ACPI as a module, because it shouldn't have allowed you to do so in the first place :) -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: PCMCIA serial CardBus support vanished in 2.4.3-pre3 and later
On closer inspection, that patch I linked to appears to be incomplete.
Can you try the attached patch, to see if it fixes the
absence-of-serial_cb problem?
Thanks,
Jeff
P.S. I'm surprised serial_cb in 2.4 worked at all, for anybody. I guess
they must be using pcmcia_cs's serial_cb, not the kernel's serial_cb...
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
Index: drivers/char/serial.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/char/serial.c,v
retrieving revision 1.1.1.33
diff -u -r1.1.1.33 serial.c
--- drivers/char/serial.c 2001/03/20 12:59:44 1.1.1.33
+++ drivers/char/serial.c 2001/03/20 15:35:47
@@ -59,8 +59,8 @@
*
*/
-static char *serial_version = "5.05";
-static char *serial_revdate = "2000-12-13";
+static char *serial_version = "5.05a";
+static char *serial_revdate = "2001-03-20";
/*
* Serial driver configuration section. Here are the various options:
@@ -4610,7 +4610,8 @@
* (Should we try to make guesses for multiport serial devices
* later?)
*/
- if ((dev->class >> 8) != PCI_CLASS_COMMUNICATION_SERIAL ||
+ if dev->class >> 8) != PCI_CLASS_COMMUNICATION_SERIAL) &&
+ ((dev->class >> 8) != PCI_CLASS_COMMUNICATION_MODEM)) ||
(dev->class & 0xff) > 6)
return 1;
@@ -4708,6 +4709,8 @@
static struct pci_device_id serial_pci_tbl[] __devinitdata = {
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_COMMUNICATION_SERIAL << 8, 0x00, },
+ { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
+PCI_CLASS_COMMUNICATION_MODEM << 8, 0x00, },
{ 0, }
};
Re: NETDEV WATCHDOG: eth0: transmit timed out on LNE100TX 4.0, kernel2.4.2-ac11 and earlier.
"Manuel A. McLure" wrote: > > System: > AMD Athlon Thunderbird 900MHz > MSI K7T Pro (VIA KT133 chipset) > Network card: Linksys LNE100TX Rev. 4.0 (tulip) > Kernel: 2.2.18 (with 0.92 Scyld drivers), 2.4.0, 2.4.1, 2.4.2, 2.4.2-ac11 > > With all the above kernel revisions/drivers, my network card hangs at random > (sometimes within minutes, other times it takes days). To restart it I need > to do an ifdown/ifup cycle and it will work fine until the next hang. I > upgraded to 2.4.2-ac11 because of the documented tulip fixes, but after a > few days got this again. The error log shows: In Alan Cox terms, that's a long time ago :) Can you please try 2.4.2-ac20? It includes fixes specifically for this problem. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA audio and parport in 2.4.2
Tim Waugh wrote: > > On Mon, Mar 19, 2001 at 12:16:26AM +, Will Newton wrote: > > > In /etc/modules.conf I have: > > > > options parport_pc irq=none > > > > but dmesg says: > > > > parport0: PC-style at 0x378 (0x778), irq 7, dma 3 > > [PCSPP,TRISTATE,COMPAT,ECP,DMA] > > Jeff, this is a bug with the Via code in parport_pc.c. Basically, the > problem is that the code that detects the Via doesn't know what > parameters you passed. I know about the problem, but I don't know the > fix yet. Will, What are your parallel port settings in BIOS? Do you have Plug-n-Play OS enabled in BIOS? The current Via-specific parport_pc.c code forces on the best possible parallel port modes the chip can handle. In retrospect, what it should be doing is reading the configuration BIOS has set up, and not touching it. I am not sure that I agree, however, that an "irq=none" on the kernel cmd line should affect the operation of the Via code. I would much rather fix the Via code as I suggest above. Time to look for and drag out the old Via laptop... Oh well, I needed to debug the Via audio code some more anyway. :) Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] RFC: Network driver info to userspace
In various scenarios where userland needs to interact with hardware,
userland often needs to know exactly what driver (and driver version) is
currently running on a given interface. Hotplugging and other
applications could -really- use the ability to find out bus information
for a given interface. Firmware
So I propose the attached addition to the ethtool interface. It adds a
new structure with several ASCII text fields, which are filled in at the
driver's discretion. Userland then interprets these fields for their
own evil designs.
Currently (AFAIK) for all kernel interfaces, userland has no reliable
way to associate a hardware device with a kernel interface, or a driver
with a kernel interface[1]. Since we have no generic register_driver()
interface, solving this problem means implementing a domain-specific
solution like I have done here...
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
Index: include/linux/ethtool.h
===
RCS file: /cvsroot/gkernel/linux_2_4/include/linux/Attic/ethtool.h,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 ethtool.h
--- include/linux/ethtool.h 2000/11/14 22:01:49 1.1.1.2
+++ include/linux/ethtool.h 2001/03/21 12:42:15
@@ -24,10 +24,21 @@
u32 reserved[4];
};
+/* these strings are set to whatever the driver author decides... */
+struct ethtool_drvinfo {
+ chardriver[32]; /* driver short name, "tulip", "eepro100" */
+ charversion[32];/* driver version string */
+ charfw_version[32]; /* firmware version string, if applicable */
+ charbus_info[32]; /* Bus info for this interface. For PCI
+* devices, use pci_dev->slot_name. */
+ charreserved1[32];
+ charreserved2[32];
+};
/* CMDs currently supported */
-#define ETHTOOL_GSET 0x0001 /* Get settings, non-privileged. */
+#define ETHTOOL_GSET 0x0001 /* Get settings. */
#define ETHTOOL_SSET 0x0002 /* Set settings, privileged. */
+#define ETHTOOL_GDRVINFO 0x0003 /* Get driver info. */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
Re: VIA audio and parport in 2.4.2
Will Newton wrote: > On Tue, 20 Mar 2001, Jeff Garzik wrote: > > I am not sure that I agree, however, that an "irq=none" on the kernel > > cmd line should affect the operation of the Via code. I would much > > rather fix the Via code as I suggest above. > > irq=none seems pretty unequivocal to me, I'm not sure how easy it is to > explain to a user that irq=none doesn't do what it says. For this specific case, Via motherboards, we know exactly whether or not an interrupt was assigned to the parallel port, and whether or not the parallel port is in an interrupt-driven mode. Attempting to pretend that the parallel port is not in an interrupt driven mode by passing irq=none is folly. If irq=none is passed to tell the Via code to -force- the parallel port into a non-irq-driven mode is one thing. If irq=none is passed to hide a problem with spurious interrupts, we need to fix that problem, not hide it. So as I see it, I should fix the Via code to read (only!) the parallel port configuration from BIOS, and set up the parallel port that way. I still am not convinced that irq= should affect the Via code at all. Maybe I can print out a message "irq=foo ignored". Optionally, I could handle irq=none by force-disabling the parallel port's interrupt driven modes, if they are active. I don't want to do this, but may be forced to by circumstance... -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: [PATCH] 2.4.3-pre6 - hdlc/dscc4 missing bits
You should use this patch instead, from Alan's tree, for updating include/linux/if_arp.h... -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. Index: include/linux/if_arp.h === RCS file: /cvsroot/gkernel/linux_2_4/include/linux/if_arp.h,v retrieving revision 1.1.1.21 diff -u -r1.1.1.21 if_arp.h --- include/linux/if_arp.h 2001/03/20 12:54:44 1.1.1.21 +++ include/linux/if_arp.h 2001/03/21 15:49:59 @@ -50,9 +50,11 @@ #define ARPHRD_X25 271 /* CCITT X.25 */ #define ARPHRD_HWX25 272 /* Boards with X.25 in firmware */ #define ARPHRD_PPP 512 -#define ARPHRD_HDLC513 /* (Cisco) HDLC */ +#define ARPHRD_CISCO 513 /* Cisco HDLC */ +#define ARPHRD_HDLCARPHRD_CISCO #define ARPHRD_LAPB516 /* LAPB */ #define ARPHRD_DDCMP517/* Digital's DDCMP protocol */ +#define ARPHRD_RAWHDLC 518 /* Raw HDLC */ #define ARPHRD_TUNNEL 768 /* IPIP tunnel */ #define ARPHRD_TUNNEL6 769 /* IPIP6 tunnel */
Re: [PATCH] Re: [PATCH] Re: [PATCH] 2.4.3-pre6 - hdlc/dscc4 missing bits
Francois Romieu wrote: > > Jeff Garzik <[EMAIL PROTECTED]> écrit : > > You should use this patch instead, from Alan's tree, for updating > > include/linux/if_arp.h... > > It adds confusion: do you imagine the poor soul who discovers hdlc in Linux > and sees ARPHRD_CISCO and ARPHRD_HDLC for the same use after some hours > of code-greping (both will be used at the moment if hdlc.c do so) ? > Don't be surprised if he ends using label pointers everywhere. :o) > > What about the following (2.5 ?): That looks like 2.5 material to me. Personally I wouldn't want to remove identifiers during 2.4 stable series.. Changing all 2.4 code to use one identifier or the other seems reasonable. Make sure to sync with Alan. WAN stuff has been occurring in his tree, and we want to make sure everybody's on the same page.. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcnet32 compilation fix for 2.4.3pre6
Andrzej Krzysztofowicz wrote: > > Hi, > It looks like a not fully merged patch from Alan's tree: > > drivers/net/net.o: In function `pcnet32_open': > drivers/net/net.o(.text+0x3bb9): undefined reference to `is_valid_ether_addr' > drivers/net/net.o: In function `pcnet32_probe1': > drivers/net/net.o(.text.init+0x5fa): undefined reference to `is_valid_ether_addr' Ouch, missed that. Thanks for the patch. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: standard_io_resources[]
Tomasz Sterna wrote: > > On Wed, Mar 21, 2001 at 09:13:05AM -0800, James Simmons wrote: > > >Isn't that a job of the device drivers? > > Well most of those resources are present on every PC motherboard. > > I still can't see a reason for allocating it before the device drivers > could do that. > > Any suggestions? Anyone? If you write into those resources and they are absent, bad things sometimes happen. So, they are always added to the reserved-resource list. I already had this argument with Linus :) Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18: e100.c (SuSE 7.1): udelay() used in a wrong way?
Ulrich Windl wrote:
> void
> Phy82562EHDelayMilliseconds(int Time)
> {
> udelay(Time);
> }
>
> AFAIK, udelay() delays microseconds, not milliseconds.
Yep, you are correct, and the code is incorrect.
mdelay() delays milliseconds.
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pcnet32 compilation fix for 2.4.3pre6
hmm, on second thought, I think I would prefer the attached patch
(compiled but not tested).
Hardware usually returns all 1's when it's not present, or not working,
so think checking for addresses filled with 1's is a good idea too.
I also took the patch from alan's tree and made the memcmp against
six-byte 'zaddr' rather than a seven-byte string :)
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
Index: include/linux/etherdevice.h
===
RCS file: /cvsroot/gkernel/linux_2_4/include/linux/etherdevice.h,v
retrieving revision 1.1.1.14.4.2
diff -u -r1.1.1.14.4.2 etherdevice.h
--- include/linux/etherdevice.h 2001/03/21 14:10:50 1.1.1.14.4.2
+++ include/linux/etherdevice.h 2001/03/22 13:37:15
@@ -46,6 +46,25 @@
memcpy (dest->data, src, len);
}
+/**
+ * is_valid_ether_addr - Determine if the given Ethernet address is valid
+ * @addr: Pointer to a six-byte array containing the Ethernet address
+ *
+ * Check that the Ethernet address (MAC) is not 00:00:00:00:00:00, is not
+ * a multicast address, and is not FF:FF:FF:FF:FF:FF.
+ *
+ * Return true if the address is valid.
+ */
+static inline int is_valid_ether_addr( u8 *addr )
+{
+ const char zaddr[6] = {0,};
+ const char faddr[6] = {0xFF,0xFF,0xFF,0xFF,0xFF,0xFF};
+
+ return !(addr[0]&1) &&
+ memcmp( addr, zaddr, 6) &&
+ memcmp( addr, faddr, 6);
+}
+
#endif
#endif /* _LINUX_ETHERDEVICE_H */
Re: [PATCH] pcnet32 compilation fix for 2.4.3pre6
Eli Carter wrote:
> The "!(addr[0]&1)" part of the test already catches the ff's case, so
> that is redundant.
> Using 6 bytes instead of 7 is an improvement.
oops. Thanks, updated patch attached. My patch also adds inline source
docs, and uses 'static inline' instead of 'static __inline__', two small
style improvements.
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
Index: include/linux/etherdevice.h
===
RCS file: /cvsroot/gkernel/linux_2_4/include/linux/etherdevice.h,v
retrieving revision 1.1.1.14.4.2
diff -u -r1.1.1.14.4.2 etherdevice.h
--- include/linux/etherdevice.h 2001/03/21 14:10:50 1.1.1.14.4.2
+++ include/linux/etherdevice.h 2001/03/22 14:44:51
@@ -46,6 +46,22 @@
memcpy (dest->data, src, len);
}
+/**
+ * is_valid_ether_addr - Determine if the given Ethernet address is valid
+ * @addr: Pointer to a six-byte array containing the Ethernet address
+ *
+ * Check that the Ethernet address (MAC) is not 00:00:00:00:00:00, is not
+ * a multicast address, and is not FF:FF:FF:FF:FF:FF.
+ *
+ * Return true if the address is valid.
+ */
+static inline int is_valid_ether_addr( u8 *addr )
+{
+ const char zaddr[6] = {0,};
+
+ return !(addr[0]&1) && memcmp( addr, zaddr, 6);
+}
+
#endif
#endif /* _LINUX_ETHERDEVICE_H */
Re: [PATCH] pcnet32 compilation fix for 2.4.3pre6
Eli Carter wrote: > Mmmm documentation. Yummy. ;) > > When I submitted the original patch, someone wanted to add the ff's > check as well... to reduce the number of people who make that > suggestion, perhaps the comment should read: > > + * Check that the Ethernet address (MAC) is not a multicast address or > + * FF:FF:FF:FF:FF:FF (by checking addr[0]&1) and is not > 00:00:00:00:00:00. > + * > > Does that make it clear that both cases are covered by the one test? yeah > Hmm... I used __inline__ because the other function in the same > headerfile used it... What is the difference between the two, and is > one depricated now? (And what about in 2.2.x?) since kernel requires gcc, which supports plaine ole 'inline', we don't need to use the longer form. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
General 2.4 impressions (was Re: [PATCH] Prevent OOM from killing init)
Personally I think the OOM killer itself is fine. I think there are problems elsewhere which are triggering the OOM killer when it should not be triggered, ie. a leak like Doug Ledford was reporting. I definitely see heavier page/dcache usage in 2.4 -- but that is to be expected due to 2.4 changes! So it is incredibily difficult to quantify if something is wrong, and if so, where... My own impressions of 2.4 are that it "feels faster" for my own uses and it's stable. The downsides I find are that heavy fs activity seems to imply increased swapping, which jibes with a guess that the page/dcache is exceptionally greedy with releasing pages under memory pressure. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
Also for 2.5, kdev_t needs to go away, along with all those arrays based on major number, and be replaced with either "struct char_device" or "struct block_device" depending on the device. I actually went through the kernel in 2.4.0-test days and did this. Most kdev_t usages should really be changed to "struct block_device". The only annoyance in the conversion was ROOT_DEV and similar things that are tied into the boot process. I didn't want to change that and potentially break the boot protocol... -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH 2.4.3.6: fix netdevice initialization
(Linus, please do not apply this. After some patch review, I'll send
this to you along with driver updates to use it)
Attached is a patch against 2.4.3-pre6, which adds alloc_etherdev and
variants to the driver API. This API addition should allow us to close
the gaping race between init_etherdev call time, and when the network
device is actually ready.
This version removes the DECLARE_xxx at the request of the crowd.
Hooray for cut-n-paste code... please check for errors.
Driver API changes for this stable kernel series are:
* Six functions added,
* Four prototypes moved from netdevice.h to foodevice.h, and
* No behavior changes, no code changes requiring immediate driver
updates
Main change in this patch:
* New functions alloc_etherdev, alloc_fddidev, alloc_hippi_dev,
alloc_fcdev, alloc_trdev
Cleanup changes in this patch:
* Move prototypes from netdevice.h to foodevice.h: [un]register_fcdev,
[un]register_trdev
* Add inline source docs for init_xxxdev
* Move EXPORT_SYMBOL for public functions from net/netsyms.c to
net_init.c
* New function register_hipdev, for API completeness
* Remove duplicate code from unregister_hipdev, [un]register_trdev,
[un]register_fcdev
* tr_setup was exported but did nothing. Rename tr_configure to
tr_setup, remove old no-op tr_setup.
--
Jeff Garzik | More novel than War and Peace
Building 1024 | More tongue-in-cheek than a lesbian orgy
MandrakeSoft | Sneakin' up like celery, yeah I'm stalkin'
Index: drivers/net/net_init.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/net_init.c,v
retrieving revision 1.1.1.8
retrieving revision 1.1.1.8.34.3
diff -u -r1.1.1.8 -r1.1.1.8.34.3
--- drivers/net/net_init.c 2001/02/27 03:03:50 1.1.1.8
+++ drivers/net/net_init.c 2001/03/21 14:10:50 1.1.1.8.34.3
@@ -28,10 +28,12 @@
up. We now share common code and have regularised name
allocation setups. Abolished the 16 card limits.
03/19/2000 - jgarzik and Urban Widmark: init_etherdev 32-byte align
+ 03/21/2001 - jgarzik: alloc_etherdev and friends
*/
#include
+#include
#include
#include
#include
@@ -68,6 +70,33 @@
*/
+static struct net_device *alloc_netdev(int sizeof_priv, const char *mask,
+ void (*setup)(struct net_device *))
+{
+ struct net_device *dev;
+ int alloc_size;
+
+ /* ensure 32-byte alignment of the private area */
+ alloc_size = sizeof (*dev) + sizeof_priv + 31;
+
+ dev = (struct net_device *) kmalloc (alloc_size, GFP_KERNEL);
+ if (dev == NULL)
+ {
+ printk(KERN_ERR "alloc_dev: Unable to allocate device memory.\n");
+ return NULL;
+ }
+
+ memset(dev, 0, alloc_size);
+
+ if (sizeof_priv)
+ dev->priv = (void *) (((long)(dev + 1) + 31) & ~31);
+
+ setup(dev);
+ strcpy(dev->name, mask);
+
+ return dev;
+}
+
static struct net_device *init_alloc_dev(int sizeof_priv)
{
struct net_device *dev;
@@ -142,6 +171,17 @@
return dev;
}
+static int __register_netdev(struct net_device *dev)
+{
+ dev_init_buffers(dev);
+
+ if (dev->init && dev->init(dev) != 0) {
+ unregister_netdev(dev);
+ return -EIO;
+ }
+ return 0;
+}
+
/**
* init_etherdev - Register ethernet device
* @dev: An ethernet device structure to be filled in, or %NULL if a new
@@ -164,6 +204,25 @@
return init_netdev(dev, sizeof_priv, "eth%d", ether_setup);
}
+/**
+ * alloc_etherdev - Register ethernet device
+ * @sizeof_priv: Size of additional driver-private structure to be allocated
+ * for this ethernet device
+ *
+ * Fill in the fields of the device structure with ethernet-generic values.
+ *
+ * Constructs a new net device, complete with a private data area of
+ * size @sizeof_priv. A 32-byte (not bit) alignment is enforced for
+ * this private data area.
+ */
+
+struct net_device *alloc_etherdev(int sizeof_priv)
+{
+ return alloc_netdev(sizeof_priv, "eth%d", ether_setup);
+}
+
+EXPORT_SYMBOL(init_etherdev);
+EXPORT_SYMBOL(alloc_etherdev);
static int eth_mac_addr(struct net_device *dev, void *p)
{
@@ -184,11 +243,48 @@
#ifdef CONFIG_FDDI
+/**
+ * init_fddidev - Register FDDI device
+ * @dev: A FDDI device structure to be filled in, or %NULL if a new
+ * struct should be allocated.
+ * @sizeof_priv: Size of additional driver-private structure to be allocated
+ * for this ethernet device
+ *
+ * Fill in the fields of the device structure with FDDI-generic values.
+ *
+ * If no device structure is passed, a new one is constructed, complete with
+ * a private data area of size @sizeof_priv. A 32-byte (not bit)
+ * alignment is enforced for this private data area.
+ *
+ * If an empty string area is
Re: PATCH 2.4.3.6: fix netdevice initialization
I have this bad habit of thinking of things after I click . One other change that accompanies this -- define a feature macro. The following should go into linux/netdevice.h: #define HAVE_ALLOC_NETDEV -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM handling
Martin Dalecki wrote: > Rik van Riel wrote: > > - the comments are just too rude ;) > > (though fun) > > That's only a matter for the "smooth" anglosaxons. Different > cultures have different measures on this. I don't feel the need > to adjust myself to the american cultural obstructivity. > I esp. to the habit of don't saying clearly what one means if one > want's to criticize something. Rik should know that lkml and the kernel sources are in no way politically correct... Fuck 'em... :) Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
Michel Wilson wrote: > Ever thought about how you would kill a process: kill -9 127892752 doesn't > sound very appealing to me. man killall(1). Kill processes by name. > So you'd also need to implement a mechanism that allows for 'easy' selection > of processes to kill, for example giving every process with the same name > a unique identifier (like httpd_0, httpd_1, httpd_2 and so on). huh? -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH 2.4.3.7: net drvr probe fix
The attached patch provides a solution for the problem where an
interface is not completely ready by the time /sbin/hotplug is called,
from init_etherdev. The patch also includes semi-related cleanups and
fixes found along the way.
Changes:
* Add alloc_etherdev, alloc_fddidev, alloc_hippi_dev, alloc_trdev, alloc_fcdev
* Add register_hipdev for API completeness
* Add inline source docs for init_fddidev, init_hippi_dev, init_trdev,
init_fcdev
* Move EXPORT_SYMBOL for public functions from net/netsyms.c to
drivers/net/net_init.c.
* Remove duplicate code by making unregister_foo functions simply call
unregister_netdev()
* Remove duplicate code by making register_foo functions simply call
new static function __register_netdev()
* Propagate returned error codes in register_netdev()
* Rename private tr_configure() to public tr_setup(), and remove no-op
tr_setup() function.
diff -u linux_2_4/drivers/net/net_init.c:1.1.1.8
linux_2_4/drivers/net/net_init.c:1.1.1.8.38.2
--- linux_2_4/drivers/net/net_init.c:1.1.1.8Mon Feb 26 19:03:50 2001
+++ linux_2_4/drivers/net/net_init.cSun Mar 25 12:43:06 2001
@@ -28,10 +28,12 @@
up. We now share common code and have regularised name
allocation setups. Abolished the 16 card limits.
03/19/2000 - jgarzik and Urban Widmark: init_etherdev 32-byte align
+ 03/21/2001 - jgarzik: alloc_etherdev and friends
*/
#include
+#include
#include
#include
#include
@@ -68,6 +70,33 @@
*/
+static struct net_device *alloc_netdev(int sizeof_priv, const char *mask,
+ void (*setup)(struct net_device *))
+{
+ struct net_device *dev;
+ int alloc_size;
+
+ /* ensure 32-byte alignment of the private area */
+ alloc_size = sizeof (*dev) + sizeof_priv + 31;
+
+ dev = (struct net_device *) kmalloc (alloc_size, GFP_KERNEL);
+ if (dev == NULL)
+ {
+ printk(KERN_ERR "alloc_dev: Unable to allocate device memory.\n");
+ return NULL;
+ }
+
+ memset(dev, 0, alloc_size);
+
+ if (sizeof_priv)
+ dev->priv = (void *) (((long)(dev + 1) + 31) & ~31);
+
+ setup(dev);
+ strcpy(dev->name, mask);
+
+ return dev;
+}
+
static struct net_device *init_alloc_dev(int sizeof_priv)
{
struct net_device *dev;
@@ -142,6 +171,17 @@
return dev;
}
+static int __register_netdev(struct net_device *dev)
+{
+ dev_init_buffers(dev);
+
+ if (dev->init && dev->init(dev) != 0) {
+ unregister_netdev(dev);
+ return -EIO;
+ }
+ return 0;
+}
+
/**
* init_etherdev - Register ethernet device
* @dev: An ethernet device structure to be filled in, or %NULL if a new
@@ -164,6 +204,25 @@
return init_netdev(dev, sizeof_priv, "eth%d", ether_setup);
}
+/**
+ * alloc_etherdev - Register ethernet device
+ * @sizeof_priv: Size of additional driver-private structure to be allocated
+ * for this ethernet device
+ *
+ * Fill in the fields of the device structure with ethernet-generic values.
+ *
+ * Constructs a new net device, complete with a private data area of
+ * size @sizeof_priv. A 32-byte (not bit) alignment is enforced for
+ * this private data area.
+ */
+
+struct net_device *alloc_etherdev(int sizeof_priv)
+{
+ return alloc_netdev(sizeof_priv, "eth%d", ether_setup);
+}
+
+EXPORT_SYMBOL(init_etherdev);
+EXPORT_SYMBOL(alloc_etherdev);
static int eth_mac_addr(struct net_device *dev, void *p)
{
@@ -184,11 +243,48 @@
#ifdef CONFIG_FDDI
+/**
+ * init_fddidev - Register FDDI device
+ * @dev: A FDDI device structure to be filled in, or %NULL if a new
+ * struct should be allocated.
+ * @sizeof_priv: Size of additional driver-private structure to be allocated
+ * for this ethernet device
+ *
+ * Fill in the fields of the device structure with FDDI-generic values.
+ *
+ * If no device structure is passed, a new one is constructed, complete with
+ * a private data area of size @sizeof_priv. A 32-byte (not bit)
+ * alignment is enforced for this private data area.
+ *
+ * If an empty string area is passed as dev->name, or a new structure is made,
+ * a new name string is constructed.
+ */
+
struct net_device *init_fddidev(struct net_device *dev, int sizeof_priv)
{
return init_netdev(dev, sizeof_priv, "fddi%d", fddi_setup);
}
+/**
+ * alloc_fddidev - Register FDDI device
+ * @sizeof_priv: Size of additional driver-private structure to be allocated
+ * for this FDDI device
+ *
+ * Fill in the fields of the device structure with FDDI-generic values.
+ *
+ * Constructs a new net device, complete with a private data area of
+ * size @sizeof_priv. A 32-byte (not bit) alignment is enforced for
+ * this private data area.
+ */
+
+struct net_device *alloc_fddidev(int sizeof_priv)
+{
+ return alloc_netdev(sizeof_priv, "fddi%d", fddi_setup);
+}
+
+EXPORT_SYMBOL(init_fddidev);
Re: CML1 cleanup patch
Peter Samuelson wrote: > > [esr] > > CONFIG_8139TOOCONFIG_RTL8139TOO > > CONFIG_8139TOO_PIOCONFIG_RTL8139TOO_PIO > > CONFIG_8139TOO_TUNE_TWISTER CONFIG_RTL8139TOO_TUNE_TWISTER > > The -TOO suffix was to distinguish between this and the former 8139 > driver, as the two coexisted in 2.2 and 2.3. As the old driver has > been dropped from 2.4, I propose likewise dropping the -TOO. It stays "8139too". Donald Becker's rtl8139.c continues to exist outside the kernel. And "rtl8139too" should have never crept into 2.2. That needs to be changed to "8139too." That's what I get for saying that I don't support 2.2... -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML1 cleanup patch
Well, bummer. I can't seem to find Eric's message archived anywhere. FWIW I am opposed to any large-scale cleanup of the configuration language and/or identifiers in -any- 2.4.x series kernel. Not only C code but installer utilities are affected by changes in the CONFIG_xxx identifiers. If we change that namespace, we are changing part of the API that is exported to drivers. Definitely not 2.4.x stuff. If we are moving to CML2 in 2.5, I see no point in big CML1 cleanups. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML1 cleanup patch
"Eric S. Raymond" wrote: > I don't care, as long as the result has a non-numeric > prefix -- bare "8139whatever" is out. Bullshit. Numeric prefixes work fine in CML1. With regards to CML2, hardware and driver filenames quite often begin with numerals, so it is quite logical that config variables may begin with a numeral. You're writing CML2. Don't create a stupid namespace with stupid limitations. I'm glad my filesystem and my sysctl namespace don't have such limitations. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML1 cleanup patch
"Eric S. Raymond" wrote: > Jeff Garzik <[EMAIL PROTECTED]>: > > FWIW I am opposed to any large-scale cleanup of the configuration > > language and/or identifiers in -any- 2.4.x series kernel. > > This is tweaking 39 symbols out of 1831, hardly large-scale. These > irregularities in the namespace cause trouble out of all proportion to > their size, is my problem. If you knew what I've been through trying > to write analysis tools...*shudder*... They cause trouble for you, solely, at the moment. Changing the CML1 namespace potentially causes trouble for many people. > > Not only C code but installer utilities are affected by changes in the > > CONFIG_xxx identifiers. If we change that namespace, we are changing > > part of the API that is exported to drivers. Definitely not 2.4.x > > stuff. > > My patch fixes those installer utilities. All three of them. And no driver > code is or possibly could be broken by it, that's a red herring. *No > object code will change as a result of this patch*. You updated Linux-Mandrake's kernel RPM and Linux-Mandrake's installer? Cool! > I want this in before the 2.5 fork for several reasons: > > (1) 19 of the 39 changes fix things that are outright bugs even in CML1. > These should not be allowed to persist in the stable branch. Please post a patch with only these 19 changes, and make sure to CC it to linux-kernel. Thanks, Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML1 cleanup patch
"Eric S. Raymond" wrote:
> Jeff Garzik <[EMAIL PROTECTED]>:
> > You updated Linux-Mandrake's kernel RPM and Linux-Mandrake's installer?
> > Cool!
> No, I didn't. But I can't even imagine how these changes could break those.
Our kernel build process has to look at CONFIG_xxx because we build
multiple kernels from the same base .config.
> > Please post a patch with only these 19 changes, and make sure to CC it
> > to linux-kernel.
> I don't think this is your decision to make, is it?
I have no control over what you choose to do. It's a free 'net, and you
are free to ignore any and all suggestions.
The normal way to get patches into the kernel is to split them up. I
just sent Linus 21 patches, which got condensed into
> -pre8:
> [...]
> - Jeff Garzik: network driver updates, i810 rng driver, and
> "alloc_etherdev()" network driver insert race condition fix.
Separate out your changes. Make the maintainers aware of your changes.
ie. if it modifies my driver's CONFIG_xxx usage or my subsystem's
Config.in, let me know. ("me" == any maintainer)
Read Documentation/SubmittingPatches.
Jeff
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full moon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML1 cleanup patch
Keith Owens wrote: > That just leaves the 17 names of the form CONFIG_[0-9]*. Only the 8139 > is likely to affect outside the kernel and the argument that renaming > config options might affect external packages does not hold. The > recent aic7xxx change broke pcmcia on 2.2 kernels but we can work round > it. There is no good reason to restrict the CML2 identifier namespace. This is a policy change not a cleanup. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 243p8 problems
Mario Mikocevic wrote: > > Hi, > > 1st : > > # depmod -a 2.4.3-pre8 > depmod: *** Unresolved symbols in /lib/modules/2.4.3-pre8/kernel/drivers/net/dummy.o > depmod: *** Unresolved symbols in >/lib/modules/2.4.3-pre8/kernel/drivers/net/eepro100.o What are the unresolved symbols? -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix net driver load problems
Frank Jacobberger wrote: > > Something has changed regarding the 8139too driver in pre8. > > I worked on it all morning long trying to resolve why the sucker > failed to load. There are new configuration options that need to > be addressed. As you recall there were zippo options in the pre7. > > There are now: > > RealTek RTL-8139 PCI Fast Ethernet Adapter support [M] > Use PIO instead of MMIO > [*] Note by selecting this, you must made your driver slower. Did you read the help for the option? > Support for automatic channel equalization (EXPERIMENTAL) [ ] > Support for older RTL-8129/8130 boards[*] By selecting this you made your driver bigger, probably for no reason.. > Doing any combination of the above netted no positive result here. > > I have run every kernel patch since 2.4.0 blah and > have never seen this driver fail to load or perform to some degree. > > Trying to do insmod 8139too.o from the : > /lib/modules/2.4.3-pre8/kernel/drivers/net directory show these > unresolved symbols: > > 8139too.o: unresolved symbol alloc_etherdev > 8139too.o: unresolved symbol unregister_netdev > 8139too.o: unresolved symbol register_netdev > > Maybe Jeff can shed more light on these changes After staring hard at my source, I ran another diff and found that net_init is not listed in export-objs. Oh well, it's better to compile stuff into your kernel anyway ;-) ;-) Attached is a patch which fixes things. Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. Index: drivers/net/Makefile === RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/Makefile,v retrieving revision 1.1.1.32 retrieving revision 1.1.1.32.2.1 diff -u -r1.1.1.32 -r1.1.1.32.2.1 --- drivers/net/Makefile2001/03/26 04:48:45 1.1.1.32 +++ drivers/net/Makefile2001/03/26 05:29:41 1.1.1.32.2.1 @@ -15,8 +15,9 @@ # All of the (potential) objects that export symbols. # This list comes from 'grep -l EXPORT_SYMBOL *.[hc]'. -export-objs := 8390.o arlan.o aironet4500_core.o aironet4500_card.o ppp_async.o \ - ppp_generic.o slhc.o pppox.o auto_irq.o +export-objs := 8390.o arlan.o aironet4500_core.o aironet4500_card.o \ + ppp_async.o ppp_generic.o slhc.o pppox.o auto_irq.o \ + net_init.o ifeq ($(CONFIG_TULIP),y) obj-y += tulip/tulip.o
Re: Q: How do I get from the latest stable kernel version to the latest prepatch version ?
"Hen, Shmulik" wrote: > > Hi, > > According to http://www.kernel.org, the latest stable kernel version is > 2.4.2. The latest prepatch version is 2.4.3-pre3. > > In order to get a full 2.4.3-pre8 kernel do I have to: > > A. download linux-2.4.2.tar.gz and all the patch-2.4.3-preX.gz and apply > them in succession or, > B. download linux-2.4.3.tar.gz (exists ?) and then apply the all patches or, > C. download linux-2.4.3-pre7.tar.gz (exists ?) and apply only > patch-2.4.3-pre8.gz ? Apply only the latest patch, currently 2.4.3-pre8. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML1 cleanup patch, take 2
esr wrote: > OK, since peoples' territorial instincts have started to lather up, > I guess I'm going to have to do this the hard way... "Split up your patch" still apparently hasn't filtered into your head. Since that is more difficult than posting a single patch, I would say you are doing it the slack way, and the way that makes it more difficult for Linus and Alan to approve one part of your patch, and disapprove of another part. > This file is a patch expressed in two ways. First, procedurally, as a > way to duplicate its effects on any kernel source tree. Secondly, as > an explicit patch against 2.4.3-pre8. It replaces my previous patch > against 2.4.3-pre6. > > This patch is the first result of a consistency audit of the configuration > system. I have been building analysis tools to check the correctness of > my CML2 rules file, and the processs of testing them turned up some problems. > > The purpose of this patch is threefold: > > (1) Clean up two errors in the CML1 corpus that could lead to subtle bugs. > This is a BUG FIX in CML1. separate patch? > (2) Fix up 20 cris-architecture configuration symbols lacking a CONFIG_ > prefix, so they obey CML1/CML2 conventions and can be detected by > `make dep', also static-analysis tools and consistency checkers. > This is a BUG FIX in CML1. separate patch? What did the cris guys say, when you showed them this patch? I agree this change is a bug fix, but get the cris' guys input first. This should be in a separate patch, too. > (3) Fix up 10 configuration symbols of the form CONFIG_[0-9]*; specific > changes are those suggested 8 Jan 2001 by PPC port maintainer Tom Rini. > This change has been APPROVED by an authorized maintainer. Maybe I am not caught up with the times... I thought Cort Dougan was the overall PowerPC maintainer. That's what MAINTAINERS says. Anyway, this is up to the PowerPC guys, but I disagree with this change nonetheless. MandrakeSoft has a PPC port, and as I mentioned earlier, some utilities in the build process etc. look at CONFIG_xxx. PPC guys: this is a gratuitous renaming change that is not required. If you have been following the "CML1 cleanup patch" thread, you see that Eric is blindly dictating policy when he says that CONFIG_[0-9] needs to be cleaned up. > This leaves ten symbols in a form that breaks CML2. I'll go after > the other individual maintainers about those. Sigh > > No actual object code will be changed by this patch; it merely does > one-to-one substitutions on some configuration symbols. > > Let me repeat that. This patch changes *no* object code. None. > However, merging it before the 2.5 fork will save me (and probably > Alan) some nasty large headaches later on... Object code changes are not the only thing we are concerned with in a stable series. Let me repeat myself for the cheap seats: Changing the 2.4.x CONFIG_xxx namespace changes the source code API provided to other kernel code. It affects software not in the Linux kernel tree. Your changes (1) and (2) sound ok. Your change (3) is gratuitous, based on policy change discussed with no one, and does not belong in stable series 2.4.x. Linus, Alan, Cort, please consider rejecting Eric's patch while it contains (3). Thanks, Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: via-rhine driver: wicked 2005 problem
wing tung Leung wrote: > It doesn't solve the (less urgent) problem of not being able the use the > NIC after a warm boot in M$ Windows. As I said, pulling the power cord from > the ATX power supply and reinserting it, makes it go away. Would it be possible for you to re-run your tests against kernel 2.4.3-pre8? (ftp://ftp.us.kernel.org/pub/linux/kernel/testing/) This is the "official" latest version of the via-rhine driver, and it includes Manfred's patch, as well as a pci_enable_device movement might solve your problem. If the problem is still not solved, could you download via-diag.c and libmii.c from ftp://www.scyld.com/pub/diag/ Compile instructions are at the bottom of via-diag.c. I'm interested in seeing two via-diag register snapshots, one from a cold boot (where it is working), and one from a warm boot. ./via-diag -maaavvveef > via-diag-cold.txt and ./via-diag -maaavvveef > via-diag-warm.txt then diff -u v*cold.txt v*warm.txt | send mail... And to see if the PCI configuration registers change between warm boot and cold boot, run lspci from pciutils: lspci -vvvxxx > lspci-cold.txt and lspci -vvvxxx > lspci-warm.txt then diff -u l*cold.txt l*warm.txt | send mail... -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] static zero initializers removal
I'll take a look at merging the drivers/net part of this patch, except for where it touches drivers/net/wan. Andrey -- for maintainers at least, it might be nice to split these up via subsystem -- one patch for drivers/isdn, one patch for drivers/char, etc. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML1 cleanup patch, take 2
Tom Rini wrote: > On Mon, Mar 26, 2001 at 09:50:53AM -0500, Jeff Garzik wrote: > > PPC guys: this is a gratuitous renaming change that is not required. > > If you have been following the "CML1 cleanup patch" thread, you see that > > Eric is blindly dictating policy when he says that CONFIG_[0-9] needs to > > be cleaned up. > The counter point to this is what does "CONFIG_6xx" or 8xx mean? It's as bad > as CONFIG_Mxxx imho :) No argument.. :) I definitely encourage namespace cleanup in 2.5 -- but please don't change an identifier just because it begins with a numeric prefix... Change it because it needs to be changed. Best regards, Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML1 cleanup patch, take 3
Wow, your script was longer than your patch :) Patch looks ok to me... -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] Questions about *_do_scsi & create_proc_entry
> Another question is that by inspecting the NULL checker's result, I > found that *_do_scsi is always used in the following way "SRpnt = > *_do_scsi(SRPnt, ...)" no matther SRPnt is NULL or not. If SRpnt is not > NULL, why don't just use > *_do_scsi(SRPnt, ...); > The same thing happens to init_etherdev. WRT init_etherdev, that's the intended effect, because it's 'dev' arg might indeed by NULL. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Compile-time versus run-time
Keith Owens wrote: > Andrew Morton wrote: > > CONFIG_8139TOO_TUNE_TWISTER > > (And wouldn't it be nice to be able to get the same functionality > > which module options give us when using a statically linked driver?) > > On my todo list for 2.5. MODULE_PARM will be promoted to > module_name.parm when the object is built in. insmod foo debug=1 or > boot with foo.debug=1. It needs a mapping of source to module which is > not easy to get for multi object modules in 2.4, my 2.5 makefile > rewrite will make it easy. (redirect to lkml) Making MODULE_PARM work when compiled in will be nice, but I see two flaws right off: * passing multiple module parms is wasteful, because the module prefix must be repeated for each argument. That strains cmdline limits (80 chars in boot environments) IMHO we can do better than that. * There are cases where you do not want MODULE_PARM options appearing as __setup, just like there are cases where options passed to __setup do not belong as a MODULE_PARM. You should not unconditionally make MODULE_PARM available on the kernel command line, even though that is the simple solution. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Config bug? In 2.2.19 CONFIG_RTL8139 depends on CONFIG_EXPERIMENTAL
Greg Ingram wrote: > > In 2.2.19 CONFIG_RTL8139 depends on CONFIG_EXPERIMENTAL. The RTL8139 > driver is not labelled as experimental. Is this an error? Yeah, add '(EXPERIMENTAL)' to the text. Send a patch to Alan if you want... -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD PCnet32 driver does not compile on 2.4.x
Santiago Romero wrote: > Sorry for the "private" message... I'm testing some machines > (real and virtual) under 2.4.3pre8, that have a AMD PCNET32 > ethernet driver. This cards works PERFECTLY under 2.2.x, but if > I compile 2.4.x, I get a error on pcnet32.c about a function > not defined: is_valid_etherdevice(). hmmm. I just tested a vanilla 2.4.3-pre8, with the drivers/net/Makefile fix, and I don't see this at all. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: natsemi.c (Netgear FA311 card) probmlems??
Torrey Hoffman wrote: > > Troy Benjegerdes wrote: > [...] > > Is anyone succesfully using a FA311 card (or anthing with a NatSemi > > DP83815 chip?) > > We are working on the 2.2.x version of the driver. On our hardware, > which has the DP83815 on the motherboard, Donald Becker's version was > capable of sending packets but not receiving. I swapped some email > with him on the subject about 6 weeks ago, sent him some debug output, > but haven't heard anything recently. > > Meanwhile, we are doing some work on it ourselves. A "Jocelyn Mayer" > posted a revised version of the driver which fixed some bugs but > introduced others - at least on our hardware. Check the archives. > > Our version now sends and receives under 2.2.17, and is fixed to read > and set the MAC address properly (!), but tends to have lousy > performance. Large file transfers usually run at a pathetic 250 > KB/s and often stall, but sometimes when the moon is in the right > phase, run at a much more reasonable 7 MB/s. We are working on it... > > If anyone else out there has some improvements, I would love to hear > about them. There are some improvements in the latest 2.4 test patch, 2.4.3-pre8. I would be very interested in hearing feedback on that. I finally got two test cards, FA311 and FA312, so I can work on it a bit too. The 2.4.3-pre8 patch, against kernel 2.4.2, is available from ftp://ftp.us.kernel.org/pub/linux/kernel/testing/ This updated 2.4 natsemi.c merges the changes in Becker's latest, which should fix eeprom/mac address reading as you mention, and it also includes some power management fixes required on some boards. Differences from 2.2 versions include locking updates and some other small differences. Please test, if you have an opportunity. (note you'll have to fix a screwup of mine in drivers/net/Makefile -- you need to add net_init.o to export-objs before you can build net drivers as modules. Building them into the kernel works fine.) -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3-pre8 xircom_tulip_cb missing symbols
Pau Aliagas wrote: > > On Wed, 28 Mar 2001, David Brownell wrote: > > > Same problem shows up with most of the USB network > > drivers too. /proc/ksyms has the macro-wrapped version > > of those names, not the mangled one. > > > > Haven't established whether there's a problem when these > > drivers are statically linked. > > I've been sent this patch by Eran Mann that adds net_init.o to the > exported objects in the net Makefile. that's the right patch. It's been posted independently three or four times now ;-) Jeff, wearing a brown paper bag -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New gigabit cards
Dennis wrote: > >Some of the products seem so new that their manufactuors have little to no > >information available about them on their webpage. One that I found, had > >conflicting specs and claimed to only have a 32kbyte recieve buffer. > > whatever you do dont buy a gigabit card with a small buffer and 32bits. > 32bits isnt enough to do gigabit, even with a large buffer. Never underestimate what will come out of Taiwan in massive quantities :) -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New gigabit cards
Scott Laird wrote: > According to the drivers, the 1000TPC uses the NS DP83820. According to > the DP83820's datasheet, it has a 8k Tx buffer and a 32k Rx buffer. > That's a bit shy of the 512k-1M that older cards use :-(. At wire speed, > that means that you'll have to service the NIC's interrupt within ~60 us > on transmit and ~250 us on receive. That seems rather optimistic. Are you assuming one interrupt per packet? GigE drivers employ interrupt mitigation, large rings, and sometimes resort to polling instead of servicing interrupts, and other techniques. Tiny buffers are ugly, but you can deal with them... -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: configuring net interfaces
Ivan Passos wrote: > Maybe it's a better idea to have just two ioctl's here (GET and SET), and > have "subioctl's" inside the structure passed to the HDLC layer (and > defined by the HDLC layer). This would allow changes in the HDLC layer > without having to change sockios.h (you'd still have to change HDLC's > code and definitions, but this would be more self-contained). Again, this > may be better, or maybe not. What do you think? That's essentially what's happening with ethtool (include/linux/ethtool.h in 2.4.3-pre8) -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: configuring net interfaces
On 29 Mar 2001, Krzysztof Halasa wrote: > Jeff Garzik <[EMAIL PROTECTED]> writes: > > > > Maybe it's a better idea to have just two ioctl's here (GET and SET), and > > > have "subioctl's" inside the structure passed to the HDLC layer (and > > > defined by the HDLC layer). This would allow changes in the HDLC layer > > > without having to change sockios.h (you'd still have to change HDLC's > > > code and definitions, but this would be more self-contained). Again, this > > > may be better, or maybe not. What do you think? > > > > That's essentially what's happening with ethtool > > (include/linux/ethtool.h in 2.4.3-pre8) > > Right. While I don't think ethernet-only interface is our ultimate goal, > I'll look at it again to see if I can stole some idea there. I'm not suggesting you modify ethtool for your needs :) But ethtool perfectly illustrates the technique of using a single socket ioctl (SIOCETHTOOL) to extend a set of standard, domain-specific ioctls (ETHTOOL_xxx) to Linux networking drivers. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcnet32 compilation fix for 2.4.3pre6
On Thu, 29 Mar 2001, Tom Leete wrote: > Ulrich Drepper wrote: > > > > [EMAIL PROTECTED] writes: > > > > > with the new ansi standard, this use of __inline__ is no longer > > > necessary, > > > > This is not correct. Since the semantics of inline in C99 and gcc > > differ all code which depends on the gcc semantics should continue to > > use __inline__ since this keyword will hopefully forever signal the > > gcc semantics. > Unfortunately, it seems that gcc will define __inline__ as a synonym for > inline, whatever inline is currently in use. I asked this on the gcc list a > while ago. The archive there should have the replies. None of this matters :) The kernel standard is 'static inline', so that is the preferred usage in standard kernel code, without overriding reasons. (also note that it is an outstanding cleanup item to replace 'extern [__]inline[__]' with 'static inline', unless there are overriding reasons not to do so.) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory leak in the ramfs file system
On Thu, 29 Mar 2001, Amit D Chaudhary wrote: > >(none):/mnt/ramfs/root# df -h /mnt/ramfs/ > >FilesystemSize Used Avail Use% Mounted on > >ramfs0 0 0 - /mnt/ramfs > I am not sure, how related this is, but we have / on ramfs and using rpm > to install(-iUvh) fails with the mesages, need 12K on / This is normal -- ramfs doesn't do filesystem accounting needed for 'df'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Memory leak in the ramfs file system
On Mon, 12 Jun 2000, Jaswinder Singh wrote: > > What does /proc/slabinfo say? The most likely leak is a dentry leak or > > an inode leak, and both of those should be fairly easy to see in the > > slab info (dentry_cache and inode_cache respectively). > > > > I am attaching details before and during my application . > > Mainly changes are in dentry_cache and inode_cache , but i am attaching > whole /proc/slabinfo for your reference. Would it be possible for you to attached a 'before' picture of slabinfo, as well as 'after'? > > Obviously, it could be a data page leak too, but such a leak should be > > easy to see by creating a few big files and deleting them.. > > > > Linus > > I am also facing one more problem with ramfs. > > du and df shows 0 , so i am also attaching its output. I don't recall how du works exactly... if it uses stat(2), it should not be broken AFAIK. As for 'df', that will definitely show zero, because ramfs does not do filesystem accounting in its present form. You might consider trying a modified version of ramfs, as found in Alan Cox's 'ac' patchkit. This patchkit includes a modified ramfs which supports limiting filesystem size, but more importantly (for you), it should make 'df' work again. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3 aic7xxx wont compile
On Thu, 29 Mar 2001, George Bonser wrote: > Just tried to build 2.4.3, got: > > make[6]: Entering directory > `/usr/local/src/linux/drivers/scsi/aic7xxx/aicasm' > gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c > aicasm_symbol.c -o aicasm > aicasm/aicasm_gram.y:45: ../queue.h: No such file or directory > aicasm/aicasm_gram.y:50: aicasm.h: No such file or directory > aicasm/aicasm_gram.y:51: aicasm_symbol.h: No such file or directory > aicasm/aicasm_gram.y:52: aicasm_insformat.h: No such file or directory > aicasm/aicasm_scan.l:44: ../queue.h: No such file or directory > aicasm/aicasm_scan.l:49: aicasm.h: No such file or directory > aicasm/aicasm_scan.l:50: aicasm_symbol.h: No such file or directory > aicasm/aicasm_scan.l:51: y.tab.h: No such file or directory Looks like the gcc command line needs '-I.' there... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: memcpy in 2.2.19
On Fri, 30 Mar 2001, Chris Funderburg wrote: > What's wrong with this picture: > ld -m elf_i386 -T /usr/src/kernel/stable/linux/arch/i386/vmlinux.lds -e [...] > -o vmlinux > drivers/scsi/scsi.a(aic7xxx.o): In function `aic7xxx_load_seeprom': > aic7xxx.o(.text+0x116bf): undefined reference to `memcpy' > make: *** [vmlinux] Error 1 > > Is this something outside the kernel tree that I've lost? Seems a bit weird > since memcpy must be > used in thousands of other place. It's even more strange because memcpy is not called at all from that routine. Generally when this occurs, someone is using a gcc feature to copy a structure, instead of calling memcpy directly. Since the kernel is sometimes compiled with -fno-builtins, and since we also have our own kernel memcpy, using this particular gcc feature often runs into problems. It's not obvious from the code that this is going on, but it's one possible cause. Can you try the new aic7xxx driver? Just search any linux-kernel mail archive for Justin Gibbs, he is always [re-]posting the link to the latest aic7xxx driver. AFAIK it has kernel compatibility and thus supports 2.2.x... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA problems on IBM ThinkPad 600X
On Fri, 30 Mar 2001, Anton Safonov wrote: > Hi! > > I have a problem with PCMCIA support on this IBM ThinkPad 600X. > > kernel - 2.4.2 + patch-2.4.3-pre4 > pcmcia-cs - 3.1.25 (also tried with 3.1.23) > > Then I insert a card (I'm trying now with two cards: 3COM 3CCFE575CT, > D-Link DFE-680TX) the computer beeps and responds with: > "cs: socket X timed out during reset" > > > kernel config file is following: > > # > # PCMCIA/CardBus support > # > CONFIG_PCMCIA=m > CONFIG_CARDBUS=y > CONFIG_I82365=y > CONFIG_TCIC=y If you have CardBus support, do -not- define CONFIG_I82365 or CONFIG_TCIC. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3 aic7xxx wont compile
On Fri, 30 Mar 2001, Justin T. Gibbs wrote: > > Yes, "-I." from gcc flags. > > > > The sad part is that people have been patching right and left to get > > that monster utility to compile because the dependencies say that it > > must be used to remake the AIC sequencer binary image; which image is > > perfectly ok except of its timestampts due to patching process. > > The sad part is that there has been a fix for this "problem", supplied > by the author of the driver, for well over a month that everyone seems > to ignore. You cannot expect that all people will instantly start using the latest driver from your Web site, immediately. Especially considering 1) There is no MAINTAINERS entry listing you or your web site 2) Your e-mail address is nowhere to be found in the code 3) The driver Web site address is nowhere to be found in the code 4) People are used to getting aic7xxx out of the kernel tarball Are people just supposed to pick up your psychic waves? :) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3 still doesn't see my Xircom CardBus modem
On Fri, 30 Mar 2001, Alessandro Suardi wrote: > Just in case people forgot... (serial.c still not detecting my card). > > As always, available for tests/patches/whatever. Thanks & ciao, Haven't forgotten, just need to figure out how generic the fix needs to be ... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3 aic7xxx wont compile
On Fri, 30 Mar 2001, Justin T. Gibbs wrote: > >You cannot expect that all people will instantly start using the > >latest driver from your Web site, immediately. Especially considering > > I guess I expect people posting on LK to read it. There have been > announcements for all the driver versions on that list, I've responded > to all of the threads complaining about the aicasm stuff, and No less than three patches were posted to linux-kernel fixing my drivers/net/Makefile screwup... after I posted my own patch. I never assume people read lkml at all before posting a problem report. Oh well, at least they are posting problem reports at all! :) > I've provided updated patches to Linus. I dunno about the patches for Linus. Have you read Documentation/SubmittingPatches? #3, #6, and especially #9 probably apply here, I'm guessing. > I'll try the psychic waves thing. Perhaps it will help. hee :) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.4.3 fails to compile
On Fri, 30 Mar 2001, Manuel A. McLure wrote:
> ...
> gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
> -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
> -march=athlon -DMODULE -DMODVERSIONS -include
> /usr/src/linux/include/linux/modversions.h -c -o buz.o buz.c
> buz.c: In function `v4l_fbuffer_alloc':
> buz.c:188: `KMALLOC_MAXSIZE' undeclared (first use in this function)
> buz.c:188: (Each undeclared identifier is reported only once
> buz.c:188: for each function it appears in.)
Easy solution -- just delete the entire test
if (size > KMALLOC_MAXSIZE) {
...
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Kernel 2.4.3 fails to compile
On Fri, 30 Mar 2001, Manuel A. McLure wrote:
> Jeff Garzik wrote:
> > On Fri, 30 Mar 2001, Manuel A. McLure wrote:
> >
> > > ...
> > > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall
> > -Wstrict-prototypes -O2
> > > -fomit-frame-pointer -fno-strict-aliasing -pipe
> > -mpreferred-stack-boundary=2
> > > -march=athlon -DMODULE -DMODVERSIONS -include
> > > /usr/src/linux/include/linux/modversions.h -c -o buz.o buz.c
> > > buz.c: In function `v4l_fbuffer_alloc':
> > > buz.c:188: `KMALLOC_MAXSIZE' undeclared (first use in this function)
> > > buz.c:188: (Each undeclared identifier is reported only once
> > > buz.c:188: for each function it appears in.)
> >
> > Easy solution -- just delete the entire test
> >
> > if (size > KMALLOC_MAXSIZE) {
> > ...
> > }
>
> Thanks, I'll do that. It just seemed strange that the file was being
> compiled in the first place when the config option was not set.
buz is built with CONFIG...ZORAN as well as CONFIG...BUZ. I dunno if
that's a bug or not...
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Summit info?
On Fri, 30 Mar 2001, Torrey Hoffman wrote: > However... for those of us who are curious, is there a web site somewhere > with information about the goings-on? What would be really nice is web cams, > or a RealAudio feed from the meetings. I don't have specific info, but the meetings are being webcast.. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
tulip (was RE: Kernel 2.4.3 fails to compile)
On Fri, 30 Mar 2001, Manuel A. McLure wrote: > It looks like the tulip driver isn't as up-to-date as the one from > 2.4.2-ac20 - when is 2.4.3-ac1 due? :-) I got NETDEV WATCHDOG errors shortly > after rebooting with 2.4.3, although these were of the "slow/packet lossy" > type I got with 2.4.2-ac20 instead of the "network completely unusable" type > I got with 2.4.2-ac11 and earlier. I'm betting that the latest ac (ac28?) is broken for you, too. I had to revert the changes in 'ac' tulip -- they fixed Comet and 21041 cards, but broke some others. sigh. sigh. More testing and debugging for Jeffro... Comet (your chip, I am guessing?) should be fixed ASAP, it's pretty easy. 21041 is not as easy, but should be fixed quickly as well. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcnet32 (maybe more) hosed in 2.4.3
On Fri, 30 Mar 2001, Scott G. Miller wrote: > Linux 2.4.3, Debian Woody. 2.4.2 works without problems. However, in > 2.4.3, pcnet32 loads, gives an error message: hrm, can you try 2.4.2-acXX as well? I pretty much just merged pcnet32 patches from there. I should be getting a pcnet32 test card on Tuesday, maybe I can knock out the bug and avoid having to revert the merge. Regards, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA problems on IBM ThinkPad 600X
On Sun, 1 Apr 2001, Constantine Gavrilov wrote: > There are problems with some PCMCIA drivers included in the kernel. For > example, support for cardbus 3com cards was moved to 3c59x.o driver. It > works (on 600X at least) only of you compile it in. It will not work as > a module. It works just fine as a module. What problems are you seeing? > I think a much better solution right now is to use drivers from > pcmcia-cs package. It always works. If you do not configure any support > for pcmcia in your kernel, when you build pcmcia-cs it will build kernel > drivers from its own source tree. Just make sure you use the latest > version. This also allows configuration files interoperbility with 2.2.x > kernel, if you wish to use that as well. pcmcia-cs does not always work, and it puts your nice 32-bit hardware into 16-bit compatibility mode AFAIK. If you have 2.4 bugs, please report them instead of spewing B.S. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Manfred Spraul wrote: > > There was a lot of discussion about possible tools > > that would dig out the /proc/pci info > > I think the tools should not dig too much information out of the system. > I remember some Microsoft (win98 beta?) bugtracking software that > insisted on sending a several hundert kB long compressed blob with every > bug report. > IMHO it must be possible to file bugreports without the complete hw info > if I know that the bug isn't hw related. Two comments -- * It's only disk space. It's better to have and not need, than need and not have. Please do give me 200kb bug reports! :) * There should be a way to allow the user to omit hw info, because the user may not want to disclose some parts of their system. Regards, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Albert D. Cahalan wrote: > Manfred Spraul writes: > > [Larry McVoy] > > >> There was a lot of discussion about possible tools > >> that would dig out the /proc/pci info > > I think the tools should not dig too much information out of the system. > > I remember some Microsoft (win98 beta?) bugtracking software that > > insisted on sending a several hundert kB long compressed blob with every > > bug report. > > IMHO it must be possible to file bugreports without the complete hw info > > if I know that the bug isn't hw related. > > Yep. The two hardware-related items that usually matter: > > Little-endian or broken-endian? > 32-bit or 64-bit? Matters to whom? You, or the people actually fixing bugs? "Broken-endian"? whatever. /proc/pci data alone with every bug report is usually invaluable. It gives you a really good idea of the general layout of the system, and you can often catch or become aware of related hardware characteristics which linux/REPORTINGS-BUGS was created to give users a hint that we need -more- information, and tells exactly what general information is useful to provide. We do not need less information. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: configuring net interfaces
On 1 Apr 2001, Krzysztof Halasa wrote: > Jeff Garzik <[EMAIL PROTECTED]> writes: > > I'm not suggesting you modify ethtool for your needs :) But ethtool > > perfectly illustrates the technique of using a single socket ioctl > > (SIOCETHTOOL) to extend a set of standard, domain-specific ioctls > > (ETHTOOL_xxx) to Linux networking drivers. > > I know. The problem is I don't see here any advantages over many SIOCxxx > command codes, while there are disadvantages. > Simple things are IMHO better, and ioctl was designed to handle many > simple commands (instead of one complex). > > Am I missing something? IMHO we should get away from adding hardware-type-specific ioctls from the generic SIOCxxx list. Sure it is easy to dump a bunch of new ioctls into sockios.h. But having "one big header that covers all hardware types and ioctl situations" does not seem like the right solution to me. First of all, you as the HDLC subsystem maintainer have a lot more control over what goes into include/linux/hdlc.h than include/linux/sockios.h. New SIOC ioctls should not be added on a whim, but after examination of the issues involved. Making a mistake and adding a bad/pointless SIOC ioctl means you are stuck with it for a long time. The same applies to ioctls in hdlc.h of course -- but the key distinction is that you are 100% sure of the issues involved because changes are localized to your own domain. Further, each change to sockios.h affects a LOT of code, both in and outside the kernel. Localizing your changes also localizes the effects of bad namespace and ioctl choices (and bugs, though in this case that would be rare). Finally, I have this (perhaps crazy) idea that we should move in the direction of removing ALL hardware-related ioctls from sockios.h, making SIOC the domain of generic network device ioctls. Comments welcome. IMHO domain-specific ioctls are a better direction than the current make-sockios.h-huge-with-new-ioctls approach. Regards, Jeff P.S. It would be awesome if you would consider CC'ing [EMAIL PROTECTED] Some developers who might have valuable input do not subscribe to linux-kernel, or are not able to read all of the net-related linux-kernel messages. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Manfred Spraul wrote: > From: "Jeff Garzik" <[EMAIL PROTECTED]> > > > > /proc/pci data alone with every bug report is usually invaluable. > > Even if the bug is a compile error? In fact, yes. Having the tuple of: .config, /proc/pci, and compile error output, you can see additionally if the user is doing something wrong. It allows you to fix the user as well as the compile error ;-) > E.g. > BUG REPORT (a real one, I didn't have the time yet to post a patch): > kernel versions: tested with 2.4.2-ac24, afaics 2.4.3 is also affected > Description: > Several config options are missing in the 'if' at the end of > linux/drivers/net/pcmcia/Config.in. > This means that CONFIG_PCMCIA_NETCARD is not set, and then (iirc) the > kernel won't link. > > CONFIG_ARCNET_COM20020_CS > CONFIG_PCMCIA_HERMES > CONFIG_AIRONET4500_CS > CONFIG_PCMCIA_IBMTR > are missing. noted. > Obviously too much data doesn't hurt, as long as > * it's hidden somewhere deep in a database, clearly separated from the > important parts (if there is an oops: decoded oops, description, how > easy is it to trigger the bug, steps to reproduce) > * very easy for the bug reporter to collect. > * not mandatory. agreed. Regards, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, David Lang wrote: > /proc/config may be bloat, but we do need a way for the kernel config to > be tied to the kernel image that is running, however it is made available. /sbin/installkernel copies stuff into /boot, appending a version number. One way might be to have this script also copy the kernel config. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, David Lang wrote: > if we want to get the .config as part of the report then we need to make > it part of the kernel in some standard way (the old /proc/config flamewar) > it's difficult enough sometimes for the sysadmin of a box to know what > kernel is running on it, let alone a bug reporting script. Let's hope it's not a flamewar, but here goes :) We -need- .config, but /proc/config seems like pure bloat. If a sysadmin (note I don't say "user") has no clue what his kernel config is, or has no clue what kernel is running on his box, then they should be fired before the day is out. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Larry McVoy wrote: > Problem details > Bug report quality [...] > But the main thing was to extract all the info we could > automatically. One thing was the machine config (hardware and > at least kernel version). The other thing was extract any oops > messages and get a stack traceback. Basically look through REPORTING-BUGS for a laundry list of helpful info. > The other main thing was to define some sort of structure to the > bug report and try and get the use to categorize if they could. > In an ideal world, we would use the maintainers file and the > stack traceback to cc the bug to the maintainer. I think we want > to explore this a bit. I'm not sure that the maintainer file is > the way to go, what if we divided it up into much broader chunks > like "fs", "vm", "network drivers", and had a mail forwarder > for each area. That could fan out to the maintainers. (slight tangent) One thing people have talked about in the past is updating MAINTAINERS to actually reflect real life... some of the active maintainers don't have maintainer entries. That may be intentional, maybe not... For drivers at least, bugs -should- be mailed to the driver maintainer where possible, which is not always the same as the subsystem maintainer. > Signal/noise [...] > Jens wants there to be a queue of Jes? > new bugs and a mechanism where people can come in the morning, pull > a pile of bugs off of the queue, sort them, sending some to the real > database. This idea has a lot of merit, it needs some pondering as > DaveM would say, to get to the point that we have a workable mechanism > which works in a distributed fashion. Back when I was hacking GNOME, various janitors (to use the now-popular term) would go through and clean the bug database, sorting through a lot of the noise. Newbies are finding the Kernel Janitors project as an excellent way to begin to contribute to the kernel. There are definitely interested, smart people willing to help, that at present don't know a lot about the kernel. Such volunteers, like the GNOMEs mentioned above, could be a vast benefit to this particular step of the bug tracking process. You http://sourceforge.net/projects/kernel-janitor/ > Past experiences > This is a catch all for sound bytes that we don't want to forget... > > - one key observation: let bugs "expire" much like news expires. If > nobody has been whining enough that it gets into the high signal > bug db then it probably isn't real. We really want a way where no > activity means let it expire. Agreed, with a caveat: some bugs should stay around but not expire. There is a class of bugs that shouldn't go away from the "less noise" bug database when there is no activity. ie. hard problems we want to remember, but solve in a later version. > Requirements 1) An e-mail interface. For sorting through massive amounts of bugs, NNTP is far more useful. Maybe as a query interface as well, NNTP is useful. But for getting into the nitty-gritty details of handling a bug, e-mail is generally the primary medium of communication between developer and user. debian-bugs assigns each bug a unique e-mail address, and all e-mail that arrives in that mailbox is appended to the bug's comments. 2) Support for binary attachments from users - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, David Lang wrote: > On Sun, 1 Apr 2001, Jeff Garzik wrote: > > /sbin/installkernel copies stuff into /boot, appending a version number. > > One way might be to have this script also copy the kernel config. > could be, /sbin/installkernel doesn't exist on my systems arch/i386/boot/install.sh has been calling /sbin/installkernel, if it exists, for a good while now. It sounds like your kernel or initscripts package is incomplete. You can grab installkernel off a Mandrake- or RedHat-based system. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
"J . A . Magallon" wrote:
> Could make part of the kernel scripts, or in one other
> standard software package, like modutils, so its versions are controlled
There is value in putting it into the Linux kernel source tree, in
linux/scripts dir. But most vendors can and should take this script as
a sample, and customize it for their distro. The Linux-Mandrake
installkernel script definitely gets touched every so often, and
decisions it makes, like updating lilo.conf or grub/menu.lst, or
autodetecting the boot loader, are definitely not to be applied for all
cases.
FWIW here is our /sbin/installkernel command line usage help text, to
give a glimpse of what it does and can do:
Usage: ${0##*/} -[lngarhcq] KERNEL_VERSION BOOTIMAGE MAPFILE
-l: Add a lilo entry
-i: Dont generate Initrd files
-n: Don't launch lilo.
-g: Add a Grub entry.
-d: Don't autodetect boot loader.
-a: Autodetect boot loader.
-r: Features for RPM post install.
-c: Don't copy files.
-q: Be quiet.
-h: This help.
> I think the best solution would be to make /boot the 'official' place for
> kernels, the -X.Y.Z naming an standard, installkernel should save System.map
> and .config.
There will never be an official place to put this stuff, because that's
a distro policy decision. A quick search just now reveals no reference
to /boot in the i386 Makefiles, and only a quick reference in the README
file.
> And you can add something like /proc/signature/map, /proc/signature/config,
> etc to md5-check if a certain file fits running kernel.
Additionally, everyone should remember: /proc is not a dumping ground :)
Ad-hoc naming like this has created the procfs namespace ugliness we
have now... let's not add to it unless we have to, and unless we have a
good idea of proper naming.
--
Jeff Garzik | May you have warm words on a cold evening,
Building 1024 | a full moon on a dark night,
MandrakeSoft | and a smooth road all the way to your door.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
Oliver Xymoron wrote: > On Mon, 2 Apr 2001, Tom Leete wrote: > > How about /lib/modules/$(uname -r)/build/.config ? It's already there. > It'd be great if we got away from the config being hidden too. When exporting it outside the kernel tree, the '.' prefix should definitely be stripped... My preference is /boot/config-2.4.3 (with /boot/config as a symlink to it) Assuming your initscripts is smart about updating /boot symlinks, any running kernel config [properly installed] can be grabbed with a simple 'cp /boot/config .' -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full moon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
