Re: 3c59x: Using bad IRQ 0
Tobias Ringstrom wrote: When saying yes to "Plug-and-play OS" in the BIOS, my 3Com 905C adapter stops working, since the driver tries to use IRQ 0, since the BIOS does not assign an IRQ to it. The driver seems to read the IRQ from the card before it calls pci_enable_device (and pci_set_master). eth0: 3Com PCI 3c905C Tornado at 0xa400, PCI: Enabling device 00:0a.0 (0014 - 0017) PCI: Assigned IRQ 9 for device 00:0a.0 00:01:02:b4:18:e4, IRQ 0 Tobias, can you confirm that calling pci_enable_device before reading dev-irq fixes the 3c59x.c problem for you? It sounds like the 2.4 kernel can now support "plug-n-play OS" BIOS setting, AFAICS. If moving pci_enable_device above any dev-irq checks solves Tobias' problem, we need to go through the PCI drivers and make sure we check things in the correct order in all PCI drivers. I wonder if we shouldn't move pci_resource_xxx calls until after pci_enable_device too. A caveat to this whole scheme is that usb-uhci -already- calls pci_enable_device before checking dev-irq, and yet cannot get around the "assign IRQ to USB: no" setting in BIOS. I hope that is an exception rather than the rule. Regards, Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [uPATCH] fix IDE/ServerWorks OSB4 config option (test11)
Bartlomiej Zolnierkiewicz wrote: --- linux-240t11/drivers/ide/Config.in Wed Nov 15 22:02:11 2000 +++ linux/drivers/ide/Config.in Tue Nov 21 14:52:07 2000 @@ -68,7 +68,7 @@ dep_bool 'OPTi 82C621 chipset enhanced support (EXPERIMENTAL)' CONFIG_BLK_DEV_OPTI621 $CONFIG_EXPERIMENTAL dep_bool 'PROMISE PDC20246/PDC20262/PDC20267 support' CONFIG_BLK_DEV_PDC202XX $CONFIG_BLK_DEV_IDEDMA_PCI dep_bool ' Special UDMA Feature' CONFIG_PDC202XX_BURST $CONFIG_BLK_DEV_PDC202XX - dep_bool 'ServerWorks OSB4 chipset support' CONFIG_BLK_DEV_OSB4 $CONFIG_BLK_DEV_OSB4 + dep_bool 'ServerWorks OSB4 chipset support' CONFIG_BLK_DEV_OSB4 $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86 dep_bool 'SiS5513 chipset support' CONFIG_BLK_DEV_SIS5513 $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86 dep_bool 'SLC90E66 chipset support' CONFIG_BLK_DEV_SLC90E66 $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86 Just wondering, why do these depend on CONFIG_X86? I just glanced at osb4.c and it looks pretty well-written and portable to me... Nothing X86 specific about it. Ditto some of the others depending on CONFIG_X86. IMHO even if the southbridge is currently only known to be used on x86's, that doesn't mean that the hardware, or the driver, will always be limited to the X86 platform. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of static foo = 0 from drivers/ide (test11)
"J . A . Magallon" wrote: On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote: -static int dataPort = 0; /* port for register data */ +static int dataPort; /* port for register data */ That is not too much confidence on the ANSI-ness of the compiler ??? There is nothing wrong with that change. Standard kernel style cleanup, which saves a few bytes in the output kernel image. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch(?): pci_device_id tables for linux-2.4.0-test11/drivers/block
"Adam J. Richter" wrote:
Just to avoid duplication of effort, I am posting this preliminary
patch which adds PCI MODULE_DEVICE_TABLE declarations to the three PCI
drivers in linux-2.4.0-test11/drivers/block. In response to input from
Christoph Hellwig, I have reduced my threshhold on using named initializers
to three entries, although I think that may be going to far, as I would
really like to keep the number of files that initialize the pci_device_id
arrays this way low so that changing struct pci_device_id remains feasible.
*This* is the over-engineering attitude I was talking about. The only
reason why you are preferring named initializers is because
pci_device_id MIGHT be changed. And if it is changed, it makes the
changeover just tad easier. For that, you ugly up the code and make it
more difficult to maintain.
_I_ am one of the people that works on maintaining these random PCI
drivers that no one gives a shit about. And if applied, your patches
make my job just a little bit harder.
We -discourage- these kind of crap design decisions in the Linux kernel.
Don't over-engineer.
--- linux-2.4.0-test11/drivers/block/DAC960.c Thu Oct 26 23:35:47 2000
+++ linux/drivers/block/DAC960.cWed Nov 22 12:42:23 2000
ok
--- linux-2.4.0-test11/drivers/block/cciss.cThu Oct 26 23:35:47 2000
+++ linux/drivers/block/cciss.c Wed Nov 22 12:29:27 2000
@@ -50,6 +50,17 @@
/* Embedded module documentation macros - see modules.h */
MODULE_AUTHOR("Charles M. White III - Compaq Computer Corporation");
MODULE_DESCRIPTION("Driver for Compaq Smart Array Controller 5300");
+static struct pci_device_id cciss_pci_tbl[] __initdata = {
+ {
+ vendor: PCI_VENDOR_ID_COMPAQ,
+ device: PCI_DEVICE_ID_COMPAQ_CISS,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+ },
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, cciss_pci_tbl);
hell no
--- linux-2.4.0-test11/drivers/block/cpqarray.c Thu Nov 16 11:30:29 2000
+++ linux/drivers/block/cpqarray.c Wed Nov 22 12:34:53 2000
ok
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft| -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Patch(?): pci_device_id tables for linux-2.4.0-test11/drivers/block
Andi Kleen wrote: On Wed, Nov 22, 2000 at 05:14:38PM -0500, Jeff Garzik wrote: *This* is the over-engineering attitude I was talking about. The only reason why you are preferring named initializers is because pci_device_id MIGHT be changed. And if it is changed, it makes the changeover just tad easier. For that, you ugly up the code and make it more difficult to maintain. The other reason is that it makes self documenting code -- no need to look up the structure definition to make sense out of the code. For the general case, that is true. But note that the general case is usually a -single- structure being initialized, not an array of structures. Unless the struct members being initialized vary wildly from one array element to another, using named initialized it redundant and -reduces- the ability of the programmer to look at the pci_tbl[] and evaluate its contents at a glance. PCI tables do not use named initalizers on purpose. It was not an accident or design mistake. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW DRIVER] firestream
Jes Sorensen wrote: I think the most important issue is when doing header files to make sure they go with the driver code and not in include/linux unless there really is a reason to expose them to user space. No reason to export register definitions for Ethernet cards down there. Agreed, that there are some headers that IMHO need to be moved out of include/linux because they aren't used in userspace, and they aren't public interfaces, nor shared across directories. -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: PROBLEM: kernel 2.4.0-test11-ac1 hang with usb-uhci and emu10k1
Michael Elkins wrote: On Thu, Nov 23, 2000 at 05:49:52PM +0100, Georg Acher wrote: On Thu, Nov 23, 2000 at 04:35:33PM +, Rui Sousa wrote: On Thu, 23 Nov 2000, Michael Elkins wrote: Usb controller is sharing a interrupt with the emu10k1. For what I know the emu10k1 driver doesn't have any problem sharing irq's, so I would blame the usb driver... usb-uhci doesn't also have any problem with sharing irqs: cat /proc/interrupts 10:5597981 XT-PIC aic7xxx, eth0, usb-uhci Hm, no one left to blame... I would debug it as follows: Place various printks in the initialization code (reset_hc(), start_hc() and alloc_uhci) and find out after which printk it hangs. Then it would be possible to investigate this further... It hangs in start_uhci(): /* disable legacy emulation */ pci_write_config_word (dev, USBLEGSUP, USBLEGSUP_DEFAULT); The loop that the call is in gets iterated 5 times. For i 4, the if (!(dev-resource[i].flags 1)) is TRUE, but on i==4, it drops into the bottom of the loop to execute check_region() and then pci_write_config_word(), where it hangs. It may not make a difference, but that check is flat out wrong. Apply this patch... (untested, you may need to include ioport.h) -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso Index: drivers/usb/usb-uhci.c === RCS file: /cvsroot/gkernel/linux_2_4/drivers/usb/usb-uhci.c,v retrieving revision 1.1.1.9 diff -u -r1.1.1.9 usb-uhci.c --- drivers/usb/usb-uhci.c 2000/10/22 23:25:12 1.1.1.9 +++ drivers/usb/usb-uhci.c 2000/11/23 23:04:37 @@ -2886,7 +2886,7 @@ unsigned int io_addr = dev-resource[i].start; unsigned int io_size = dev-resource[i].end - dev-resource[i].start + 1; - if (!(dev-resource[i].flags 1)) + if (!(dev-resource[i].flags IORESOURCE_IO)) continue; /* Is it already in use? */
Re: Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface
Pavel Machek wrote: Hi! I also agree that the ioctl patch is kind of a bandaid over the problems that you described, and, while Zach Brown can speak The biggest problem is that the current code is gross gross gross. I've been avoiding dealing with it too much in the hopes that moving to oss_audio will make things much more friendly across the board. What is oss_audio? A module I wrote to encapsulate all the OSS logic into a single file. There are so many sound drivers that get their ioctls wrong in certain cases, don't do mmap, etc. that I moved all the logic into one place. You can obtain include/linux/oss_audio.h and drivers/sound/oss_audio.c from gkernel CVS. Check out module 'linux_2_4', tag 'hack_2_4_0_test11'. (http://sourceforge.net/projects/gkernel/) I thought alsa is going in in 2.5... Yep. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: beware of dead string constants
Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: This is mostly a heads-up to say that in this regard gcc is not ready for prime time, so we really can't get away with using if() as an ifdef yet, at least not without penalty. Humm.. whats the Advantage of this? Advantage of what? If you mean preferring 'if ()' over 'ifdef'... Linus. :) And I agree with him: code looks -much- more clean without ifdefs. And the compiler should be smart enough to completely eliminate code inside an 'if (0)' code block. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x: Using bad IRQ 0
Linus Torvalds wrote:
On Thu, 23 Nov 2000, Tobias Ringstrom wrote:
- enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code
print out what the pirq table entries are etc.
Done. When adding the call to eisa_set_level_irq, the line
IRQ for 00:0a.0(0) via 00:0a.0 - PIRQ 03, mask 1eb8, excl - newirq=9 -
assigning IRQ 9 ... OK
was changed into
IRQ for 00:0a.0(0) via 00:0a.0 - PIRQ 03, mask 1eb8, excl - newirq=9 -
assigning IRQ 9 - edge ... OK
Ok.
The thing was marked as edge-triggered, which is basically always wrong
for a PCI interrupt. The above printout just means that it now noticed
that it was edge, and fixed it up in the ELCR.
FWIW Via's PCI to ISA bridge has a PIRQ edge/level register.
Vendor=1106h, Device=686h, PCI config offset 54h, RW
Bits 7-4 reserved, zero.
Bit 3: PIRQA# edge (clear bit for level)
Bit 2: PIRQB# edge (clear bit for level)
Bit 1: PIRQC# edge (clear bit for level)
Bit 0: PIRQD# edge (clear bit for level)
The bits are all supposed to default to zero (level).
- add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before
the "return 1;"
You certainly know your kernel very well... :-)
That's why they pay me the big bucks. Good.
I'll make it do the eisa_set_level_irq() in the generic code: it should
always be right (we don't do it now in the PIIX4 case, for example, but
the PIIX documentation actually says that we _should_), and there is no
need to do it separately for each interrupt router.
So calling eisa_set_level_irq() means nothing will scream if we do not
update [for example] the above register?
Jeff
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft| -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: changing BIOS setting
Andrew Park wrote: Is there a way to change BIOS setting (like boot sequence) from the kernel space? Any pointers would be appreciated. Yes. All the BIOS does is configure your hardware. Get docs on your hardware, and you can do anything that BIOS does. For example, if your parallel port is disabled in BIOS, and you have the datasheet for your southbridge, then you can "manually" enable the parallel port by writing certain values to certain PCI config registers. That said, it is generally a bad idea to do this sort of thing. Unless you have a cluster full of machines that all have a BIOS-related problem, or similar, you should just reboot and adjust your BIOS... Of course, if you are really motivated, you could just flash your own BIOS. Check out http://www.acl.lanl.gov/linuxbios/ Regards, Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x: Using bad IRQ 0
Linus Torvalds wrote: On Tue, 21 Nov 2000, Jeff Garzik wrote: A caveat to this whole scheme is that usb-uhci -already- calls pci_enable_device before checking dev-irq, and yet cannot get around the "assign IRQ to USB: no" setting in BIOS. I hope that is an exception rather than the rule. Do we have a recent report of this with full PCI debug output? It might just be another unlisted intel irq router.. Actually, I -was- able to reproduce this problem on my SMP PIIX4 box here. But as of test11-final, I am no longer able to reproduce it. Maybe some intrepid testers are willing to test 2.4.0-test11 with these BIOS settings: PNP OS: Yes Assign IRQ to USB: No It works for me... :) Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of static foo = 0
Andries Brouwer wrote:
In a program source there is information for the compiler
and information for the future me. Removing the " = 0"
is like removing comments. For the compiler the information
remains the same. For the programmer something is lost.
This is pretty much personal opinion :)
The C language is full of implicit as well as explicit features. You
are arguing that using an implicit feature robs the programmer of
information. For you maybe... For others, no information is lost AND
the code is more clean AND the kernel is smaller. It's just a matter of
knowing and internalizing "the rules" in your head.
Jeff
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft| -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Patch: linux-2.4.0-test11ac4/drivers/net/tokenring/{tmspci,abyss}.c __devinit fixes
"Adam J. Richter" wrote: I hope this patch will be applied both to the development version of the driver and, ideally, to Alan's tree, and really ideally, propagated to Linus with the rest of Adam Fritzler's port. These are not fixes, please do not apply. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Pls add this driver to the kernel tree !!
On Tue, 28 Nov 2000, John B. Jacobsen wrote: /* winbond-840.c: A Linux PCI network adapter skeleton device driver. */ It is already in 2.4.x Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: corruption
On Fri, 1 Dec 2000, Andrew Morton wrote:
Alexander Viro wrote:
Confirms. That's definitely an empty list_head at address 0xc3c49058 and -pre2
has O_SYNC patches.
foo. The overnight run wedged tight in mmap002. No progress.
I bet this'll catch it:
--- include/linux/list.h.orig Fri Dec 1 08:33:36 2000
+++ include/linux/list.h Fri Dec 1 08:33:55 2000
@@ -90,6 +90,7 @@
static __inline__ void list_del(struct list_head *entry)
{
__list_del(entry-prev, entry-next);
+ entry-next = entry-prev = 0;
}
Or just call list_del_init instead...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: why volatile on vgacon.c?
On Wed, 29 Nov 2000, Andries Brouwer wrote:
On Wed, Nov 29, 2000 at 05:24:15PM +0100, Santiago Garcia Mantinan wrote:
That was on 2.2 series, but since I moved it to 2.4 series I don't have that
cga card found anymore. I have looked on the kernel code and followed it to
the __init function in vgacon.c, more concretely this piece of code...
scr_writew(0xAA55, p);
scr_writew(0x55AA, p + 1);
if (scr_readw(p) != 0xAA55 || scr_readw(p + 1) != 0x55AA) {
Well, the thing is that this code and the code in this function is almost
the same in 2.4 as in 2.2, however reading returns the written values on 2.2
and different ones (0x) on 2.4
Probably without the volatile the compiler optimizes the entire
if statement away because it very well knows that it just wrote
these values there. With the volatile it has to check, and finds
that there is nothing there.
hmmm. That's why barriers exist, right?
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
On Sat, 2 Dec 2000, Igmar Palsenberg wrote: Indeed, you are correct. Is vpnd broken then, for assuming that it can gather the required randomness in one read? Yep. It assumes that if the required randommness numbers aren't met a read to /dev/random will block. And it's not the only program that assumes this : I also did. /dev/random is called a blocking random device, which more or less implies that it will totally block. I suggest we put this somewhere in the kernel docs, since lots of people out there assume that it totally blocks. "totally block"? For a blocking fd, read(2) has always blocked until some data is available. There has never been a guarantee, for any driver, that a read(2) will return the full amount of bytes requested. There is no need to document this... man read(2) ;-) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
On Sun, 3 Dec 2000, Chris Wedgwood wrote:
Russell King [EMAIL PROTECTED] écrit :
[...]
We already have a standard interface for this, but many drivers do not
support it. Its called "ifconfig eth0 media xxx":
Actually, I starteed work on adding this to the 3c59x code last
night; I am now a little dispondent though as it wasn't as simple as
I first thought it might be.
Does 'ifconfig eth0 media xxx' wind up calling dev-set_config?
If yes, my guess is correct, I think the proper solution is to:
* create a generic set_config, which does nothing but convert the calls'
semantics into ethtool semantics, and
* add ethtool support to the specific driver
And you might even go so far as to create a generic MII implementation
of ethtool support, so that existing drivers can simply plug in their
mdio_{read,write} functions to automatically get full ethtool support.
(disclaimer: this is a spur-of-the-moment thought, creating a generic
MII module for ethtool support may not be feasible)
drivers/net/sis900.c implements set_config, if you want an example..
Finally, if you want to just use ethtool directly, grab the SRPM and
install it on your system.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test11: arch/i386/boot/bootsect.S incompatible with Vaio C1VE (Crusoe) floppy
On Sat, 2 Dec 2000, Wolfgang Spraul wrote: 2.4.0-test11, arch/i386/boot/bootsect.S has a probe_loop: to determine the number of sectors that can be read at once (i.e. in one track). This routine does not work with the Sony UDF5 USB floppy disk, mapped as an Int13 device by the Vaio C1VE (Crusoe) BIOS. Therefore, a bzdisk floppy will not be bootable. The bzdisk code is used so infrequently compared to the normal bootloaders, lilo, grub, and syslinux, that I'm not surprised it has problems with many edge cases. Although I imagine this is an unpopular opinion, I think that we should remove all bzdisk-type code from X86... syslinux and other boot loaders handle weird BIOS quirks much better, simply because they are used in far more situations than bzdisk. syslinux especially is quite nice for loading kernels from floppy. It's very small, and "syslinux -s" adds in some wonderfully-paranoid sanity checks which make boot loading works on many a quirky BIOS. (don't use '-s' unless you need it, of course, it slows things down...) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test11: hangs while Probing PCI hardware for Sony Vaio C1VE (Crusoe)
On Sat, 2 Dec 2000, Wolfgang Spraul wrote: PhoenixBIOS, Sony Vaio C1VE I did some printk() debugging, but the kernel hangs at various places in pci_setup_device(), mostly in pci_read_bases(). This is a Transmeta laptop, right? See the recent thread with "Transmeta" in the subject. The problem seems to have been identified, and hopefully the fix will appear in test12-pre4, when released... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sunhme.c patch for new PCI interface (UNTESTED)
"Adam J. Richter" wrote:
-static struct happy_meal *root_happy_dev = NULL;
-
#ifdef CONFIG_SBUS
+static struct happy_meal *root_happy_dev = NULL;
static struct quattro *qfe_sbus_list = NULL;
#endif
don't initialize static to zero/null explicitly..
- if (dev == NULL) {
- dev = init_etherdev(0, sizeof(struct happy_meal));
- } else {
- dev-priv = kmalloc(sizeof(struct happy_meal), GFP_KERNEL);
- if (dev-priv == NULL)
- return -ENOMEM;
- }
+ dev = init_etherdev(0, sizeof(struct happy_meal));
allocation failure not checked
-static int __init happy_meal_pci_init(struct net_device *dev, struct pci_dev *pdev)
+static int __devinit happy_meal_pci_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
Are you aware of any hotplug sunhme hardware? If no, don't change it to
__devinit...
- if (dev == NULL) {
- dev = init_etherdev(0, sizeof(struct happy_meal));
- } else {
- dev-priv = kmalloc(sizeof(struct happy_meal), GFP_KERNEL);
- if (dev-priv == NULL)
- return -ENOMEM;
- }
+ dev = init_etherdev(0, sizeof(struct happy_meal));
check for failure.
also, ether_setup() call is not needed if you always call
init_etherdev(NULL, ...).
+static void __devexit happy_meal_pci_remove (struct pci_dev *pdev)
+{
+ struct happy_meal *hp = pdev-driver_data;
+
+ pci_free_consistent(hp-happy_dev,
+ PAGE_SIZE,
+ hp-happy_block,
+ hp-hblock_dvma);
+ unregister_netdev(hp-dev);
+ kfree(hp-dev);
+}
zero pdev-driver_data. If this driver has to be portable, use
pci_{get,set}_drvdata() instead of directly accessing ::driver_data.
+static struct pci_device_id happymeal_pci_ids[] __devinitdata = {
again, no __devxxx if not hotplug.
#ifdef CONFIG_PCI
- cards += happy_meal_pci_probe(dev);
+ return pci_module_init(happy_meal_pci_driver);
+#else
+ return (cards 0) ? 0 : -ENODEV;
#endif
ifdef not needed
+#ifdef CONFIG_PCI
+ pci_unregister_driver (happy_meal_pci_driver);
+#endif
ifdef not needed.
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft| -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
On Sun, 3 Dec 2000, Keith Owens wrote: If you go down this path, please add a standard performance monitoring method to query the current capacity of an interface. to report "eth0 is handling 1 Megabyte/second, but we cannot tell if that is 90% (10BaseT) or 9% (100BaseT) utilization". We should report capacity rather than speed because speed alone is not the controlling factor, other things like half or full duplex affect the capacity. Well, ethtool interface supports reporting media selection as well as [re]setting media setting. I dunno if we could report what capacity an interface is handling without adding code to hot paths... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/random probs in 2.4test(12-pre3)
On Sun, 3 Dec 2000, Igmar Palsenberg wrote: Any programmer who has evolved sufficiently from a scriptie should take necessary precautions to check how much data was transferred. Those who don't..well, there is still tomorrow. There is no reason to add any additional documentation. If we did, we'd be starting the trend of documenting the direction a mouse moves when it's pushed and not to be alarmed if you turn the mouse sideways and the result is 90 degrees off. random devices are different. If it request 10 bytes on random stuff, I want 10 bytes. Anything less is a waste of the read, because I need 10 bytes. At least, in my opinion. Anyone has an insight how other *NIX'es handle this ? This is standard stuff... You are really pissing into the wind here ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sunhme.c patch for new PCI interface (UNTESTED)
"Adam J. Richter" wrote:
Jeff Garzik writes:
Are you aware of any hotplug sunhme hardware? If no, don't change it to
__devinit...
Can I have a hot plug PCI bridge card that connects to
a regular PCI backplane (perhaps as some kind of CardBus docking
station card)? If so, all PCI drivers should use __dev{init,exit}{,data}.
I am willing to consider adding __devxxx only when other __devxxx
entries already exist.
These conversions to _devxxx are too late in the freeze, and only have
value for isolated cases --which you admit you don't even know exist--.
Linus Rule 1: Don't overdesign. Even if such cases do exist, and this
is a need, it should be addressed some other way.
Your suggestion bloats drivers needlessly for the majority of cases and
I will not be applying any such patches...
Jeff
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft| -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre4
On Sun, 3 Dec 2000, Mohammad A. Haque wrote: Was borking on dummy.c. This seemed to fix it. Verification please? gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11/include -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.0-test11/include/linux/modversions.h -c -o dummy.o dummy.c dummy.c: In function `dummy_init_module': dummy.c:103: invalid type argument of `-' make[2]: *** [dummy.o] Error 1 No, module.h needs fixing. I guess I didn't send that one to Alan... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre4 drivers/net/dummy
the fix is in module.h which needs extra parens in the def of set_module_owner... Jeff On Mon, 4 Dec 2000, Mohammad A. Haque wrote: Patch posted here... http://marc.theaimsgroup.com/?l=linux-kernelm=97590235825341w=2 "Garst R. Reese" wrote: Fails to compile module at line 103, invalid type argument of - Sorry if this well known. Garst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i810_audio 2.4.0-test11
On Mon, 4 Dec 2000, Thomas Sailer wrote: And before killing format conversion you should kill the mmap stunt, because the format conversion complexity (~25 LOC) is by far dwarfed by the mmap emulation stuff. mmap -emulation- ?? Ug. Is Quake really worth that much? :) The underlying question is: - do we want an usb audio driver that supports the OSS interface and with which most existing applications work of course Anything in between is IMO silly. Killing the format conversion drops the advantage of running many existing applications but don't bring you much closer to the goal of simplicity. OSS has always implied that the software performs conversions when the hardware cannot support certain formats. And the kernel direction has always been to -remove- any software conversion code. We removed SoftOSS, for example. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0.12.4: drivers/net/dummy.c fails compile
On Mon, 4 Dec 2000, Horst von Brand wrote: SPARC64, Red Hat 6.2 + local updates A better patch has already been posted, and is present in the 2.4.0-test11-ac series. module.h needs to be modified to protect the argument of SET_MODULE_OWNER. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre6
Erik Mouw wrote:
On Wed, Dec 06, 2000 at 11:38:30AM -0800, Linus Torvalds wrote:
But I see something obviously wrong there: you have busmaster disabled.
Looking into the UHCI controller code, I notice that neither UHCI driver
actually does the (required)
pci_set_master(dev);
Please add that to just after a successful "pci_enable_device(dev)", and I
just bet your USB will start working.
Yes, that did the trick! Problem solved, thanks a lot!
Johannes, Georg, the above is a fairly embarrassing bug, and is likely to
explain a _lot_ of USB failures (the OHCI driver does do this, btw).
Here is the patch, I don't know if it is enabled in the right place,
but it definatively fixes the problem.
--- drivers/usb/uhci.c.old Wed Dec 6 20:55:05 2000
+++ drivers/usb/uhci.c Wed Dec 6 20:55:37 2000
@@ -2383,6 +2383,8 @@
if (pci_enable_device(dev) 0)
return -ENODEV;
+ pci_set_master(dev);
+
if (!dev-irq) {
err("found UHCI device with no IRQ assigned. check BIOS
settings!");
return -ENODEV;
--- drivers/usb/usb-uhci.c.old Wed Dec 6 20:53:58 2000
+++ drivers/usb/usb-uhci.c Wed Dec 6 20:54:48 2000
@@ -2941,6 +2941,8 @@
if (pci_enable_device(dev) 0)
return -ENODEV;
+
+ pci_set_master(dev);
/* Search for the IO base address.. */
for (i = 0; i 6; i++) {
I didn't test your patch, but it looks good. Immediately following
pci_enable_device is generally a really good place for the call to
pci_set_master.
Jeff
--
Jeff Garzik |
Building 1024 | These are not the J's you're lookin' for.
MandrakeSoft| It's an old Jedi mind trick.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre6
Miles Lane wrote: Hmm. Your patch doesn't test whether pci_enable_device(dev) was successful, does it? eh? It's self-evident from Erik's patch that pci_enable_device's return call is already being tested, thus you only need to add a call to pci_set_master. Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC-2] Configuring Synchronous Interfaces in Linux
Alan Cox wrote:
I think we need few ioctl calls: get + set media (int argument),
get + set speed (probably two - RX and TX), etc.
In my 2.4 HDLC stuff - to be published :-( - there something like that
(in private ioctl range, of course).
I think we are agreeing
I'm saying use something like
struct
{
u16 media_group;
union
{
struct hdlc_physical ...
struct hdlc_bitstream
struct hdlc_protocol
struct fr_protocol
struct eth_physical
Not yet another one for eth... We now have ethtool for this. And a
generic netdevice::set_config wrapper can be created that simply calls
the ethtool ioctl with the proper info and locking.
Jeff
--
Jeff Garzik |
Building 1024 | These are not the J's you're lookin' for.
MandrakeSoft| It's an old Jedi mind trick.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NTFS repair tools
Peter Samuelson wrote: [Jeff Merkey] Please consider the attached patch to make it a little bit harder for folks to enable NTFS Write Support under Linux until it can get fixed properly. Hey! It was a joke! A better way would be just to comment out the CONFIG_NTFS_RW line entirely. Actually, I think that *would* be a good idea. Anyone who has any business messing with NTFS_RW is more than capable of editing Config.in. Agreed. I would prefer that filesystems with known broken write support depend on CONFIG_BROKEN (which would be always defined to 'n') Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
Peter Horton wrote: On Wed, Dec 06, 2000 at 07:44:02PM -0500, Mike A. Harris wrote: Which ethernet module works with this card? 2.2.17 kernel If the PCI device ID is 3065 then it's via-rhine, but not supported by the driver in the kernel. Get updated via-rhine from Donald Becker's site http://www.scyld.com/network. 2.4.x-test has some fixes for via-rhine which don't appear to have made it into the Becker driver yet... Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: question about tulip patch to set CSR0 for pci 2.0 bus
Clayton Weaver wrote: Shouldn't the setting of the CSR0 value for x86 switch between normal (0x01A08000) and cautious (0x01A04800) based on some notion of what generation of pci bus is installed rather than what cpu the kernel is compiled for? That's one thing that bothered me about the method that the .90 driver used. It worked for me, of course, cool, but when I thought about putting a real general purpose patch into later versions of tulip.c to solve the same problem, it bothered me that the old method assumes an association between pci bus and cpu that may not be valid. I don't know that there are any 386/486/5x86 systems that can use the 0x01A08000 setting (that apparently works on most x86 pci 2.1 busses), but then again I don't know that there aren't, either. If the pci bus level is 2.0, it makes sense to use the cautious CSR0 setting, for the same reasons that the .90 tulip.c in 2.0.38 does, and if the pci level is 2.1, you aren't taking any chances with 0x01A08000 that the driver doesn't take now. The pci driver, initialized before any pci devices, appears to know whether you have a pci 2.0 or pci 2.1 bus, so why not use that information instead of cpu generation? A good suggestion, too... Some other hardware behaves differently based on PCI bus version, it would be nice for the driver to notice that and enable (or disable) advanced features. To blindly assume is just a PCI bus lockup waiting to happen... Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development Documentation?
Daniel Phillips wrote:
On Fri, 08 Dec 2000, Alan Cox wrote:
For the kernel stuff there is a project to put documentation about functions
and what they do inline into the kernel. Its slow progress. Trying to do
anything formal and structured isnt going to be productive until the
documentation is much much more complete
Tigran Aivazian has been preparing 'Linux Kernel Internals' which is
*highly recommended* and 100% free. Why don't you get together with
him, and Gary Lawrence Murphy (see his monthy kernel wiki nag)?
Personally, I try to do the right thing and submit at least one piece
of documentation per month to somebody's documenation project but...
it's not always so easy to free up the required hour or two. This
month my feeble attempt consisted of nagging Ben LaHaise to submit a
particularly lucid email he sent me as a code comment.
Lucid e-mails often get stuck into Documentation/*, that's fine.
The preferred is 'make {pdf,ps,html}docs' as yanked from
Documentation/DocBook.
Jeff
--
Jeff Garzik |
Building 1024 | These are not the J's you're lookin' for.
MandrakeSoft| It's an old Jedi mind trick.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: NTFS repair tools]
"Jeff V. Merkey" wrote: On Fri, Dec 08, 2000 at 02:00:29PM +, Alan Cox wrote: Agree. We need to disable it, since folks do not read the docs (obviously). Of course, we could leave it on, and I could start charging money for these tools -- there's little doubt it would be a lucrative business. Perhaps this is what I'll do if the numbers of copies keeps growing. When it hits 100 per week, it's taking a lot of our time to support, so I will have to start charging for it. I am very firmly against removing something because people do not read manuals, what is next fdisk , mkfs ?. We should put in a nastier message then. It WILL DESTROY DATA IRREPARABLY and I've got even more bad news -- because it's in Linux, Microsoft is already altering the on-disk structures again, so it's about to be broken in R/O mode as well when Whistler comes out. We don't need any messages. If (DANGEROUS) is not sufficient, then disable the feature unconditionally. Someone hacking on the code will be smart enough to enable the stuff while they are debugging. Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial cardbus code.... for testing, please.....
Linus Torvalds wrote: On Sat, 9 Dec 2000, Theodore Y. Ts'o wrote: I didn't have time to do more than just quickly apply the patch and leave in a hurry, but my Vaio certainly recognized the serial port on the combo cardbus card I have with this patch. Everything looked fine - I got a message saying it found a 16450 on ttyS4 when I plugged the card in. When you have a chance, can you check and make sure that you actually can talk to the modem? That will make me feel much better. Done. It works perfectly fine for me, with the following caveat: It crashes hard if I remove the card while the modem is in use, though (ie insert card, point minicom at it, sit at the minicom window while removing the card). This is a problem that many drivers have: when the card is removed, the driver sees an interrupt (which happens to be the CardBus card removal interrupt, but the serial driver doesn't know that, and the way cardbus interrupts work it's always shared with the driver). So the serial driver reads the modem status byte, which is all ones, and decides that there is a ton of work to do. It then loops forever, because the status byte bits will obviously continue to be all ones. Note how the "rs_interrupt()" routine _tries_ to avoid this by having a pass counter value, but that logic never triggers because we will loop forever in receive_chars(), so the rs_interrupt() counter never even gets to increment. Other places in serial.c check for 0xff, which implies we can and should do the same in the interrupt handler... /* * If we read 0xff from the LSR, there is no UART here. */ if (serial_in(info, UART_LSR) == 0xff) return -1; I'm starting to think this Ositech Jack of Spades is unusual in some way, since your (Linus) BestData card and other serial CardBus cards sound like they work. Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hotplug mopup
Andrew Morton wrote: - On the unregister/removal path, the netdevice layer ensures that the interface is removed from the kernel namespace prior to launching `/sbin/hotplug net unregister eth0'. This means that when handling netdevice unregistration /sbin/hotplug cannot and must not attempt to do anything with eth0! Generally it'll fail to find an interface with this name. If it does find eth0, it'll be the wrong one due to a race. This is not a bug. 'unregister eth0' says to userspace "eth0 just disappeared." Read my previous messages on the subject: Add events like NETDEV_UP, NETDEV_DOWN, and NETDEV_GOING_DOWN to netdev_event_names[] if you want to call /sbin/hotplug for other netdev events. Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial cardbus code.... for testing, please.....
Linus Torvalds wrote: Oh, serial_cb shouldn't work anyway, I think. As soon as the serial.c hotplug patch appear, you'll be receiving a patch that eliminates serial_cb. Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial cardbus code.... for testing, please.....
"Theodore Y. Ts'o" wrote: Date: Sat, 09 Dec 2000 11:13:59 -0500 From: Jeff Garzik [EMAIL PROTECTED] Note how the "rs_interrupt()" routine _tries_ to avoid this by having a pass counter value, but that logic never triggers because we will loop forever in receive_chars(), so the rs_interrupt() counter never even gets to increment. Other places in serial.c check for 0xff, which implies we can and should do the same in the interrupt handler... No, other places in the serial driver check for 0xff *after* setting various registers and clearing various flags. Those various initializations are critical before you can simply do a "bail if LSR == 0xff" check. Looking through the code, isn't this setup complete before any interrupts get delivered to rs_interrupt? It's possible (not very likely, but possible) for LSR to go into christmas tree mode where all of the flags are set in normal operation. So for the interrupt driver, we're going to have to do some kind of loop based thing --- if interrupt driver receives 0xff more than some number of times, bail. oh well :) Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial cardbus code.... for testing, please.....
"Theodore Y. Ts'o" wrote: In any case, I think I know how to fix the serial driver to not loop in receive_chars(). If I get this working, do you want to take a serial driver update now or post 2.4.0? I have a number of fixes queued up that I didn't consider critical, so I haven't fed them to you. One of them is from an SGI engineer who's been harassing me about getting one of the changes in, since he's apparently on deadline and he needs a change for one of his SGI MIPS boxes. I don't understand why he can't just use a kernel with a patch, but whatever... FWIW I don't think you should sit on fixes until post 2.4.0... and I would like to get CardBus serial working because it's broken in the current tree... Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Swapping-over-nbd deadlock fixed?
I see in the 2.2.18 release notes that a deadlock, related to swapping over a network via nbd, was fixed. Is this bug present in 2.4.x-test? -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] generic_serial's block_til_ready
Nick Holloway wrote: [EMAIL PROTECTED] (Patrick van de Lageweg) writes: This patch renames the block_til_ready of generic serial to gs_block_til_ready. it helps when other modules have a "static block_til_ready" defined when used older modutils. Do you mean older than the version specified as being required in Documention/CHANGES? If so, then I'm not surprised the patch has not been applied (how many times have you sent it?). His patch is a namespace cleanup, which IMHO should be applied... Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: National Semiconductor DP83815 ethernet driver?
Torrey Hoffman wrote: I am wondering about the current status of a driver for the NS83815 ethernet chip. From searching Google, I know some sort of driver exists. In July, Adam J. Richter ([EMAIL PROTECTED]) posted a 2.2.16 driver he obtained from Dave Gotwisner at Wyse Technologies. And Tim Hockin mentioned that he was using an NSC driver, but had made some minor modifications. Use drivers/net/natsemi.c... it's in 2.4.x-test. -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
Simon Huggins wrote: On Fri, Dec 08, 2000 at 09:56:15AM -0500, Jeff Garzik wrote: Peter Horton wrote: If the PCI device ID is 3065 then it's via-rhine, but not supported by the driver in the kernel. Get updated via-rhine from Donald Becker's site http://www.scyld.com/network. 2.4.x-test has some fixes for via-rhine which don't appear to have made it into the Becker driver yet... Is either of these likely to make it into the stock 2.2 via-rhine? Becker never replies to patches and changes I send him, so who knows. Ask Becker... Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: insmod problem after modutils upgrading
Christian Ullrich wrote: * Corisen schrieb am Donnerstag, 14.12.2000: executing "insmod 8139too" at the command prompt shows the following error message: using /lib/modules/2.4.0-test12/kernel/drivers/net/8139too.o /lib/modules/2.4.0-test12/kernel/drivers/net/8139too.o: symbol for parameter debug not found. how can i make insmod load the network module again pls? I "fixed" the same problem in 2.2.18 by commenting out the line MODULE_PARM (debug, "i"); near the end of drivers/net/8139too.c. Since I run modutils 2.3.22 as well, it can't be related to the modutils. Yep, that's the correct fix -- remove that line. My apologies to Keith Owens for originally saying the opposite (I deal with so many net drivers they all get jumbled up in my mind) Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: insmod problem after modutils upgrading
Alan Cox wrote: how can i make insmod load the network module again pls? I "fixed" the same problem in 2.2.18 by commenting out the line MODULE_PARM (debug, "i"); near the end of drivers/net/8139too.c. Since I run modutils 2.3.22 as well, it can't be related to the modutils. It is modutils. Their behaviour changed in a non back compatible way. Do not use modutils 2.3.22 with Linux 2.2.* is the simple answer. Perhaps Keith can make this a warning in 2.3.23 That, and/or allow "insmod -f" to load the module. '-f' has become pretty useless lately... :) Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [Fwd: [PATCH] cs89x0 is not only an ISA card]
Russell King wrote: Erik Mouw writes: The Crystal CS89x0 ethernet chip is also used in quite some embedded systems that don't have an ISA bus at all, so the CONFIG_ISA option in drivers/net/Config.in is inapropriate. Here is a patch against 2.4.0-test12 to fix that. Please consider applying. I don't think this is the right way to fix the problem. Take for instance an EBSA285 platform which has only PCI sockets. It is possible to plug in a card with an ISA bridge on, with a ESS SB clone on board (I have one here). Maybe the right thing to do is to define CONFIG_ISA on these architectures/ machine types where the device itself is actually an ISA device, instead of going through special-casing the driver configuration entries? Agreed. We -don't- want to remove CONFIG_ISA or other dependencies. The idea for drivers/net/Config.in at least is that all architectures can source the file, and be presented with a proper list of devices for that platform. For an embedded board that supports cs89x0, as you suggest, defining CONFIG_ISA is a much better option. Or, making cs89x0 dependent on CONFIG_EMBEDDED_PLATFORM -and- CONFIG_ISA. Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
The test13-pre1 changelog was something along the lines of "alright, I am sick of this Makefile crap. I fixed some, clean up the rest." ;-) -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
It may work, but the bridge secondary/subordinate numbers look wrong. I am pondering if the bus numbering/bridging stuff shouldn't be given a good looking-over. I have the wonderful _PCI System Architecture, 4th Ed._ in my hands, and it describes PCI-PCI bridge init in great detail, including several multi-bus, multi-bridge examples. (Martin, run don't walk to amazon to get this book.) Anyway, this book seems to imply that we are getting stuff really wrong somewhere. First, some definitions: downstream - away from the host processor primary - number of the PCI bus closer to the host processor secondary - number of the PCI bus on the downstream side of the PCI bridge subordinate - number of the highest-numbered bus on the downstream side of the PCI bridge 00:03.0 CardBus bridge: Texas Instruments PCI1131 (rev 01) Bus: primary=00, secondary=02, subordinate=05, sec-latency=0 First bridge on bus 0. primary == 0 - ok secondary == 2, should be 1 (bus #1 is behind this bridge) subordinate == 5, should be 2 (bus #2 follows us) 00:03.1 CardBus bridge: Texas Instruments PCI1131 (rev 01) Bus: primary=00, secondary=06, subordinate=09, sec-latency=0 Second bridge on bus 0. primary == 0 - ok secondary == 6, should be 2 (bus #2 behind this bridge) subordinate == 9, should be 3 (bus #3 follows us) 00:11.0 PCI bridge: Intel Corporation 82380FB (rev 01) (prog-if 80) Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Third bridge on bus 0. primary == 0 - ok secondary == 1, should be 3 (bus #3 behind this bridge) subordinate == 1, should be 3 (no bus follows, so subordinate==secondary) Now... this final bridge, the PCI (not CardBus) bridge, actually looks ok... if you imagine that the third bridge is configured before the CardBus bridges for some reason. Bus number 1 appears to be laid out correctly. However, the two CardBus bridges have totally wrong values for the secondary and subordinate bridge numbers, whatever the cause. Questions: Martin, any idea why the bridges are numbered like this? Second, will anything break if bus numbers change on x86? There exists pcibios_assign_all_busses() on all platforms... but only Alpha defines it to 1. All others define it to zero. include/asm-alpha/pci.h: /* Override the logic in pci_scan_bus for skipping already-configured bus numbers. */ #define pcibios_assign_all_busses() 1 And Jamal, can you privately e-mail me your 'dmesg' output (with debugging enabled in pci-i386.h), from -before- applying patches. Regards, Jeff -- Jeff Garzik| Raft naked... Building 1024 | It adds color to your cheeks. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PATCH 2.4.0.10.6: always no-strict-aliasing
Linus Torvalds wrote: (a) the new compiler requirements (sorry, but it turned out that 2.7.2.3 really is too subtly broken with named structure initializers that are very heavily used these days inside the kernel) Suggested stable compiler: gcc-2.91.66, aka egcs-1.1.2, which is the one most vendors have been shipping for a long time, and while sure to be buggy too has not been found to be seriously so at least yet. Other modern gcc versions may well work too. Since egcs-1.1.2 supports -fno-strict-aliasing, would the attached patch against linux/Makefile be appropriate? -- Jeff Garzik| Raft naked... Building 1024 | It adds color to your cheeks. MandrakeSoft | Index: Makefile === RCS file: /cvsroot/gkernel/linux_2_4/Makefile,v retrieving revision 1.1.1.11 diff -u -r1.1.1.11 Makefile --- Makefile2000/10/22 23:14:50 1.1.1.11 +++ Makefile2000/10/27 08:32:28 @@ -16,7 +16,7 @@ FINDHPATH = $(HPATH)/asm $(HPATH)/linux $(HPATH)/scsi $(HPATH)/net HOSTCC = gcc -HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer +HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer +-fno-strict-aliasing CROSS_COMPILE = @@ -87,7 +87,7 @@ CPPFLAGS := -D__KERNEL__ -I$(HPATH) -CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer +CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer +-fno-strict-aliasing AFLAGS := -D__ASSEMBLY__ $(CPPFLAGS) # @@ -181,9 +181,6 @@ DRIVERS += $(DRIVERS-y) include arch/$(ARCH)/Makefile - -# use '-fno-strict-aliasing', but only if the compiler can take it -CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc /dev/null /dev/null 21; then echo "-fno-strict-aliasing"; fi) export CPPFLAGS CFLAGS AFLAGS
Re: [patch] kernel/module.c (plus gratuitous rant)
Pavel Machek wrote: Would it be possible to keep 2.7.2.3? You still need 2.7.2.3 to reliably compile 2.0.X (and maybe even 2.2.all-but-latest?). What fails, when you use egcs-1.1.2 to build 2.0.x or early 2.2.x? Maybe they need -fno-strict-aliasing... is that what you are referring to? Regards, Jeff -- Jeff Garzik| "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft | dash and screaming like a cheerleader." | -Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PATCH 2.4.0.10.6: video4linux API update, bttv mmap rewrite
Thought some people here might be interested in this too... Description
quoted below.
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft| dash and screaming like a cheerleader."
| -Max
This patch, against 2.4.0-test10-pre6, updates bttv to use the new and
groovy method of supporting mmap.
Advantages:
* Code more simple.
* mmap now only limited to number of free pages in the system (busts vmalloc limits)
* mmap no longer requires vmalloc, or remap_page_range.
Disadvantages:
* Requires videodev API update (new member: mmap_vma).
* KNOWN BUG: If your gbufsize causes a frame to cross a page boundary,
you lose. The code doesn't support this, and doesn't check for it
either. Boom. (this is fixable though)
* Totally untested. I don't own any bttv hardware.
Index: include/linux/videodev.h
===
RCS file: /cvsroot/gkernel/linux_2_4/include/linux/videodev.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 videodev.h
--- include/linux/videodev.h2000/10/22 19:36:11 1.1.1.1
+++ include/linux/videodev.h2000/10/28 07:31:20
@@ -32,6 +32,7 @@
int busy;
int minor;
devfs_handle_t devfs_handle;
+ int (*mmap_vma)(struct file *, struct vm_area_struct *, struct video_device *);
};
extern int videodev_init(void);
Index: drivers/media/video/bttv-driver.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/media/video/bttv-driver.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 bttv-driver.c
--- drivers/media/video/bttv-driver.c 2000/10/22 22:02:34 1.1.1.2
+++ drivers/media/video/bttv-driver.c 2000/10/28 07:31:24
@@ -142,16 +142,6 @@
return ret;
}
-static inline unsigned long uvirt_to_bus(unsigned long adr)
-{
-unsigned long kva, ret;
-
-kva = uvirt_to_kva(pgd_offset(current-mm, adr), adr);
- ret = virt_to_bus((void *)kva);
-MDEBUG(printk("uv2b(%lx--%lx)", adr, ret));
-return ret;
-}
-
static inline unsigned long kvirt_to_bus(unsigned long adr)
{
unsigned long va, kva, ret;
@@ -163,79 +153,60 @@
return ret;
}
-/* Here we want the physical address of the memory.
- * This is used when initializing the contents of the
- * area and marking the pages as reserved.
+/*
+ * Alloc and free DMA pages for mmap(2)
*/
-static inline unsigned long kvirt_to_pa(unsigned long adr)
-{
-unsigned long va, kva, ret;
-
-va = VMALLOC_VMADDR(adr);
-kva = uvirt_to_kva(pgd_offset_k(va), va);
- ret = __pa(kva);
-MDEBUG(printk("kv2pa(%lx--%lx)", adr, ret));
-return ret;
-}
-
-static void * rvmalloc(signed long size)
+
+static void free_dmabuffers(struct bttv *btv)
{
- void * mem;
- unsigned long adr, page;
+ unsigned int i;
- mem=vmalloc_32(size);
- if (mem)
- {
- memset(mem, 0, size); /* Clear the ram out, no junk to the user */
- adr=(unsigned long) mem;
- while (size 0)
-{
- page = kvirt_to_pa(adr);
- mem_map_reserve(virt_to_page(__va(page)));
- adr+=PAGE_SIZE;
- size-=PAGE_SIZE;
- }
+ if (btv-page) {
+ for (i = 0; i btv-n_pages; i++)
+ if (btv-page[i].cpuaddr)
+ pci_free_consistent (btv-dev, PAGE_SIZE,
+btv-page[i].cpuaddr,
+btv-page[i].handle);
+ memset(btv-page, 0, sizeof(btv-page) * btv-n_pages);
+ btv-n_pages = 0;
+ kfree(btv-page);
+ btv-page = NULL;
}
- return mem;
}
-static void rvfree(void * mem, signed long size)
+static int alloc_dmabuffers(struct bttv *btv)
{
-unsigned long adr, page;
-
- if (mem)
- {
- adr=(unsigned long) mem;
- while (size 0)
-{
- page = kvirt_to_pa(adr);
- mem_map_unreserve(virt_to_page(__va(page)));
- adr+=PAGE_SIZE;
- size-=PAGE_SIZE;
- }
- vfree(mem);
- }
-}
+ unsigned int i;
+ if (btv-page) {
+ printk(KERN_ERR "bttv%d: Double alloc of DMA pages!\n", btv-nr);
+ return 0;
+ }
+ btv-n_pages = (gbuffers * gbufsize) PAGE_SHIFT;
+ if ((gbuffers * gbufsize) % PAGE_SIZE)
+ btv-n_pages++;
-/*
- * Create the giant waste of buffer space we need for now
- * until we get DMA to user space sorted out (probably
Re: No IRQ known for interrupt pin A of device 00:0f.0
Remi Turk wrote: Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ALI15X3: IDE controller on PCI bus 00 dev 78 PCI: No IRQ known for interrupt pin A of device 00:0f.0. Please try using pci=biosirq. test10-pre6 gives this warning? Can you post the output of dump_pirq, from the pcmcia_cs package? (if you don't have it already, http://pcmcia-cs.sourceforge.net/) -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and shrieking like a cheerleader." | -Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] NE2000
pavel rabel wrote: There are three drivers for n2k cards. One is MCA only, one is PCI only, and the then the third one (ne.c) is both ISA and PCI. I think the ISA driver should be ISA only, as is described in Documentation and in config help. So I removed PCI code from ne.c to have ISA only driver. It gets a bit smaller, although I am not sure whether more code can be removed. This change sounds ok to me, if noone else objects. (I added to the CC a bit) I saw that code, and was thinking about doing the same thing myself. ne2k-pci.c definitely has changes which are not included in ne.c, and it seems silly to duplicate ne2000 PCI support. Regards, Jeff P.S. Pavel, for the future, patches made with "diff -u" are preferred. -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and shrieking like a cheerleader." | -Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PATCH 2.4.0.10.6: wrapper.h cleanup
Linus, Attached is a patch against 2.4.0-test10-pre6. I went the ultra-safe route and put parentheses around every macro arg. Compiles ok for me here... If you were wondering if we can remove wrapper.h altogether, IMHO no, there are too many users (43) right now.. Changes: * add lots of parens * line up vm_xxx and mem_map_xxx nicely with tabs * remove unused: wait_handle file_handle inode_handle select_table_handle vm_area_handle connect_wrapper current_got_fatal_signal current_set_timeout module_interruptible_sleep_on module_select_wait module_wake_up module_register_chrdev module_unregister_chrdev module_register_blkdev module_unregister_blkdev inode_get_rdev file_get_flags mem_map_inc_count mem_map_dec_count -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and shrieking like a cheerleader." | -Max Kevin Lawton wrote: Listed in 2.4 headers as: #define mem_map_reserve(p) set_bit(PG_reserved, p-flags) #define mem_map_unreserve(p) clear_bit(PG_reserved, p-flags) ...but should be: #define mem_map_reserve(p) set_bit(PG_reserved, ((p)-flags)) #define mem_map_unreserve(p) clear_bit(PG_reserved, ((p)-flags)) Because of the 'void *' nature of the 2nd parameter to set_bit/clear_bit, the compiler is not picking up this error. Either expression generates a pointer, but not the same values. Might as well also wrap the parameter 'p' with parentheses in the subsequent macros, mem_map_inc_count() and mem_map_dec_count(), for clarity. CC me if needed. I'm not on this list. -Kevin Lawton Plex86 project - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ Index: include/linux/wrapper.h === RCS file: /cvsroot/gkernel/linux_2_4/include/linux/wrapper.h,v retrieving revision 1.1.1.3 diff -u -r1.1.1.3 wrapper.h --- include/linux/wrapper.h 2000/10/22 21:00:45 1.1.1.3 +++ include/linux/wrapper.h 2000/10/30 03:07:00 @@ -1,36 +1,14 @@ #ifndef _WRAPPER_H_ #define _WRAPPER_H_ -#define wait_handle struct wait_queue -#define file_handle struct file -#define inode_handle struct inode -#define select_table_handle select_table -#define vm_area_handle struct vm_area_struct -#define connect_wrapper(x) 0 -#define current_got_fatal_signal() (signal_pending(current)) -#define current_set_timeout(val) current-timeout = val +#define vma_set_inode(v,i) ((v)-vm_inode = (i)) +#define vma_get_flags(v) ((v)-vm_flags) +#define vma_get_pgoff(v) ((v)-vm_pgoff) +#define vma_get_start(v) ((v)-vm_start) +#define vma_get_end(v) ((v)-vm_end) +#define vma_get_page_prot(v) ((v)-vm_page_prot) -#define module_interruptible_sleep_on interruptible_sleep_on -#define module_wake_up wake_up -#define module_select_wait select_wait -#define module_register_chrdev register_chrdev -#define module_unregister_chrdev unregister_chrdev -#define module_register_blkdev register_blkdev -#define module_unregister_blkdev unregister_blkdev +#define mem_map_reserve(p) set_bit(PG_reserved, ((p)-flags)) +#define mem_map_unreserve(p) clear_bit(PG_reserved, ((p)-flags)) -#define inode_get_rdev(i) i-i_rdev - -#define file_get_flags(f) f-f_flags - -#define vma_set_inode(v,i) v-vm_inode = i -#define vma_get_flags(v) v-vm_flags -#define vma_get_pgoff(v) v-vm_pgoff -#define vma_get_start(v) v-vm_start -#define vma_get_end(v) v-vm_end -#define vma_get_page_prot(v) v-vm_page_prot - -#define mem_map_reserve(p) set_bit(PG_reserved, p-flags) -#define mem_map_unreserve(p) clear_bit(PG_reserved, p-flags) -#define mem_map_inc_count(p) atomic_inc((p-count)) -#define mem_map_dec_count(p) atomic_dec((p-count)) -#endif +#endif /* _WRAPPER_H_ */
Re: kmalloc() allocation.
"Richard B. Johnson" wrote: Now, I could set up a linked-list of buffers and use vmalloc() if the buffers were allocated from non-paged RAM. I don't think they are. These buffers must be present during an interrupt. Non-paged RAM? I'm not sure what you mean by that. Both kmalloc and vmalloc allocate pages, but neither will allocate pages that the system will swap out (page out). [vk]malloc pages are always around during an interrupt. Jeff -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and shrieking like a cheerleader." | -Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kmalloc() allocation.
Tigran Aivazian wrote:
On Mon, 30 Oct 2000, Jeff Garzik wrote:
"Richard B. Johnson" wrote:
Now, I could set up a linked-list of buffers and use vmalloc()
if the buffers were allocated from non-paged RAM. I don't think
they are. These buffers must be present during an interrupt.
Non-paged RAM? I'm not sure what you mean by that.
Both kmalloc and vmalloc allocate pages, but neither will allocate pages
that the system will swap out (page out). [vk]malloc pages are always
around during an interrupt.
Jeff, I was going to tell him that but in the previous sentence he was
talking about userspace supplied buffers and those are certainly not
pinned.
Well the problem sounds really strange then. Why are kmalloc/vmalloc
being talked about at all, if we are dealing with userspace-supplied
buffers?
IF copy_to_user is being used here, userspace buffers in kernel space
are pointless. Any userspace buffer supplied to read(2) must by design
be a different buffer than the 2nd arg of copy_to_user. If copy_to_user
is being used, then there is a "copy" taking place...
Richard, if you want to read directly into userspace buffers, kiobufs
are the way to go... If you don't want to ever swap them in and out,
you can mlock(2) them. Or simply allocate the memory in the driver, and
mmap those buffers. Much easier than read(2), and it eliminates any
copy step.
Jeff
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft| dash and shrieking like a cheerleader."
| -Max
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kiobuf/rawio fixes for 2.4.0-test10-pre6
Christoph Hellwig wrote: +Locking down user memory and doing mass storage device IO with it is not +the only purpose of kiobufs. Another use for kiobufs is allowing +user-space mmaping dma memory, e.g in sound drivers. To do so you +need to lock-down kernel virtual memory and refernece it using kiobufs. +The code that does exactly this is not yet in the kernel - get Stephen +Tweedie's kiobuf patchset if you want to use this. Take a look at drivers/sound/via82cxxx_audio.c. How can that mmap be improved by using kiobufs? It seems like there is less overhead to mmap(2) DMA memory the way I do it currently -- without kiobufs... Honestly interested, Jeff -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and shrieking like a cheerleader." | -Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kmalloc() allocation.
"Richard B. Johnson" wrote: On Mon, 30 Oct 2000, Jeff Garzik wrote: "Richard B. Johnson" wrote: Now, I could set up a linked-list of buffers and use vmalloc() if the buffers were allocated from non-paged RAM. I don't think they are. These buffers must be present during an interrupt. Non-paged RAM? I'm not sure what you mean by that. Both kmalloc and vmalloc allocate pages, but neither will allocate pages that the system will swap out (page out). [vk]malloc pages are always around during an interrupt. Jeff Hmm, vmalloc() doesn't seem to have the size limitation. Are you sure that it's present during an interrupt? I can't page-fault during the interrupt. vmalloc'd memory does have a size limitation, though it's larger than kmalloc's limit. AFAIK vmalloc'd memory is a collection of pages remapping in the page tables to be virtually contiguous, implying that it is present during an interrupt. -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and shrieking like a cheerleader." | -Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kiobuf/rawio fixes for 2.4.0-test10-pre6
Christoph Hellwig wrote: On Mon, Oct 30, 2000 at 12:19:21PM -0500, Jeff Garzik wrote: Take a look at drivers/sound/via82cxxx_audio.c. How can that mmap be improved by using kiobufs? I think so - but you need Stephen's kvmap patch, that is in the same patchset the forward-ported fixes are (at ftp://ftp.linux.org.uk/pub/linux/sct/fs/raw-io/) An very nice example is included. Seen it, re-read my question... I keep seeing "audio drivers' mmap" used a specific example of a place that would benefit from kiobufs. The current via audio mmap looks quite a bit like mmap_kiobuf and its support code... except without all the kiobuf overhead. My question from above is: how can the via audio mmap in test10-preXX be improved by using kiobufs? I am not a kiobuf expert, but AFAICS a non-kiobuf implementation is better for audio drivers. (and the via audio mmap implementation is what some other audio drivers are about to start using...) I can clearly see that many applications will find kiobufs quite useful (learned another from alan just now...), but I do not see that audio drivers can benefit from kiobufs at all. Corrections on this fact are requested, as I am hacking audio drivers right now and want to make sure I pick the best course of action for the long term. Regards, Jeff -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and shrieking like a cheerleader." | -Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] NE2000
Paul Gortmaker wrote:
There is no urgency in trying to squeeze a patch like this in the back
door of a 2.4.0 release. For example, there are people out there now
who are using the ne.c driver to run both ISA and PCI cards in the same
box without having to use 2 different drivers. We can wait until 2.5.0
to break their .config file.
IMNSHO this is a bug, though...
Do a diff of the key 8390 interface routines in ne.c, and ne2k-pci.c.
Ignoring the inb_p and outb_p differences, there are distinct advantages
to using ne2k-pci.c on with an NE2000 PCI board.
Since ne2k-pci.c supports all boards ne.c does, and includes some fixes
that ne.c does not, it seems like removing the PCI support in ne.c is a
bug fix change.
It looks like ne2k-pci.c does need a HZ scaling fixing from ne.c
though...
Jeff
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft| dash and shrieking like a cheerleader."
| -Max
--- /g/g/tmp/1 Mon Oct 30 14:22:41 2000
+++ /g/g/tmp/2 Mon Oct 30 14:22:58 2000
@@ -1,60 +1,61 @@
/* Hard reset the card. This used to pause for the same period that a
8390 reset command required, but that shouldn't be necessary. */
-
-static void ne_reset_8390(struct net_device *dev)
+static void
+ne2k_pci_reset_8390(struct net_device *dev)
{
unsigned long reset_start_time = jiffies;
- if (ei_debug 1)
- printk(KERN_DEBUG "resetting the 8390 t=%ld...", jiffies);
+ if (debug 1) printk("%s: Resetting the 8390 t=%ld...",
+ dev-name, jiffies);
- /* DON'T change these to inb_p/outb_p or reset will fail on clones. */
outb(inb(NE_BASE + NE_RESET), NE_BASE + NE_RESET);
ei_status.txing = 0;
ei_status.dmaing = 0;
/* This check _should_not_ be necessary, omit eventually. */
- while ((inb_p(NE_BASE+EN0_ISR) ENISR_RESET) == 0)
- if (jiffies - reset_start_time 2*HZ/100) {
- printk(KERN_WARNING "%s: ne_reset_8390() did not complete.\n",
dev-name);
+ while ((inb(NE_BASE+EN0_ISR) ENISR_RESET) == 0)
+ if (jiffies - reset_start_time 2) {
+ printk("%s: ne2k_pci_reset_8390() did not complete.\n",
+dev-name);
break;
}
- outb_p(ENISR_RESET, NE_BASE + EN0_ISR); /* Ack intr. */
+ outb(ENISR_RESET, NE_BASE + EN0_ISR); /* Ack intr. */
}
/* Grab the 8390 specific header. Similar to the block_input routine, but
we don't need to be concerned with ring wrap as the header will be at
the start of a page, so we optimize accordingly. */
-static void ne_get_8390_hdr(struct net_device *dev, struct e8390_pkt_hdr *hdr, int
ring_page)
+static void
+ne2k_pci_get_8390_hdr(struct net_device *dev, struct e8390_pkt_hdr *hdr, int
+ring_page)
{
- int nic_base = dev-base_addr;
- /* This *shouldn't* happen. If it does, it's the last thing you'll see */
+ long nic_base = dev-base_addr;
- if (ei_status.dmaing)
- {
- printk(KERN_EMERG "%s: DMAing conflict in ne_get_8390_hdr "
+ /* This *shouldn't* happen. If it does, it's the last thing you'll see */
+ if (ei_status.dmaing) {
+ printk("%s: DMAing conflict in ne2k_pci_get_8390_hdr "
"[DMAstat:%d][irqlock:%d].\n",
dev-name, ei_status.dmaing, ei_status.irqlock);
return;
}
ei_status.dmaing |= 0x01;
- outb_p(E8390_NODMA+E8390_PAGE0+E8390_START, nic_base+ NE_CMD);
- outb_p(sizeof(struct e8390_pkt_hdr), nic_base + EN0_RCNTLO);
- outb_p(0, nic_base + EN0_RCNTHI);
- outb_p(0, nic_base + EN0_RSARLO); /* On page boundary */
- outb_p(ring_page, nic_base + EN0_RSARHI);
- outb_p(E8390_RREAD+E8390_START, nic_base + NE_CMD);
+ outb(E8390_NODMA+E8390_PAGE0+E8390_START, nic_base+ NE_CMD);
+ outb(sizeof(struct e8390_pkt_hdr), nic_base + EN0_RCNTLO);
+ outb(0, nic_base + EN0_RCNTHI);
+ outb(0, nic_base + EN0_RSARLO); /* On page boundary */
+ outb(ring_page, nic_base + EN0_RSARHI);
+ outb(E8390_RREAD+E8390_START, nic_base + NE_CMD);
- if (ei_status.word16)
+ if (ei_status.ne2k_flags ONLY_16BIT_IO) {
insw(NE_BASE + NE_DATAPORT, hdr, sizeof(struct e8390_pkt_hdr)1);
- else
- insb(NE_BASE + NE_DATAPORT, hdr, sizeof(struct e8390_pkt_hdr));
+ } else {
+ *(u32*)hdr = le32_to_cpu(inl(NE_BASE + NE_DATAPORT));
+ le16_to_cpus(hdr-count);
+ }
- outb_p(ENISR_RDC, nic_base + EN0_ISR); /* Ack intr. */
+ outb(ENISR_RDC, nic_base + EN0_ISR);/* Ack intr. */
Re: [PATCH] kiobuf/rawio fixes for 2.4.0-test10-pre6
Christoph Hellwig wrote:
On Mon, Oct 30, 2000 at 01:56:07PM -0500, Jeff Garzik wrote:
My question from above is: how can the via audio mmap in test10-preXX
be improved by using kiobufs? I am not a kiobuf expert, but AFAICS a
non-kiobuf implementation is better for audio drivers. (and the via
audio mmap implementation is what some other audio drivers are about to
start using...)
I think the biggest advantage is that you actually get the list of pages
when you perform the mmap instead of doing virt_to_page on every -nopage.
That should speed up the operations on the mmap'ed are a bit.
nopage() is only called when the page is not mapped for the current
process. So it doesn't get called very often. Easy enough to call
virt_to_page at alloc instead of nopage time, though. Patch attached :)
The other strong argument for the kiobuf solution is code-sharing. Instead
of having every (sound) driver playing with the vm, there is one central
place when you use kvmaps.
Actually, I wonder if its even possible for mmap_kiobuf to support audio
-- full duplex requires that both record and playback buffer(s),
theoretically two separate sets of kiobufs, to be presented as one space
(with playback always presented before record). Even if you can do that
with mmap_kiobuf, some audio hardware doesn't support scatter-gather, so
each set of kiobufs must be physically contiguous for each channel.
thinks audio drivers' write(2) should be kiobuf'd, but only for
hardware which supports scatter-gather.
I can't think of any other cases where kiobuf would apply to audio.
Jeff
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft| dash and shrieking like a cheerleader."
| -Max
Index: drivers/sound/via82cxxx_audio.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/sound/via82cxxx_audio.c,v
retrieving revision 1.1.1.6.4.1
diff -u -r1.1.1.6.4.1 via82cxxx_audio.c
--- drivers/sound/via82cxxx_audio.c 2000/10/27 08:21:41 1.1.1.6.4.1
+++ drivers/sound/via82cxxx_audio.c 2000/10/30 19:57:21
@@ -226,6 +226,7 @@
struct via_sgd_data {
dma_addr_t handle;
void *cpuaddr;
+ struct page *page;
};
@@ -626,6 +627,7 @@
if (!chan-sgbuf[i].cpuaddr)
goto err_out_nomem;
+ chan-sgbuf[i].page = virt_to_page (chan-sgbuf[i].cpuaddr);
if (i (VIA_DMA_BUFFERS - 1))
chan-sgtable[i].count = cpu_to_le32 (VIA_DMA_BUF_SIZE |
VIA_FLAG);
@@ -722,6 +724,7 @@
chan-sgbuf[i].handle);
chan-sgbuf[i].cpuaddr = NULL;
chan-sgbuf[i].handle = 0;
+ chan-sgbuf[i].page = NULL;
}
if (chan-sgtable) {
@@ -1717,9 +1720,11 @@
} else if (!wr)
chan = card-ch_in;
+ assert (chan-sgbuf[pgoff].cpuaddr != NULL);
+ assert (chan-sgbuf[pgoff].page != NULL);
assert unsigned long)chan-sgbuf[pgoff].cpuaddr) % PAGE_SIZE) == 0);
- dmapage = virt_to_page (chan-sgbuf[pgoff].cpuaddr);
+ dmapage = chan-sgbuf[pgoff].page;
DPRINTK ("EXIT, returning page %p for cpuaddr %lXh\n",
dmapage, (unsigned long) chan-sgbuf[pgoff].cpuaddr);
get_page (dmapage);
Re: test10-pre7
Keith Owens wrote:
On Mon, 30 Oct 2000 17:01:20 -0500,
Jeff Garzik [EMAIL PROTECTED] wrote:
Keith Owens wrote:
USB still gets unresolved symbols when part is in kernel, part is in
modules and modversions are set. Patch against 2.4.0-test10-pre7, only
affects drivers/usb/Makefile.
Or instead of all that, you could simply call the core init function
from init/main.c...
Does that work when all of usb is a module? The point of __initcall is
to avoid all the conditional code that used to be in main.c.
When all of usb is a module, there are no initcalls.
If you need static initialization for in-kernel init, here is the
shortest solution I can come up with:
/* usb.c **/
int usbcore_init() {...}
#ifdef MODULE
module_init(usbcore_init);
#endif
module_exit(usbcore_exit);
/ main.c **/
extern int usbcore_init (void);
/* ... */
#ifdef CONFIG_USB
usbcore_init();
#endif
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft| dash and shrieking like a cheerleader."
| -Max
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre7
Linus Torvalds wrote: On Tue, 31 Oct 2000, Keith Owens wrote: obj-y is used together with export-objs to split objects into O_OBJS (no export symbol) and OX_OBJS (export symbol). If usbcore.o (multi) is not replaced by its components then usb.o (in export-objs) is not added to OX_OBJS so usb.c gets compiled with the wrong flags which causes incorrect module symbols. Multi's in obj-y have to replaced by their components before being split into O_OBS and OX_OBJS. Your honour, I object. What would be wrong with just splitting it the other way, ie make OX_OBJS be the expanded (but not ordered) list? That should take care of it, no? As an aside: remember you mentioned we should try to go 100% OX_OBJS anyway, eliminating O_OBJS completely... -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and shrieking like a cheerleader." | -Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: / on ramfs, possible?
David Woodhouse wrote: On Mon, 30 Oct 2000, H. Peter Anvin wrote: Pardon?! This doesn't make any sense... The question was: how do switch from the initrd to using the ramfs as /? Using pivot_root should do it (after the pivot, you can of course nuke the initrd ramdisk.) My question is: What do you want to do that for? You can nuke the initrd ramdisk, but you can't drop the rd.c code, or ll_rw_blk.c code, etc. So why not just keep your root filesystem in the initrd where it started off? ramfs size is far more dynamic than rd, and it shrinks as well as grows. Unless you are creating a lot of temporary files and such, though, initrd is indeed a much better solution from many perspectives. (IMHO) Jeff -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and shrieking like a cheerleader." | -Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was: Strange performance behavior of 2.4.0-test9)
Andrew Morton wrote: --- linux-2.4.0-test10-pre5/fs/locks.c Tue Oct 24 21:34:13 2000 +++ linux-akpm/fs/locks.c Sun Oct 29 02:31:10 2000 @@ -125,10 +125,9 @@ #include asm/semaphore.h #include asm/uaccess.h -DECLARE_MUTEX(file_lock_sem); - -#define acquire_fl_sem() down(file_lock_sem) -#define release_fl_sem() up(file_lock_sem) +spinlock_t file_lock_lock = SPIN_LOCK_UNLOCKED; +#define acquire_fl_lock() spin_lock(file_lock_lock); +#define release_fl_lock() spin_unlock(file_lock_lock); It seems like better concurrency could be achieved with reader-writer locks. Some of the lock test routines simply scan the list, without modifying it. -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and screaming like a cheerleader." | -Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre7 (LINK ordering)
Randy Dunlap wrote: With CONFIG_USB=y and all other USB modules built as modules (=m), linking usbdrv.o into the kernel image gives this: drivers/usb/usbdrv.o(.data+0x2f4): undefined reference to Works for me here, .config attached. Local changes, merge error, or similar? I don't have any local USB patches... -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and shrieking like a cheerleader." | -Max config.bz2
Re: [patch] NE2000
Paul,
Ok, here's what I have. Included are your changes, as well as
drivers/net/ne.c:
* use probe_irq_on/off instead of autoirq_xxx (autoirq is going away)
* request_region first thing in ne_probe1, before any hardware
interaction takes place. Eliminates any potential resource races. Also
eliminates a call to check_region.
* Trim trailing whitespace
drivers/net/ne2k-pci.c:
* Merge Becker version 1.02 ne2k-pci.c, which adds forced full duplex
support, and also several cosmetic changes where merely serve to bring
the kernel's ne2k-pci.c closer to Becker's version (ie. makes the diff
smaller).
* Just call BUG() if we don't have a net_device in ne2k_pci_remove_one
* Correct pci_module_init return code handling
As an aside, for 2.5.x, would it be possible to merge all the common
ne2000 code (block_input/output, etc.) from the various ne2k drivers?
As it stands there exists ne.c, ne2.c, ne2k-pci.c, and pcnet_cs.c, all
of which do pretty much the same thing at their core. [and AFAICS, all
but pcnet_cs might easily call a common ne2k library]
Regards,
Jeff
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft| dash and shrieking like a cheerleader."
| -Max
Index: drivers/net/ne.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/ne.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 ne.c
--- drivers/net/ne.c2000/10/31 21:21:49 1.1.1.4
+++ drivers/net/ne.c2000/11/01 13:24:36
@@ -29,21 +29,22 @@
occur after memory is allocated for dev-priv. Deallocated memory
last in cleanup_modue()
Richard Guenther: Added support for ISAPnP cards
-
+Paul Gortmaker : Discontinued PCI support - use ne2k-pci.c instead.
+
*/
/* Routines for the NatSemi-based designs (NE[12]000). */
-static const char *version =
-"ne.c:v1.10 9/23/94 Donald Becker ([EMAIL PROTECTED])\n";
+static const char version1[] =
+"ne.c:v1.10 9/23/94 Donald Becker ([EMAIL PROTECTED])\n";
+static const char version2[] =
+"Last modified Nov 1, 2000 by Paul Gortmaker\n";
#include linux/module.h
-#include linux/config.h
#include linux/kernel.h
#include linux/sched.h
#include linux/errno.h
-#include linux/pci.h
#include linux/isapnp.h
#include linux/init.h
#include linux/delay.h
@@ -70,28 +71,11 @@
/* A zero-terminated list of I/O addresses to be probed at boot. */
#ifndef MODULE
-static unsigned int netcard_portlist[] __initdata = {
+static unsigned int netcard_portlist[] __initdata = {
0x300, 0x280, 0x320, 0x340, 0x360, 0x380, 0
};
#endif
-#ifdef CONFIG_PCI
-/* Ack! People are making PCI ne2000 clones! Oh the horror, the horror... */
-static struct { unsigned short vendor, dev_id; char *name; }
-pci_clone_list[] __initdata = {
- {PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8029,
"Realtek 8029" },
- {PCI_VENDOR_ID_WINBOND2,PCI_DEVICE_ID_WINBOND2_89C940,
"Winbond 89C940" },
- {PCI_VENDOR_ID_COMPEX, PCI_DEVICE_ID_COMPEX_RL2000,
"Compex ReadyLink 2000" },
- {PCI_VENDOR_ID_KTI, PCI_DEVICE_ID_KTI_ET32P2, "KTI
ET32P2" },
- {PCI_VENDOR_ID_NETVIN, PCI_DEVICE_ID_NETVIN_NV5000SC,
"NetVin NV5000" },
- {PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C926, "VIA
82C926 Amazon" },
- {PCI_VENDOR_ID_SURECOM, PCI_DEVICE_ID_SURECOM_NE34,
"SureCom NE34"},
- {0,}
-};
-
-static int probe_pci = 1;
-#endif
-
static struct { unsigned short vendor, function; char *name; }
isapnp_clone_list[] __initdata = {
{ISAPNP_VENDOR('E','D','I'), ISAPNP_FUNCTION(0x0216), "NN NE2000" },
@@ -114,7 +98,9 @@
{"ET-100","ET-200", {0x00, 0x45, 0x54}}, /* YANG and YA clone */
{"COMPEX","COMPEX16",{0x00,0x80,0x48}}, /* Broken ISA Compex cards */
{"E-LAN100", "E-LAN200", {0x00, 0x00, 0x5d}}, /* Broken ne1000 clones */
-{"PCM-4823", "PCM-4823", {0x00, 0xc0, 0x6c}}, /* Broken Advantech MoBo */
+{"PCM-4823", "PCM-4823", {0x00, 0xc0, 0x6c}}, /* Broken Advantech MoBo */
+{"REALTEK", "RTL8019", {0x00, 0x00, 0xe8}}, /* no-name with Realtek chip */
+{"LCS-8834", "LCS-8836", {0x04, 0x04, 0x37}}, /* ShinyNet (SET) */
{0,}
};
#endif
@@ -132,15 +118,9 @@
#define NESM_START_PG 0x40/* First page of TX buffer */
#define NESM_STOP_PG 0x80/* Last page +1 of RX ring */
-/* Non-zero only if the current card is a PCI with BIOS-set IRQ. */
-static unsigned int pci_irq_line = 0;
-
int ne_probe(st
Re: Linux-2.4.0-test10
Andi Kleen wrote: On Tue, Oct 31, 2000 at 08:55:13PM +, Alan Cox wrote: What about the fact anyone can crash a box using ioctls on net devices and waiting for an unload - was this fixed ? The ioctls of network devices are generally unsafe on SMP, because they run with kernel lock dropped now but are mostly not safe to do so. Wrong. The BLK is dropped in sock_ioctl, but struct netdevice::do_ioctl is called with rtnl_lock held: net/core/dev.c: rtnl_lock(); ret = dev_ifsioc(ifr, cmd); rtnl_unlock(); Therefore for 2.4.x, our concern is whether a particular net driver needs further SMP protection internally, or if rtnl_lock (a semaphore, not a spinlock) is sufficient. Jeff -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and shrieking like a cheerleader." | -Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Where did kgcc go in 2.4.0-test10 ?
"J . A . Magallon" wrote:
On Thu, 02 Nov 2000 02:12:31 Jeff Garzik wrote:
You're not changing 2.4.x to use kgcc, are you? It seems to be working
fine under gcc 2.95.2+fixes...
What means "using kgcc" ?
Alan has a script in 2.2.x which attempts to find the best compiler for
building your kernel. It looks for kgcc first, IIRC.
Alan's message wasn't clear, but it seemed to imply that a patch to add
this script to 2.4.x would be submitted to Linus. gcc 2.95.2 is a bit
smarter about some things, and I definitely prefer using that compiler.
I also prefer fixing 2.4.x kernel-compiler bugs rather than defaulting
people to an older compiler.
Think of packages like ALSA drivers grepping or analizing the kernel Makefile
to find that options are -fomit-frame-pointer -malign= and so on.
And that options can change from version to version of gcc.
Simpler: build a script (what kgcc is). An external module package, use kgcc.
This is a totally separate issue. Choice of compiler is but one of many
variables. We need the build system to export all these variables, and
ALSA and other external packages will then pick up those settings for
use in their own builds. See for example
http://gtf.org/garzik/kernel/files/patches/2.4/2.4.0-test9/external-modules-2.4.0.9.8.patch.gz
Jeff
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft| dash and shrieking like a cheerleader."
| -Max
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Via audio driver update
TimO wrote: Jeff Garzik wrote: An update of the Via audio driver for Linux 2.4.x kernels has been posted at http://gtf.org/garzik/drivers/via82cxxx/ Hi Jeff, Somewhere between v1.1.8 and 1.1.10 (I haven't tried 1.1.9), the output Please grab 1.1.14, there were a number of bug fixes since 1.1.10. You can get this version in the recently-released 2.4.0-test10 kernel, or download from http://sourceforge.net/projects/gkernel/ Thanks, Jeff -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and shrieking like a cheerleader." | -Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Where did kgcc go in 2.4.0-test10 ?
[EMAIL PROTECTED] wrote: What I haven't seen yet is an explanation of why kgcc can't be used for compiling *everything* It can. But if we are talking about 2.4.x, I want my kernel built with the improved gcc-2.95.2 -- unless there is a good reason not to do so -- and kgcc is egcs-1.1.2 not gcc-2.95.2 on my system. and why another compiler even needs to be installed. Cuz the kernel should not dictate the compiler choice for the entire distro. -- Jeff Garzik | "Mind if I drive?" -Sam Building 1024 | "Not if you don't mind me clawing at the MandrakeSoft| dash and shrieking like a cheerleader." | -Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10 won't boot
Hans-Joachim Baader wrote:
test10, compiled with gcc 2.95.2, won't boot on one of my machine.
It stops after the "now booting the kernel" message. Yes, I have
configured Virtual Terminal and VGA text console.
00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 04)
00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 04)
00:03.0 Bridge: Acer Laboratories Inc. [ALi] M7101 PMU
00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin
IV] (rev c3)
00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c1)
Does it boot with the attached patch?
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft| dash and shrieking like a cheerleader."
| -Max
Index: drivers/ide/ide-pci.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/ide/ide-pci.c,v
retrieving revision 1.1.1.6
retrieving revision 1.1.1.6.6.1
diff -u -r1.1.1.6 -r1.1.1.6.6.1
--- drivers/ide/ide-pci.c 2000/10/27 07:45:53 1.1.1.6
+++ drivers/ide/ide-pci.c 2000/10/31 22:43:32 1.1.1.6.6.1
@@ -528,10 +528,7 @@
autodma = 1;
#endif
-#if 1 /* what do do with this useful tool ??? */
- if (pci_enable_device(dev))
- return;
-#endif
+ pci_enable_device(dev);
check_if_enabled:
if (pci_read_config_word(dev, PCI_COMMAND, pcicmd)) {
Re: vesafb doesn't work in 240t10?
Narancs 1 wrote: I used to start vesafb like this: /etc/lilo.conf: vga=317 I want to start the kernel in 1024x768 16 bit How to do it? I've read Doc*/fb/vesafb.txt vga takes a decimal number, but the number in vesafb.txt is hexidecimal. Let us convert 0x317 to decimal: [jgarzik@rum linux_2_4]$ perl -e 'printf "%d\n", 0x317;' 791 So, use "vga=791" in your lilo.conf. -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poll and OSS API
"Richard B. Johnson" wrote: The specification is bogus and should be fixed. select() is not a function that was designed to start/stop anything. Writing a specification to qualify some particular implementation's side-affects is patently wrong. ioctl() was designed to control things. You should contact a committee member and get it fixed. Further, all should fail to write code to such a so-called specification. If specifications are allowed to be written like this, soon the lights will go out when you open a file. This cannot be allowed. Don't support such diatribe. We are stuck with the current OSS API, including warts aplenty, until ALSA replaces it. (but even then OSS will live on in infamy...) Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poll and OSS API
Thomas Sailer wrote: The OSS API (http://www.opensound.com/pguide/oss.pdf, page 102ff) specifies that a select _with the sounddriver's filedescriptor set in the read mask_ should start the recording. Implementing this is currently not possible, as the driver does not get to know whether the application had the filedescriptor set in the select call. Similarily for poll, the driver does not get the caller's events. Well, it's only a problem for full duplex :) If you are write-only in poll(), read doesn't apply. Read-only in poll(), and you start DMA. For full duplex... my Via driver starts DMA'ing. That was my interpretation of the spec. I don't think this is all that important though, because it's that way for more than a year and the first complaint reached me yesterday. What was the complaint? FWIW I highly recommend Rui Sousa's oss-test stuff. Check out the "emu10k1" module from Creative's CVS server, and look in the emu10k1/utils/oss-test directory. Regards, Jeff Creative CVS info: export CVSROOT=:pserver:[EMAIL PROTECTED]:/usr/local/cvsroot echo note - password is 'cvsguest' -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: non-gcc linux?
"D. Hugh Redelmeier" wrote: Being GCC-dependent is rather parochial. Being GCC-version-dependent is downright embarrassing. Summary: spurious GCC-isms are a bad thing. Summary: You have no clue about kernel-gcc interdependencies and issues. - use ISO C 89 when possible (without undue pain) - use IOS C 99 when advantageous - use GCCisms for the remainder of appropriate things BUT embed them in macros defined in header so that they can be systematically replaced. Using these macros probably makes the code more readable. Use of any GCCism should probably be justified in commentary. This would improve the code *and* make it more portable. Why does this improve the code? It gets slower and uglier and more difficult to maintain. Why does this make the code more portable? gcc is already highly portable, and so it the kernel. This too gains us nothing. Removing gcc-isms without a pragmatic reason -- and no, ISO C compliancy is not a pragmatic reason -- is silly, extra work for little or no value. Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 255.255.255.255 won't broadcast to multiple NICs
Rob Landley wrote: Under 2.2.16, broadcast packets addressed to 255.255.255.255 do not go out to all interfaces in a machine with multiple network cards. They're getting routed out the default gateway's interface instead. Are the network cards on the same network? -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.0.10: Update hotplug
David Brownell wrote: - Changing /sbin/hotplug invocations ... now it can only support "add" and "del" events. (USB now uses "add" and "remove", though "remove" doesn't try to do anything yet.) This removes the intended flexibility whereby different subsystems (such as networking) can define their own events. Wrong. Different subsystems -do- define their own events. However, different subsystems should use the same verbs for the same actions. We need consistency where possible. - "/sbin/hotplug net ..." replaced by "/sbin/network", with two custom event types. Hotplug device insertion and network interface addition/removal are two fundamentally different things. Further, my code purposefully does not wrap CONFIG_HOTPLUG around the /sbin/network code, because /sbin/network has utility outside the domain of hotplug. Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
David Ford wrote: Alan Cox wrote: 10. To Do But Non Showstopper * PCMCIA/Cardbus hangs (Basically unusable - Hinds pcmcia code is reliable) + PCMCIA crashes on unloading pci_socket The pci_socket crash is fixed it seems Not unless it was fixed in test10 release. I have a PC LinkSys dual 10/100 and 56K card that will kill the machine if you physically pull it out no matter what cardctl/module steps are taken. It uses the ne2k and serial drivers. Part of that might be that serial doesn't support hotplug without patching. -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
[EMAIL PROTECTED] wrote: Hello! that does hardware register access without protecting against interrupts or checking if the interface is up. This issue is not that issue. It is separate issue and in fact it is private problem of driver and its author, what is safe, what is not safe. F.e. I see no cathastrophe even if MII registers are accessed without any protections. Diag utilities do this from user space. 8)8) It depends on the hardware... For the ioctl-only case, you are correct. rtnl_lock protects us there. But when the timer and ioctl both call mdio_xxx, you need SMP protection, otherwise you corrupt the multi-step MDIO read/write found in many drivers. IMNSHO the timer routines found in net drivers should all be converted to kernel threads. There are too many limitations placed on you by timers. de4x5 is probably also buggy in regard to this. de4x5 is hopeless. I added nice comment in softnet to it. Unfortunately it was lost. 8) Andi, neither you nor me nor Alan nor anyone are able to audit all this unnevessarily overcomplicated code. It was buggy, is buggy and will be buggy. It is inavoidable, as soon as you have hundreds of drivers. de4x5 is becoming EISA-only in 2.5.x too, since its PCI support is duplicated now in tulip driver. Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
Alan Cox wrote: * Check all devices use resources properly (Everyone now has to use request_region and check the return since we no longer single thread driver inits in all module cases. Also memory regions are now requestable and a lot of old drivers dont know this yet. -- Alan Cox) Folks have done most of the common drivers. So its not really a show stopper now just a 'clean up' s/check_region/request_region/ is moving along, but there is still a ways to go. I agree with "folks have done most of the common drivers" I have seen very few additions of request_mem_region, though. * Issue with notifiers that try to deregister themselves? (lnz; notifier locking change by Garzik should backed out, according to Jeff) and according to Alan Fixed for a couple versions now. * Spin doing ioctls on a down netdeice as it unloads == BOOM (prumpf, Alan Cox) Possible other net driver SMP issues (andi kleen) Turns out to be safe according to Jeff and ANK To avoid Andi confusing the issue :) ... 1) The first item listed does not exist 2) the second item listed exists -- many net drivers are not SMP. They are most of the way there, but there are still small races which exist in some drivers. Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
Bill Wendling wrote: Also sprach [EMAIL PROTECTED]: } de4x5 is probably also buggy in regard to this. } } de4x5 is hopeless. I added nice comment in softnet to it. } Unfortunately it was lost. 8) } } Andi, neither you nor me nor Alan nor anyone are able to audit } all this unnevessarily overcomplicated code. It was buggy, is buggy } and will be buggy. It is inavoidable, as soon as you have hundreds } of drivers. } If they are buggy and unsupported, why aren't they being expunged from the main source tree and placed into a ``contrib'' directory or something for people who may want those drivers? de4x5 is stable. Its hopeless to add stuff to it, or try to any fix of the (IMHO small) issues, but its fine as is. For maintenance issues, its PCI support will be eliminated in 2.5.x because it is a duplicate of support in the tulip driver. Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
Andi Kleen wrote: de4x5 is stable, but tends to perform badly under load, mostly because it doesn't use rx_copybreak and overflows standard socket buffers with its always MTU sized skbuffs. One of the reasons that de4x5 isn't gone already is that I get reports that de4x5 performs better than the tulip driver for their card. Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test9
"Richard B. Johnson" wrote:
I have, again, tried to use a new kernel. It is linux-2.4.0-test9
Apparently a newer version was just put up while downloading this
one. This is possible because it took a day to download it );
If you could download patch-2.4.0-test10, and try out test10-final, that
would be awesome...
(3) With the new kernel, I can't access screen memory anymore. When
testing software drivers for hardware that I don't have, I usually use
the screen-regen buffer to emulate the shared memory window.
Here is a snippet of code:
//info-mem = 0xb8000 what they actually are
//info-mem_len = 0x4000
if((info-vxi_iomem = ioremap(info-mem, info-mem_len)) == NULL)
{
printk(KERN_ALERT "%s: Can't allocate shared memory\n", devname);
(void)unregister_chrdev(info-major, info-dev);
kfree(info-tmp_buf);
kfree(info);
return -ENOMEM;
}
info-vxi_base = (UNIV *) bus_to_virt(UL info-vxi_iomem);
||
This pointer should point to the beginning of the screen buffer.
It always has before.
When accessing this from a module, I get;
Unable to handle kernel paging requist at virtual address 800b8304.
bug 1) ioremap returns a cookie, not a bus address. therefore, calling
ioremap output to bus_to_virt is incorrect.
bug 2) what are you doing with vxi_base? I don't have the rest of your
code here, but I'm willing to bet that you are directly de-referencing
memory, instead of using {read,write}[bwl] / memcpy_{to,from}io. Read
linux/Documentation/IO-mapping.txt for more info.
(4) More name-space polution. Somebody added another macro called
get_page(). When, if ever, will we start using the good-old
convention of defining macros in upper-case?
The name-space polution has really gotten out-of-hand. You
can't write code using ordinary symbol names anymore. You
need to make variables have names like:
int LoopCounterForOutSideLoop;
char *UserInputAndOutputBufferForWednesday;
This is NotGood(tm)
I guess it should probably have been named "page_get"? I looked through
'nm vmlinux' output at the public symbols, and there are definitely a
ton of them.
Though it is definitely C convention that macros are in all uppercase
(gcc is good about this), the kernel has never really been good about
that...
Jeff
--
Jeff Garzik | Dinner is ready when
Building 1024 | the smoke alarm goes off.
MandrakeSoft| -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
Alan Cox wrote: Not unless it was fixed in test10 release. I have a PC LinkSys dual 10/100 and 56K card that will kill the machine if you physically pull it out no matter what cardctl/module steps are taken. It uses the ne2k and serial drivers. Part of that might be that serial doesn't support hotplug without patching. Linksys rings a bell with an outstandng 2.2 lockup on pcmcia. I think this might be a driver bug ? On 2.2.x, possibly. On 2.4.x: 1) insert CardBus serial or modem card, that reports itself as PCI_CLASS_COMMUNICATION_SERIAL. 2) modprobe serial, it sees and registers the PCI serial port. 3) eject card, which serial.c doesn't presently notice. ... Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)
David Ford wrote: The odd part is that it used to work "way back when". Was this just a fluke? That may have been back in the legacy days. Ejecting ne2k should be ok as long as you are using ne2k-pci or pcnet_cs. Eject serial looks like bad news unless you are using serial_cs (which is impossible at the moment, AFAIK). -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test9
"Richard B. Johnson" wrote:
On Fri, 3 Nov 2000, Jeff Garzik wrote:
"Richard B. Johnson" wrote:
(3) With the new kernel, I can't access screen memory anymore. When
testing software drivers for hardware that I don't have, I usually use
the screen-regen buffer to emulate the shared memory window.
Here is a snippet of code:
//info-mem = 0xb8000 what they actually are
//info-mem_len = 0x4000
if((info-vxi_iomem = ioremap(info-mem, info-mem_len)) == NULL)
{
printk(KERN_ALERT "%s: Can't allocate shared memory\n", devname);
(void)unregister_chrdev(info-major, info-dev);
kfree(info-tmp_buf);
kfree(info);
return -ENOMEM;
}
info-vxi_base = (UNIV *) bus_to_virt(UL info-vxi_iomem);
||
This pointer should point to the beginning of the screen buffer.
It always has before.
When accessing this from a module, I get;
Unable to handle kernel paging requist at virtual address 800b8304.
bug 1) ioremap returns a cookie, not a bus address. therefore, calling
ioremap output to bus_to_virt is incorrect.
So explain?? What do you mean a cookie?
ioremap returns a value that ideally should only be passed on to other
MMIO functions: iounmap, readb, readw, readl, writeb, writew, writel,
memcpy_toio, memcpy_fromio, etc.
Think of ioremap as returning a token which can be passed back into the
above list of functions. You should never dereference ioremap'd memory
directly...
bug 2) what are you doing with vxi_base? I don't have the rest of your
code here, but I'm willing to bet that you are directly de-referencing
memory, instead of using {read,write}[bwl] / memcpy_{to,from}io. Read
linux/Documentation/IO-mapping.txt for more info.
Nope. It's copied, using memcpy_to/from_io, into a kmalloc()ed buffer.
As long as you are passing ioremap'd address to memcpy_to/from_io,
that's ok.
However, there is a section, of 0x800 dwords that are accessed as
registers (directly).
This will be a real bitch, if necessary, with the real device because
I have to reference 0x800 dwords as device registers.
And if I can't do that, I am totally screwed, and will have to stay
with a version that allows it. I can just imagine code that references
these registers using an obscure macro. It just won't be maintainable
and I don't intend to live with the code for the product lifetime.
Well, ioremap returns a virtual address, which is directly accessible to
the local CPU. Maybe (as a hack) you can completely ignore what I said
above, and directly de-reference the ioremap'd memory. ie. eliminate
info-vxi_base altogether.
But if you are going to eliminate info-vxi_base, it seems like that
would flush out all direct de-refs, whether they are buried in an
obscure macro or not. And if you find all that crap, you might as well
use readb/writel at that point...
info-registers[0x7FF] = newvalue;
becomes
writel(newvalue, info-registers[0x7FF]);
and
regval = info-registers[0x7FF];
becomes
regval = readl(info-registers[0x7FF]);
--
Jeff Garzik | Dinner is ready when
Building 1024 | the smoke alarm goes off.
MandrakeSoft| -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Oops when loading 3c509-module in test10
Håvard Garnes wrote:
This occurs when the 3c509-module is being loaded at startup, and in
/proc/modules it is listed as (initialising). It it worth mentioning
that I have two 3c509-cards in my computer. This worked in test8.
Oops. This is one of the newer (and better) ISA modules, which actually
does allocate its device structure correctly.
Please apply this patch...
Jeff
--
Jeff Garzik | Dinner is ready when
Building 1024 | the smoke alarm goes off.
MandrakeSoft| -/usr/games/fortune
Index: linux_2_4/drivers/net/3c509.c
diff -u linux_2_4/drivers/net/3c509.c:1.1.1.5 linux_2_4/drivers/net/3c509.c:1.1.1.3
--- linux_2_4/drivers/net/3c509.c:1.1.1.5 Tue Oct 31 13:21:47 2000
+++ linux_2_4/drivers/net/3c509.c Sun Oct 22 13:29:58 2000
@@ -434,6 +436,13 @@
/* Free the interrupt so that some other card can use it. */
outw(0x0f00, ioaddr + WN0_IRQ);
found:
+ if (dev == NULL) {
+ dev = init_etherdev(dev, sizeof(struct el3_private));
+ if (dev == NULL) {
+ release_region(ioaddr, EL3_IO_EXTENT);
+ return -ENOMEM;
+ }
+ }
memcpy(dev-dev_addr, phys_addr, sizeof(phys_addr));
dev-base_addr = ioaddr;
dev-irq = irq;
Re: Poll and OSS API
Linus Torvalds wrote: On Thu, 2 Nov 2000, Thomas Sailer wrote: The OSS API (http://www.opensound.com/pguide/oss.pdf, page 102ff) specifies that a select _with the sounddriver's filedescriptor set in the read mask_ should start the recording. So fix the stupid API. The above is just idiocy. We're pretty much stuck with the API, until we look at merging ALSA in 2.5.x. Broken API or not, OSS is a mature API, and there are spec-correct apps that depend on this behavior. (FWIW, ALSA nicely marginalizes its OSS support into a single module, so that ALSA drivers aren't affected by OSS' ugliness) Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Sample device driver - 2.2 and 2.4 support?
Richard A Nelson wrote: I've been assigned a device driver that uses the old (2.0) PCI support APIs - and is still working on 2.2. I need to get this driver working on 2.2 and 2.4, I'm assuming I'll need to go switch to the newer PCI stuff - but am curious about the toleration support in later 2.2 kernels; is it complete enough that I can migrate to 2.4, and still compile on 2.2? You can still use the 2.0.x PCI functions on 2.4.x. They are slower than the 'struct pci_dev' versions of the functions, because each pcibios_xxx call incurs a call to pci_find_slot(). The device: 1-2 DMA 1 IRQ The driver: mkalloc __get_free_pages virt_to_bus request_irc wake_up The driver has similiar functionality to a sound card: Send/Receive (possibly large) data to device via DMA (page fixing, etc) Is there a cononical example (esp. wrt 2.2 - 2.4 changes) I should look at ? That depends on both the changes and your driver... Every driver is different, so nothing is really canonical WRT driver API changes. If your driver is similar to a sound card, then look at drivers/sound/*.c ... Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poll and OSS API
Linus Torvalds wrote: On Sat, 4 Nov 2000, Jeff Garzik wrote: So fix the stupid API. The above is just idiocy. We're pretty much stuck with the API, until we look at merging ALSA in 2.5.x. Broken API or not, OSS is a mature API, and there are spec-correct apps that depend on this behavior. Considering that about 100% of the sound drivers do not follow that particular API damage anyway (they can't, as has been pointed out: the driver doesn't even receive enough information to be _able_ to follow the documented API), I doubt that there are all that many programs that depend on it. Yes, some drivers apparently _try_ to follow the spec to some degree, but we should just change the documentation asap. Fine with me. Allows for some driver simplification, and it only applies to the lesser-used recording stuff at any rate. Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poll and OSS API
Linus Torvalds wrote: Considering that about 100% of the sound drivers do not follow that particular API damage anyway (they can't, as has been pointed out: the driver doesn't even receive enough information to be _able_ to follow the documented API), I doubt that there are all that many programs that depend on it. While I'm thinking about the subject.. even after updating the API, the drivers still need to know what events to poll for. AFAIK 99% of the drivers currently select to block on read/write/read+write based on file-f_mode, which works, but isn't really correct. Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: USB init order dependencies.
Russell King wrote:
Dunlap, Randy writes:
David is entitled to his opinion (IMO).
And I dislike this patch, as he and I have already discussed.
Short of fixing the link order, I like Jeff's suggestion
better (if it actually works, that is): go back to the
way it was a few months ago by calling usb_init()
from init/main.c and making the module_init(usb_init);
in usb.c conditional (#ifdef MODULE).
However, that breaks the OHCI driver on ARM. Unless we're going to start
putting init calls back into init/main.c so that we can guarantee the order
of init calls which Linus will not like, you will end up with a lot of ARM
guys complaining.
Linus, your opinion would be helpful at this point.
Back when some of the initial USB initcall stuff started appearing,
there were similar discussions, similar problems, and similar
solutions. I was also wondering how fbdev (which needs to give you a
console ASAP) would work with initcalls, etc. At the time (~6 months
ago?), Linus' opinion was basically "if the link order hacking starts to
get ugly, just put it in init/main.c" So, Randy really should be
calling the quoted text above "Linus' suggestion" ;-)
Putting a call into init/main.c isn't a long term solution, but it
should get us there for 2.4.x... init/main.c is also the best solution
for ugly cross-directory link order dependencies. I would say the link
order of foo.o's in linux/Makefile is the most delicate/fragile of all
the Makefiles... touching linux/Makefile link order this close to 2.4.0
is asking for trouble. Compared to that, adding a few lines to
init/main.c isn't so bad.
IMHO,
Jeff
--
Jeff Garzik | Dinner is ready when
Building 1024 | the smoke alarm goes off.
MandrakeSoft| -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test9
Ingo Oeser wrote: On Fri, Nov 03, 2000 at 10:12:31PM -0500, Jeff Garzik wrote: But if you are going to eliminate info-vxi_base, it seems like that would flush out all direct de-refs, whether they are buried in an obscure macro or not. And if you find all that crap, you might as well use readb/writel at that point... info-registers[0x7FF] = newvalue; becomes writel(newvalue, info-registers[0x7FF]); and regval = info-registers[0x7FF]; becomes regval = readl(info-registers[0x7FF]); Wasn't this the clean and recommended interface anyway? (ref. IO-mapping.txt:150) Absolutely! We are talking about an old driver, though, and due consideration has to be given to not breaking existing code :) Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.4-test10: new wrapper.h brakes drivers
David Hammerton wrote: Hi, i just installed the latest kernel (2.4-test10). On recompilation of my "Nvidia" kernel drivers (for geforce 2 3d video support in linux), it failed linking to "mem_map_inc_count" (and dec_count). Im not much of a programmer, but to get it working all i had to do was to add to '/usr/src/linux/include/linux/wrapper.h': /*the patch*/ #define mem_map_inc_count(p)atomic_inc((p-count)) #define mem_map_dec_count(p)atomic_dec((p-count)) /*end patch*/ yes, you'll notice i ripped this out of the older kernels.. good luck in finding an alternative, or just leave it in, or whatever. if the nvidia kernel shell needs to support multiple kernel versions, they should add #ifndef mem_map_inc_count ...compat code... #endif -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Who will be responsible for 2.4.0 patches?
Thomas Molina wrote: I want to make a minor change to the sound drivers Makefile for compiling pas16 as well as a modification to the documentation file. I'm told that since it is not a bugfix it needs to wait for post 2.4 final release. Send me the patch... if its minor and useful, maybe it can go in. Otherwise, yeah, you'll have to wait until 2.4.0 is released... Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Locking Between User Context and Soft IRQs in 2.4.0
"Hen, Shmulik" wrote: We are trying to port a network driver from 2.2.x to 2.4.x and have some question regarding locks. According to the kernel locking HOWTO, we have to take extra care when locking between user context threads and BH/tasklet/softIRQ, so we learned (the hard way ;-) that when running the ioctl system call from an application we should use spin_lock/unlock_bh() and not spin_lock/unlock() inside dev-do_ioctl(). That is not necessarily true. If you have timers or tasklets going, sure. I prefer kernel threads for a lot of tasks nowadays, because you only have two cases for locking -- user and interrupt -- and you can sleep all you want to in a kernel thread. * What about the other entry points implemented in net_device ? I wrote the attached doc, after tracing through the code. It has not been reviewed yet so it is not canonical, but hopefully it is informative... * We've got dev-get_stats, dev-set_mac_address, dev-set_mutlicast_list and others that are all called from running 'ifconfig' which is an application. Are they considered user context too ? You are inside a spinlock in get_stats, so you cannot sleep. But you can sleep in set_multicast_list. Not sure about set_mac_address. * What about dev-open and dev-stop ? Sleep all you want, we'll leave the light on for ya. * We figured that dev-hard_start_xmit() and timer callbacks are not considered user context, but how can I find out if they are being run as SoftIRQ or as tasklets or as Bottom Halves ? (their different definitions require different types of protections) I'm not sure about the context from which hard_start_xmit is called... Its inside a spinlock, so you shouldn't be sleeping. timers are unique unto themselves... but you lock against them using spin_lock_bh outside the timer, and spin_lock inside the timer. wrap entire operations from top to bottom. For example, our dev-hard_start_xmit() will have a spin_lock() at the beginning and a spin_unlock() at the end of the function. Why? dev-xmit_lock is obtained before dev-hard_start_xmit is called, and released after it returns. * What about other calls to the kernel ? can the running thread be switched out of context when calling kernel entries and not be switched back in when they finish ? should I beware of deadlocks in such case ? You should always beware of deadlocks! Jeff -- Jeff Garzik | Dinner is ready when Building 1024 | the smoke alarm goes off. MandrakeSoft| -/usr/games/fortune struct net_device synchronization rules === dev-open: Locking: Inside rtnl_lock() semaphore. Sleeping: OK dev-stop: Locking: Inside rtnl_lock() semaphore. Sleeping: OK dev-do_ioctl: Locking: Inside rtnl_lock() semaphore. Sleeping: OK dev-get_stats: Locking: Inside dev_base_lock spinlock. Sleeping: NO dev-hard_start_xmit: Locking: Inside dev-xmit_lock spinlock. Sleeping: NO[1] dev-tx_timeout: Locking: Inside dev-xmit_lock spinlock. Sleeping: NO[1] dev-set_multicast_list: Locking: Inside dev-xmit_lock spinlock. Sleeping: NO[1] NOTE [1]: On principle, you should not sleep when a spinlock is held. However, since this spinlock is per-net-device, we only block ourselves if we sleep, so the effect is mitigated.
