Re: [patch] 2.4.2-pre3: parport_pc init_module bug
On Wed, 14 Feb 2001, Grant Grundler wrote: Philipp Rumpf wrote: Jeff Garzik wrote: Looks ok, but I wonder if we should include this list in the docs. These is stuff defined by the PCI spec, and this list could potentially get longer... (opinions either way wanted...) Having people look things up in the spec isn't very user friendly. Finding a copy of the PCI 2.1 or 2.2 spec I could pass on to others (outside of HP) was a problem last year. The best I could do then (legally) was point them to "PCI Systems Architecture" published by MindShare. _PCI Systems Architecture_ is an awesome book, definitely. AFAIK there are two avenues to go, when getting the PCI specs. Become a PCI SIG member (much $$$), or buy a CD-ROM. For US$50, a non-member can purchase a CD-ROM from the PCI SIG which includes the latest versions of all the PCI specifications, in PDF format, as well as a hardcopy of the PCI 2.2 spec itself. Great deal, I recommend it for anybody intersted in hacking PCI. 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: Beware - kernel Newbie!
On Sun, 18 Feb 2001, Pedro Diaz Jimenez wrote: This is an typical mail from an experienced user-land programmer who wants to help in kernel development ;D. I've been lurking for a while in this list and I'm wondering if this is the right list for asking stupid newbie questions. Is it?. If not, do you know one?. Where I can find documentation? We are always welcome to answer newbie -kernel hacking- questions... just ask specific ones. For example, ask "how does struct netdevice's last_rx member get used?", not "what do I need to do to write a network driver?" The documentation is in linux/Documentation/* (yeah, yeah, read the code. But things are always better with an 'vi Doc.txt' in the processes tree :) Really. The code is the best documentation. Hone your code reading skills. Use the source, Luke. 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: anyone can tell me 2.4.2 is stable or not?
On Mon, 19 Feb 2001, Thomas Lau wrote: is it stable for use? Is the world a wonderful, beautiful place? Both are subjective questions. 2.4 has been stable for me for quite a long time, as it has been for many others. It totally depends on your hardware, and what you are doing. I would say for the most part, yes. 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: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Werner Almesberger wrote: Now what's at stake ? Look at the Windows world. Also there, companies could release their drivers as Open Source. Quick, how many do this ? Almost none. So, given the choice, most companies have defaulted to closed source. Consistently complaining when a company tries to release only closed source drivers for Linux seems to generally have the desired effect of making them change their policy. FWIW, -every single- Windows driver source code I've seen has been bloody awful. Asking them to release that code would probably result in embarrassment. Same reasoning why many companies won't release hardware specifications... The internal docs are bad. Really bad. 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: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Nicholas Knight wrote: From: "Jeff Garzik" [EMAIL PROTECTED] FWIW, -every single- Windows driver source code I've seen has been bloody awful. Asking them to release that code would probably result in embarrassment. Same reasoning why many companies won't release hardware specifications... The internal docs are bad. Really bad. While I understand that internal docs and source are often simply a mess, I fail to see why this should prevent a company from releasing specs or source. Sure somebody will come along and say "What on earth were you people THINKING?!", and then they'll get over it and do something useful with the specs and/or source to the drivers (or if they don't, somebody else will) I seriously doubt it'd lead to a company seeing a drop in sales because of it... and even if they did, I'd say it's a calculated risk, as they could well pick up a higher number of new customers than the number of old customers they lost due to wider ranging support. And even if their specs and code were the worst peices of trash on the planet, I'd still thank them for opening them up to the public. You might thank them. The other opinion is... people look at the newly-released garbage source code, and say "wow, the driver I'm running is shit. I'm switching to another type of hardware." etc. Maybe harmless, maybe PR disaster. 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: sendfile from char device?
On Mon, 19 Feb 2001, Matthew Kirkwood wrote: I'm looking for a fast way to initialise a file to zeroes (without holes) and reckoned that sendfile from /dev/zero would be the way to go. But, unfortunately, sendfile (in 2.2 and 2.4) appears not to support sendfile(2)ing a device: Correct... sendfile(2) is only for sources/destinations that can be ripped through the page cache. I converted Lineo's BusyBox to use sendfile, only to see it die when used on anything but a normal file or a socket. 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: ethernet driver probs (tulip, de4x5, 3c509)
On 20 Feb 2001, Manfred Bartz wrote: I have 3 NICs (2*DEC, 1*3c509) in my gateway (P75, 40M RAM). tulip.o in 2.4.1 insists on selecting 10baseT, no command line option can convince it otherwise. tulip.o in 2.2.16 auto detected media and worked fine. A little info on your cards would be helpful. With well over 100 different types of Tulip cards, I can't just read your mind :) lspci, tulip-diag, and dmesg output would all be helpful. de4x5.o in 2.4.1 needs to be told the media, then works fine. de4x5.o in 2.2.16 auto detected media and worked fine. de4x5 is going away, anyway. 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: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, David Howells wrote: I suspect part of the problem with commercial driver support on Linux is that the Linux driver API (such as it is) is relatively poorly documented In-kernel documentation, agreed. _Linux Device Drivers_ is a good reference for 2.2 and below. and seems to change almost on a week-by-week basis anyway. I've done my share of chasing the current kernel revision with drivers that aren't part of the kernel tree: by the time you update the driver to work with the current kernel revision, there's a new one out, and the driver doesn't compile with it. This is entirely in your imagination. Driver APIs are stable across the stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18, 2.4.0 through whatever. 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: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Richard B. Johnson wrote: One of the latest module killers was the opaque type, "THIS_MODULE", put at the beginning of struct file_operations. This happened between 2.4.0 and 2.4.x. So it's not "imagination". Richard, Time to join the rest of us on planet Earth. That was added in 2.4.0-test2, and was most definitely in 2.4.0 release. 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: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Mikulas Patocka wrote: I suspect part of the problem with commercial driver support on Linux is that the Linux driver API (such as it is) is relatively poorly documented In-kernel documentation, agreed. _Linux Device Drivers_ is a good reference for 2.2 and below. And do implementators of generic kernel functions and developers of device drivers respect it? And how can they respect it if it's a commercial book? _Linux Device Drivers_ documents the 2.2 (and previous) API, and thus refutes the argument that the kernel API is poorly documented. Since the publication of the book -succeeds- the publication of the APIs, your questions are not applicable. and seems to change almost on a week-by-week basis anyway. I've done my share of chasing the current kernel revision with drivers that aren't part of the kernel tree: by the time you update the driver to work with the current kernel revision, there's a new one out, and the driver doesn't compile with it. This is entirely in your imagination. Driver APIs are stable across the stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18, 2.4.0 through whatever. No true. Do you remember for example the mark_buffer_dirty change in some 2.2.x that triggered ext2 directory corruption? (mark_buffer_dirty was changed so that it could block). Another example of bug that comes from the lack of specification is calling of get_free_pages by non-running processes that caused lockups on all kernels 2.2.15. And it is still not cleaned up - see tcp_recvmsg(). Having documentation could prevent this kind of bugs. Hardly. No documentation is often -better- than bad documentation. You don't need too long texts, just a brief description: "this function may be called from process/bh/interrupt context, it may/may not block, it may/may not be called in TASK_[UN]INTERURPTIBLE state, it may take these locks." With documentation developers would be able to change implementation of kernel functions without the need to recheck all drivers that use them. Anytime you change implementation, you gotta check all drivers that use them. I know, I'm one of the grunts that does such reviews and changes. Saying "code is the specification" is not good. I'm not arguing against documentation. That is dumb. But the code is ALWAYS canonical. Not docs. 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: unresloved symbols in 2.4.1
On Tue, 20 Feb 2001, Bill Nottingham wrote:
Eugene Danilchenko ([EMAIL PROTECTED]) said:
cd /lib/modules/2.4.1; \
mkdir -p pcmcia; \
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.1; fi
depmod: *** Unresolved symbols in /lib/modules/2.4.1/kernel/fs/binfmt_elf.o
depmod: get_pte_slow
depmod: __handle_bad_pmd
System: RedHat 6.2
on system installed:
modutils-2.4.2-1
What does it mean.
It means that compiling ELF binary support as a module doesn't work right.
and what have i to do to avoid it?
Compile it in (CONFIG_BINFMT_ELF=y). If you're using Red Hat Linux 6.2,
compiling it as a module is an incredibly bad idea anyway.
I wonder if we shouldn't disable CONFIG_BINFMT_ELF=m, until we have a
good use case and some good testers.
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: Probs with PCI bus master DMA to user space
On Tue, 20 Feb 2001, Norbert Roos wrote: Allocate the buffers in the kernel and mmap() them into user space But the buffers are usually allocated with malloc() by any application which wants to use my driver.. otherwise my driver would have to offer a malloc-like function, but I can hardly force the application to use my own malloc function. If you are writing the driver, sure you can. 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: Probs with PCI bus master DMA to user space
On Tue, 20 Feb 2001, Norbert Roos wrote:
Jeff Garzik wrote:
But the buffers are usually allocated with malloc() by any application
which wants to use my driver.. otherwise my driver would have to offer a
malloc-like function, but I can hardly force the application to use my
own malloc function.
If you are writing the driver, sure you can.
??
The application is doing something like
fd = open("/dev/mydriver");
buf = malloc();
fill_buffer_with_data(buf);
write(fd,buf);
And now i should tell the programmer not to use malloc() but my special
driver-malloc?
Or do you mean something different?
fd = open(...);
buf = mmap(fd, ...);
fill_buffer_with_data(buf);
ioctl(fd, ...); /* tell kernel data is there */
There are variations depending on the application, but you get the
picture. A buffer copy is eliminated when mmap is used, too, making
your application faster.
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/
PATCH: Via audio rate lock, for testing
Can you guys test this patch, and let me know if it fixes Via audio
problems on your kernel?
It should apply against 2.4.1 or 2.4.1-acXX kernels. Note that it
should be applied with "patch -p0" while in the linux kernel source
directory, not applied with "patch -p1".
Regards,
Jeff
Index: drivers/sound/via82cxxx_audio.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/sound/via82cxxx_audio.c,v
retrieving revision 1.1.1.13.22.1
diff -u -r1.1.1.13.22.1 via82cxxx_audio.c
--- drivers/sound/via82cxxx_audio.c 2001/02/18 23:58:28 1.1.1.13.22.1
+++ drivers/sound/via82cxxx_audio.c 2001/02/21 16:36:23
@@ -281,6 +281,8 @@
int dev_dsp;/* /dev/dsp index from register_sound_dsp() */
+ int locked_rate : 1;
+
struct semaphore syscall_sem;
struct semaphore open_sem;
@@ -503,10 +505,16 @@
static int via_set_rate (struct ac97_codec *ac97,
struct via_channel *chan, unsigned rate)
{
+ struct via_info *card = ac97-private_data;
int rate_reg;
DPRINTK ("ENTER, rate = %d\n", rate);
+ if (card-locked_rate) {
+ chan-rate = 48000;
+ goto out;
+ }
+
if (rate 48000) rate = 48000;
if (rate 4000)rate = 4000;
@@ -530,6 +538,13 @@
*/
chan-rate = via_ac97_read_reg (ac97, rate_reg);
+ if (chan-rate == 0) {
+ card-locked_rate = 1;
+ chan-rate = 48000;
+ printk (KERN_WARNING PFX "Codec rate locked at 48Khz\n");
+ }
+
+out:
DPRINTK ("EXIT, returning rate %d Hz\n", chan-rate);
return chan-rate;
}
@@ -1438,7 +1453,7 @@
* via_ac97_reset - Reset Via AC97 hardware
* @card: Private info for specified board
*
- * Reset Via AC97 hardware.
+ * Reset Via AC97 codec, controller, and hardware.
*/
static int __init via_ac97_reset (struct via_info *card)
@@ -1512,8 +1527,8 @@
*/
/* enable variable rate, variable rate MIC ADC */
- tmp16 = via_ac97_read_reg (card-ac97, 0x2A);
- via_ac97_write_reg (card-ac97, 0x2A, tmp16 | (10));
+ tmp16 = via_ac97_read_reg (card-ac97, AC97_EXTENDED_STATUS);
+ via_ac97_write_reg (card-ac97, AC97_EXTENDED_STATUS, tmp16 | 1);
pci_read_config_byte (pdev, VIA_ACLINK_CTRL, tmp8);
if ((tmp8 (VIA_CR41_AC97_ENABLE | VIA_CR41_AC97_RESET)) == 0) {
@@ -1588,8 +1603,22 @@
}
/* enable variable rate, variable rate MIC ADC */
- tmp16 = via_ac97_read_reg (card-ac97, 0x2A);
- via_ac97_write_reg (card-ac97, 0x2A, tmp16 | (10));
+ tmp16 = via_ac97_read_reg (card-ac97, AC97_EXTENDED_STATUS);
+ via_ac97_write_reg (card-ac97, AC97_EXTENDED_STATUS, tmp16 | 1);
+
+ /*
+* If we cannot enable VRA, we have a locked-rate codec.
+* We try again to enable VRA before assuming so, however.
+*/
+ tmp16 = via_ac97_read_reg (card-ac97, AC97_EXTENDED_STATUS);
+ if ((tmp16 1) == 0) {
+ via_ac97_write_reg (card-ac97, AC97_EXTENDED_STATUS, tmp16 | 1);
+ tmp16 = via_ac97_read_reg (card-ac97, AC97_EXTENDED_STATUS);
+ if ((tmp16 1) == 0) {
+ card-locked_rate = 1;
+ printk (KERN_WARNING PFX "Codec rate locked at 48Khz\n");
+ }
+ }
DPRINTK ("EXIT, returning 0\n");
return 0;
-
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: Detecting SMP
On Wed, 21 Feb 2001, Tigran Aivazian wrote: yes, just run the famous mptable program. If the machine is SMP then it will have a valid Intel MP 1.4 configuration tables so the program will show meaningful output. Does that allow you to detect multiple processors... or just an SMP board? 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: PROBLEM: Network hanging - Tulip driver with Netgear (Lite-On)
On Thu, 22 Feb 2001, Alan Cox wrote: three Netgear NICs and am experiencing considerable trouble with the=20 combination: Kernel 2.4.[01]:ifconfig shows that the card see's traffic on t= he=20 network, but does not transmit anything (no response to ping). Use a current 2.4.*-ac. Jeff and co fixed this we think. Credit almost 100% to Manfred Spraul for isolating the problem, making a patch, and passing it around for testing... I was just the merge monkey in this case :) 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: Linux 2.4.2ac1
On Thu, 22 Feb 2001, Adrian Bunk wrote: Hi Alan, is it possible that you send a list of all the changes in 2.4.2ac1 compared to plain 2.4.2? I doubt Alan has time for requests like this (but more power to him, if he does)... His patch is diff'd against 2.4.2, so just look at the patch. I do this for a quick summary of files changes: bzgrep '^--- linux' alans-patch.bz2 | 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/
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. /unquantified vague ramble -- 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 linux/config.h
+#include linux/module.h
#include linux/kernel.h
#include linux/sched.h
#include linux/types.h
@@ -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 empt
Re: PATCH 2.4.3.6: fix netdevice initialization
I have this bad habit of thinking of things after I click Send. 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 linux/config.h
+#include linux/module.h
#include linux/kernel.h
#include linux/sched.h
#include linux/types.h
@@ -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
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. insert Twilight Zone music 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: 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//plug 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 installkernel 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/
Re: [PATCH] multiline string cleanup
Andi Kleen wrote: "J . A . Magallon" [EMAIL PROTECTED] writes: This is one other try to make kernel sources gcc-3.0 friendly. This cleans some muti-line asm strings in checksum.h and floppy.h (this were the only ones reported in my kernel build, perhaps there are more in drivers I do not use). I surely hope the gcc guys will just remove that silly warning again, because it makes it impossible to write readable inline assembly now. If it's a silly warning, then we should turn it off in linux/Makefile. I dunno that the kernel can dictate to gcc here what to do... Also some multiline string cleanups have already made it into the kernel -- though that is not conclusive, as it may just be maintainer preference. 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: /proc/config idea
Jeremy Jackson wrote: Yes, I like this. I do this manually, it allows reproducability, and incremental modifications, tracing how that kernel on that problem system was made... I think the ultimate would be to put all of .config (gzipped?) in a new ELF section without the Loadable attribute... I wish System.map was the same. The you're guaranteed you know how a kernel on disk was configured. To correlate a running kernel to one on disk (vmlinuz) you have LILO... it appends an environment variable to the kernel command line with the name of the file it booted. This is not infallable, since LILO maps disk sectors, only using the filesystem at map install time. Permaps an md5sum of the .text ELF section would conclusively link the in-core kernel with an on-disk vmlinuz? Shouldn't be hard to do with objcopy and /proc/kmem? [...] Comments anyone? Instead of doing all this stuff in the kernel, you could simply update symlinks to properly installed files at boot time. Putting _files_ in the kernel is plain silly. This is unreclaimable memory, folks. There is no need to special case an operation as simple as reading a file. [I think this about firmware images too, but that's another thread] -- 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: can not compile 2.4.3 on alpha
Gustavo Niemeyer wrote: Hello Andrejs!! /usr/src/linux-2.4.3/include/asm/pgalloc.h:334: conflicting types for `pte_alloc' This is happening on ia64 as well. The interface seems to have changed but some architectures were forgotten. The interface changed and other architectures have not caught up yet :) Other archs pretty much always play catch-up to the x86 port. -- 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: scsi bus numbering
"Justin T. Gibbs" wrote: It is bogus that this stuff depends on link order to function correctly. No, it is simply one more rule, and one that is not immediately obvious. Take heart though. Like Rolaids, 2.5's updated makefile system will bring relief... Make sure to add a comment, when you update the 2.4 makefile where link order is significant. (as it is not, in all cases) -- 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: /proc/config idea
Jeremy Jackson wrote: If you have a lot of kernels around, which Config-2.4.3 applies to kernel 2.4.3 given 5 to choose from...the idea (same for System.map) is that it being in the same file they can't be confused. Kinda like forks under Mac (but let's not go there now) The same applies to kernel modules too. Are you going to put all those in the kernel image too? If it's a file, read it from a filesystem after the kernel has booted. There is no need to special case this stuff. -- 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: tulip (was RE: Kernel 2.4.3 fails to compile)
"Manuel A. McLure" wrote: Jeff Garzik wrote: 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. Yes, mine is a Comet - here's the exact detection message: Mar 30 13:09:06 ulthar kernel: Linux Tulip driver version 0.9.14 (February 20, 2 001) Mar 30 13:09:06 ulthar kernel: PCI: Found IRQ 5 for device 00:0c.0 Mar 30 13:09:06 ulthar kernel: eth0: ADMtek Comet rev 17 at 0xb000, 00:20:78:0D: D2:E1, IRQ 5. Ok, this should be fixed in the latest patches sent to Alan and Linus. -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: Groups maximum
Stephen Burns wrote: Hey all, I have checked out the archives, and I found an old post regarding this. The solution in the post, however, did not work for me. I am attempting to raise the maximum 32 group per user limit on my 2.4.2 kernel. I patched both linux/include/linux/limits.h and the asm-i386/param.h, replacing the default "32" with "256." My glibc is 2.1.2. When I make clean, and recompile the kernel, it boots fine but I am still limited to 32 groups. I don't need to do anything with glibc since it is of the 2.1 or greater category, correct? Any ideas, hints, tricks? Thanks a ton for your help, please CC me as I've not been approved yet as a member of this list. You gotta change the task struct... -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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] 15 potential pointer dereference errors in 2.4.3
Andy Chou wrote: [BUG] /u2/acc/oses/linux/2.4.3/drivers/net/tokenring/tmsisa.c:274:tms_isa_probe: ERROR:NULL:273:274: Using unknown ptr "card" illegally! set by 'kmalloc':273 fixed [BUG] /u2/acc/oses/linux/2.4.3/drivers/pcmcia/rsrc_mgr.c:199:do_io_probe: ERROR:NULL:191:199: Using unknown ptr "b" illegally! set by 'kmalloc':191 fixed -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: ethernet phy link state info
Johan Adolfsson wrote: I don't have an answer but a related question: Is there any "standard ioctl" to force an interface to a certain link state, eg. auto, 10Mbs, 100Mbps, half/full duplex etc.? /sbin/mii-tool should do this on most network cards. -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: Multi-function PCI devices
Michael Reinelt wrote: I've got a problem with my communication card: It's a PCI card with a NetMos chip, and it provides two serial and one parallel port. It's not officially supported by the linux kernel, so I wrote my own patch and sent it to the parallel, serial and pci maintainer. The patch itself is basically an extension of the pci id tables; and I hope it's in the queue for the official kernel. Where is this patch available? I haven't heard of an extension to the pci id tables, so I wonder if it's really in the queue for the official kernel. The card shows up on the PCI bus as one device. For the card provides both serial and parallel ports, it will be driven by two subsystems, the serial and the parallel driver. [...] pci_announce_device() will be called only if there's no other driver claiming the device. This explains why either the parallel or the serial port will be detected: The first driver loaded will see the device, the next drivers won't. I'm afraid this is not a bug, but a design issue, and will be hard to solve. Maybe we need a flag for such devices which allows it to be claimed ba more thean one driver? Not so hard. There is no need to register more than one driver per PCI device -- just create a PCI driver whose probe routine registers serial and parallel, and whose remove routine unregisters same. Jeff -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: Multi-function PCI devices
Tim Waugh wrote:
On Sat, Apr 07, 2001 at 01:33:25PM +0200, Michael Reinelt wrote:
Adding PCI entries to both serial.c and parport_pc.c was that easy
And that's how it should be, IMHO. There needs to be provision for
more than one driver to be able to talk to any given PCI device.
No, because that gets really ugly. You have to create a shim driver
which allocates resources, and registers subsystems. Only a single PCI
driver like this know best how to locate and allocate resources. You
can wish to hack such into the serial or parallel driver's PCI probe id
lists, but that won't work for this case, and trying to do it any other
way looks suspiciously like a hack :)
You asked in your last message to show you code, here is a short
example. Note that I would love to rip out the SUPERIO code in parport
and make it a separate driver like this short, contrived example. Much
more modular than the existing solution.
static int __devinit foo_init_one (...)
{
u32 tmp;
int rc;
struct serial_port serial;
struct parport parport;
pci_read_config_byte(pdev, 0x40, tmp);
serial.irq = tmp 0xFF;
pci_read_config_word(pdev, 0x42, tmp);
serial.port = tmp 0x;
rc = register_serial(serial);
if (rc 0)
return rc;
pci_read_config_byte(pdev, 0x40, tmp);
parport.irq = tmp 0xFF;
pci_read_config_word(pdev, 0x42, tmp);
parport.port = tmp 0x;
rc = register_parport(parport);
if (rc 0)
return rc;
return 0;
}
static void __init foo_init(void) {
return pci_module_init(foo_driver);
}
static void __exit foo_exit(void) {
pci_unregister_driver(foo_driver);
}
module_init(foo_init);
module_exit(foo_exit);
--
Jeff Garzik | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft | and shrieking like a cheerleader."
-
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: Multi-function PCI devices
Brian Gerst wrote: Grard Roudier wrote: Given your description, this board is certainly not a multi-fonction PCI device. Multi-function PCI devices provide separate resources for each function in a way that allows each function to be driven by separate software drivers. A single function PCI device that provides several functionnalities commonly handled by separate sub-systems, is nothing but a bag of shit we should not want to support in any O/S in my opinion. Let me claim that ingenieers that want O/Ses to support such hardware are either morons or bastards. Unfortunately, Windoze supports this configuration, and that's enough for most hardware designers. This is also an issue with the joystick ports on many PCI sound cards. We're not in a position to get up on the soap box and decree this hardware "a bag of shit" though, yet. PS. I have run into this issue before with joystick ports on many PCI sound cards. The only one that I found that did it right (seperate PCI function for the game port) was the SBLive. We -can- support multifunction cards such and these, and no we don't need to hack the infrastructure to do it. You might need to hack the subsystem drivers a bit to make them more flexible, but that's it. WRT the specific example of joystick ports, it is already possible for a sound driver to register a joystick port. No problem there either. Jeff -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: Multi-function PCI devices
Michael Reinelt wrote: But what I want to know before I spend time (and not-earning-money :-) into this, I want to know: Is this the right way (TM)? How do other multiport cards deal with this issue? This is a specific question to the serial and parallel maintainers: are there cards supported by _both_ the serial and parallel subsystem? Do they work with 2.4.3? Will they work in the future? (I'm too lazy to compare the PCI tables from serial and parallel ;-) FWIW Tim (in this thread) is the parallel maintainer, tytso is the serial maintainer. WRT serial, there exists serial_cs driver, and the serial_cb driver -used- to exist. The entire purpose of these "shim" drivers was to probe their [pcmcia, CardBus] busses for the necessary information, and then call the existing serial layer to register ports using the probe information already discovered. I think the pcmcia-cs package has a similar plug-n-play shim driver for parallel ports. To answer your question, if there are such multifunctions cards working in 2.4.3, then their drivers are either (a) ignoring one or more functions in favor of a primary function, or (b) lucky enough to have hardware which export multiple PCI bus entries, one for each logical function, making it easy to modify the subsystem driver itself to probe for the hardware. Another (design) question: How will such a driver/module deal with autodetection and/or devfs? I don't like to specify 'alias /dev/tts/4 netmos', because thats pure junk to me. What about pci hotplugging? pci hotplugging happens pretty much transparently. When a new device is plugged in, your pci_driver::probe routine is called. When a new device is removed, your pci_driver::remove routine is called. Jeff -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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 for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Gunther Mayer wrote: Hardware has always needed quirks (linux-2.4.3 has about 60 occurences of the word "quirks", not to mention workaround, blacklist and other synonyms)! Please apply this little patch instead of wasting time by finger-pointing and arguing. Martin, comments? Is Martin still alive? He hasn't been active in PCI development well over six months, maybe a year now. Ivan (alpha hacker) appeared on the scene to fix serious PCI bridge bugs, DaveM has added some PCI DMA stuff, and I've added a couple driver-related things. I haven't seen code from Martin in a long long time, and only a comment or two in recent memory. --- linux-2.4.3-orig/include/linux/pci.hWed Apr 4 19:46:49 2001 +++ linux/include/linux/pci.h Sat Apr 7 20:01:51 2001 @@ -454,6 +454,9 @@ void (*remove)(struct pci_dev *dev);/* Device removed (NULL if not a hot-plug capable driver) */ void (*suspend)(struct pci_dev *dev); /* Device suspended */ void (*resume)(struct pci_dev *dev);/* Device woken up */ + int multifunction_quirks; /* Quirks for PCI serial+parport cards, + here multiple drivers are allowed to register + for the same pci id match */ }; As has been explained, the current API supports this just fine without modification. Also, changing the API in the stable series should be frowned upon, -especially- something domain specific like this. Jeff -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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 for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Tim Waugh wrote: It would allow support for new multi-IO cards to generally be the addition of about two lines to two files (which is currently how it's done), rather than having separate mutant hybrid monstrosity drivers for each card (IMHO).. ;-) My point of view is that hacking the kernel so that two device drivers can pretend they are not driving the same hardware is silly. With such hardware there are always inter-dependencies, and you can either hack special case code into two or more drivers, or create one central control point from which knowledge is dispatched. Like I mentioned in a previous message, the Via parport code is ugly and should go into a Via superio driver. It is simply not scalable to consider the alternative -- add superio code to parport_pc.c for each ISA bridge out there. I think the same principle applies to this discussion as well. It's just ugly to keep hacking in special cases to handle hardware that is multifunction like this. Jeff -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: Multi-function PCI devices
Tim Waugh wrote: On Sat, Apr 07, 2001 at 01:23:27PM -0400, Jeff Garzik wrote: You asked in your last message to show you code, here is a short example. Note that I would love to rip out the SUPERIO code in parport and make it a separate driver like this short, contrived example. Much more modular than the existing solution. (The superio code is on its way out anyway, for different reasons..) I think there will be further discussion on this :) More modular? Yes, it adds another module to support a card, so yes there are more modules. But with the multifunction_quirks approach, support is a question of adding two lines in a table. struct pci_driver is going to become struct driver, don't forget. With that in mind, the "multifunction_quirks" patch appears even more of a bus-specific hack. Why do you want to dirty the soon-to-be generic driver API for stupid hardware? It takes two seconds to write a shim driver as I have described, and further a shim driver is not necessary on sensible hardware. Jeff -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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 for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Gunther Mayer wrote: Jeff Garzik wrote: Like I mentioned in a previous message, the Via parport code is ugly and should go into a Via superio driver. It is simply not scalable to consider the alternative -- add superio code to parport_pc.c for each ISA bridge out there. I think the same principle applies to this discussion as well. Yes, superio will go away and replaced by user level utility: http://home.t-online.de/home/gunther.mayer/lssuperio-0.61.tar.bz2 The entire point of superio is -not- configuration. That's what your BIOS setup does, and/or user-level utilities. The point of superio support is that you can obtain 100% accurate probe information for legacy ISA devices, by looking at the information exported by the ISA bridge. There is no need for "probing" per se, because you know whether or not the parallel port is enabled, exactly what IRQ it's on, and exactly what DMA channel it uses. So, a superio probe occurs first because it provides the maximum information at the least cost. Since ISA devices must still be supported, the ISA probe should come after the PCI probe (which includes PCI superio stuff). ISA probes to ports already registered via the superio probe fail at the request_region level, avoiding any unnecessary hardware access at those ports. There are tertiary benefits to such a scheme as well, I'll be glad to elaborate on if people are interested in the nitty gritty (read: boring) details. Jeff -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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 for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Gunther Mayer wrote: Jeff Garzik wrote: Gunther Mayer wrote: Hardware has always needed quirks (linux-2.4.3 has about 60 occurences of the word "quirks", not to mention workaround, blacklist and other synonyms)! Please apply this little patch instead of wasting time by finger-pointing and arguing. Martin, comments? Is Martin still alive? He hasn't been active in PCI development well over six months, maybe a year now. Ivan (alpha hacker) appeared on the scene to fix serious PCI bridge bugs, DaveM has added some PCI DMA stuff, and I've added a couple driver-related things. I haven't seen code from Martin in a long long time, and only a comment or two in recent memory. See linux/MAINTAINERS for "PCI Subsystem", the attribute is even called: "Supported: Someone is actually paid to look after this". Who cares... action not words. :) A lot of those MAINTAINERS entries do not reflect reality [which is a bug, of course]. Jeff -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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 for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Gunther Mayer wrote: More module interdependencies == More complicated == More clueless users With module autoloading, they don't have to care about module interdependencies. The primary thing people care about is what string is passed to modprobe. When that changes, things break. As long as that doesn't change, you are ok. Who cares if two or five or ten helper modules are automatically pulled in, and who cares if that list of helper modules changes... Functionally speaking, the user is completely unaware of the change. Many users will be surprised if they must load another module (e.g."pci_multiio") to get their parallel and serial ports working. Thus _must not_ happen in the stable release. Agreed. Jeff -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: Sources of entropy - /dev/random problem for network servers
Alex Bligh - linux-kernel wrote: The machine in question is locked in a data center (can't be the only one) and thus sees none of the former two. IDE Entropy comes from executed IDE commands. The disk is physically largely inactive due to caching. But there's plenty of network traffic which should generate IRQs. Use a hardware random number generator if you need a lot of entropy. The i810 RNG driver and userspace tools at http://sourceforge.net/project/gkernel/ provide an example for an implementation, if your hardware is not i8xx. However, only 3 drivers in drivers/net actually set SA_SAMPLE_RANDOM when calling request_irq(). I believe all of them should. No, because an attacker can potentially control input and make it non-random. Jeff -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: 8139too.c and 2.4.4-pre1 kernel burp
Frank Jacobberger wrote: Jeff, I noticed the following on boot with 2.4.4-pre1: kernel: eth0: Too much work at interrupt, IntrStatus=0x0001. What is this saying to me :) How often does this occur? A lot, or just once or twice? -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: Question on accessing /proc
Srinivasan Venkatraman wrote: I am new to this list. I did go through the FAQ before posting this question. I have a specific requirment - creating,modifying and deleting data structures inside the kernel values of which will be passed by an user application. I know we could do this by writing a system call or by ioctl command to a character device. My question is can we do this by writing to /proc file system ? Can we actually create, modify and delete data structures by accessing this file system ? You could definitely use procfs, but it sounds like your example would be complex. Lately mounting filesystems has become a cheap operation in Linux. Mount/umount is also a convenient synchronization point. So, maybe consider implementing your own tiny filesystems - a data filesystem, where you mmap(2)/read(2)/write(2) data values, and a control filesystem, where you control the system and manipulate data values. That way, you can use standard Unix syscalls, standard Unix tools and standard Unix permissions to accomplish your domain-specific task. -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: Still IRQ routing problems with VIA
Axel Thimm wrote:
0.7.[2,3] are the usb devices. BIOS (and 2.2 kernels) had them at IRQ 5. 2.4
somehow picks the irq of the ethernet adapter, iqr 11, instead.
At least usb is then unusable.
As you say that you have the same board, what is the output of dump_pirq - are
your link values in the set of {1,2,3,5} or are they continuous 1-4? Maybe you
are lucky - or better say, I am having bad luck :(
Changing '#undef DEBUG' to '#define DEBUG 1' in
arch/i386/kernel/pci-i386.h is also very helpful. Can you guys do so,
and post the 'dmesg -s 16384' results to lkml? This includes the same
information as dump_pirq, as well as some additional information.
Note that turning "Plug-n-Play OS" off in BIOS setup typically fixes
many interrupt routing problems -- but Linux 2.4 should now have support
for PNP OS:Yes. Clearly there appear to be problems with that support
on some Via hardware.
Note that you should have "Plug-n-Play OS: Yes" when generated the
requested 'dmesg' output.
Regards,
Jeff
--
Jeff Garzik | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft | and shrieking like a cheerleader."
-
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: Still IRQ routing problems with VIA
On Tue, 10 Apr 2001, Manuel A. McLure wrote: This may be the difference - I always set "Plug-n-Play OS: No" on all my machines. Linux works fine and it doesn't seem to hurt Windows 98 any. Correct, it's perfectly fine to do that on all machines (not just Via). Users should also set "PNP OS: No" for Linux 2.2... Other BIOS settings to verify: Assign IRQ to VGA: no (optional, but you probably don't need a VGA IRQ) Operating System: other (or Unix, depending on the BIOS) Memory hole: no Unless you are using ISA cards, make sure all your PCI plug-n-play IRQ settings are set to "PCI/PnP" not "ISA/ICU". hmmm, maybe I should write a Linux kernel BIOS guide/FAQ... 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/
x86 cpu configuration (was: Re: [PATCH] i386 rw_semaphores fix)
Linus Torvalds wrote: That's no problem if we make this SMP-specific - I doubt anybody actually uses SMP on i486's even if the machines exist, as I think they all had special glue logic that Linux would have trouble with anyway. But the advantages of being able to use one generic kernel that works on plain UP i386 machines as well as SMP P6+ machines is big enough that I would want to be able to say "CONFIG_X86_GENERIC" + "CONFIG_SMP". (slight tangent) FWIW I think the i386 CPU selection logic in make config should be reconsidered in 2.5+... The alpha presents you with a list of platforms, and allows you to select a specific one, or a generic option that includes all platforms. The current way of doing things on x86 -- essentially selecting a minimal level of CPU support -- is nice for vendors like Mandrake who drops support for older CPUs. But it isn't nice for the case where a user wants support for their specific processor and no other. I have a P-II, why include code that only works on K7 or P-III? The embedded people, I think, would find such a change useful too. The only problem with an alpha-like configuration is that Mandrake cannot select a minimum CPU level of support anymore... I guess that could be solved by an "advanced" sub-menu, similar to that which is found in drivers/video/Config.in, which allows fine-grained Y/N selections of CPU support. -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: Still IRQ routing problems with VIA
"Manuel A. McLure" wrote: Jeff Garzik said... Changing '#undef DEBUG' to '#define DEBUG 1' in arch/i386/kernel/pci-i386.h is also very helpful. Can you guys do so, and post the 'dmesg -s 16384' results to lkml? This includes the same information as dump_pirq, as well as some additional information. Here's my dmesg output - I tried with both PNP: Yes and PNP: No and the dmesg outputs were exactly the same modulo a Hz or two in the processor speed detection. Thanks. I'm building a database of these. There is definitely an issue with Via and interrupt routing. Hopefully I can collate this data soon and figure out what's going on. I need to find some Via hardware for myself, too, since I only have an old Via-based laptop which works 100% ;-) I do have an IRQ for my VGA since the instructions for my card (a Voodoo 5 5500) specifically say an IRQ is needed. I wonder though... In my mind this is a driver not hardware issue. If the XFree86 and/or Linux console driver do not use the IRQ, you need not have BIOS assign one. If you are feeling dangerous, try turning the VGA IRQ assignment off in BIOS and see if things melt/explode/kick ass. Regards, Jeff -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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: Still IRQ routing problems with VIA
"Manuel A. McLure" wrote:
I'd do that if this wasn't also my Windows 98 gaming machine - I'm supposing
that the Windows drivers do use the IRQ even if XFree86/Linux doesn't. I
dunno if Windows is smart enough to assign an IRQ even if the BIOS doesn't.
Anyway, things are working now (specially since the last tulip patches) and
I like it that way :-)
Well, as the old saying goes, "if it ain't broke, don't fix it."
Theoretically, with PNP OS enabled, the driver will assign VGA an IRQ if
it needs one, under both Windows and Linux.
Jeff
--
Jeff Garzik | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft | and shrieking like a cheerleader."
-
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] serial ioctl not returning with 2.4.3
Steven Walter wrote:
When I try to start "agetty" on my serial line, agetty hangs in an
ioctl; according to strace, this ioctl is "SNDCTL_TMR_STOP". This
doesn't sound right, but that ioctl is defined as _IO('T', 3) if that
makes any more sense.
The reason that this must be a kernel bug is because agetty works
flawlessly in an identically-configured 2.4.2 kernel, and even a 2.4.3
kernel with the debugging tokens defined. I'd be glad to give any help
that I could.
I am not sure this is a serial driver bug:
[jgarzik@rum linux_2_4]$ find . -name '*.[ch]'|xargs grep -wn
SNDCTL_TMR_STOP
./arch/sparc64/kernel/ioctl32.c:3503:COMPATIBLE_IOCTL(SNDCTL_TMR_STOP)
./drivers/sound/mpu401.c:1522: case SNDCTL_TMR_STOP:
./drivers/sound/sequencer.c:1352: case SNDCTL_TMR_STOP:
./drivers/sound/sound_timer.c:195: case SNDCTL_TMR_STOP:
./drivers/sound/sys_timer.c:206:case SNDCTL_TMR_STOP:
./include/linux/soundcard.h:165:#define SNDCTL_TMR_STOP
_SIO ('T', 3)
--
Jeff Garzik | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft | and shrieking like a cheerleader."
-
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/
