Jon Forsberg <[EMAIL PROTECTED]> écrit :
> I have an Surecom EP-320X-S Ethernet adapter which apparently uses a
> Myson MTD-8xx chip. It works well with the "fealnx" driver (labeled
> "Myson MTD-8xx PCI Ethernet support" in kernel config) except for one thing:
> After a while in use it stops
Jon Forsberg [EMAIL PROTECTED] écrit :
I have an Surecom EP-320X-S Ethernet adapter which apparently uses a
Myson MTD-8xx chip. It works well with the fealnx driver (labeled
Myson MTD-8xx PCI Ethernet support in kernel config) except for one thing:
After a while in use it stops working and
[EMAIL PROTECTED] <[EMAIL PROTECTED]> ecrit :
[...]
> (i) The kernel has high visibility, and work on the kernel
> [even if only on the Documentation subdirectory] has high "prestige".
> As a consequence, parts of the kernel tree are kept much better
> up-to-date than documentation found
[EMAIL PROTECTED] [EMAIL PROTECTED] ecrit :
[...]
(i) The kernel has high visibility, and work on the kernel
[even if only on the Documentation subdirectory] has high prestige.
As a consequence, parts of the kernel tree are kept much better
up-to-date than documentation found elsewhere.
Why
Haseeb Budhani <[EMAIL PROTECTED]> ecrit :
[...]
> I have a fairly quick one: Is there an ioctl flag/call which can be used
> to find out the "type" of the interface being used ?
See net/core/dev.c:dev_ifsioc + SIOCGIFHWADDR + include/linux/if_arp.h
+
Haseeb Budhani [EMAIL PROTECTED] ecrit :
[...]
I have a fairly quick one: Is there an ioctl flag/call which can be used
to find out the type of the interface being used ?
See net/core/dev.c:dev_ifsioc + SIOCGIFHWADDR + include/linux/if_arp.h
+
Emmanuel Varagnat <[EMAIL PROTECTED]> écrit :
> I need to had a header to the data in the sk_buff.
> But what to do if there is no enough space left at the head ?
I assume "alloc+copy" isn't the expected answer, is it ?
> I saw skb_copy_expand, but it gives me a new sk_buff. Is there
> a way to
Emmanuel Varagnat [EMAIL PROTECTED] écrit :
I need to had a header to the data in the sk_buff.
But what to do if there is no enough space left at the head ?
I assume alloc+copy isn't the expected answer, is it ?
I saw skb_copy_expand, but it gives me a new sk_buff. Is there
a way to expand
[EMAIL PROTECTED] <[EMAIL PROTECTED]> écrit :
> Where do I get this basic info on ATAPI? Will I benefit from the IDE
> standards document? Where can I get that?
www.t13.org
ww.google.com
It's time consuming but you may see something emerging from your
work in a few monthes if you sacrifice your
[EMAIL PROTECTED] [EMAIL PROTECTED] écrit :
Where do I get this basic info on ATAPI? Will I benefit from the IDE
standards document? Where can I get that?
www.t13.org
ww.google.com
It's time consuming but you may see something emerging from your
work in a few monthes if you sacrifice your
Alan Cox <[EMAIL PROTECTED]> écrit :
[...]
> o Add missing locking to stradis driver (me)
- unbalanced returns after down();
- 1770: if the initial version isn't racy with saa7146_irq (line 534), this
one is equivalent and shorter.
init_saa7146:2185
if ((saa->dmadebi =
Alan Cox [EMAIL PROTECTED] écrit :
[...]
o Add missing locking to stradis driver (me)
- unbalanced returns after down();
- 1770: if the initial version isn't racy with saa7146_irq (line 534), this
one is equivalent and shorter.
init_saa7146:2185
if ((saa-dmadebi =
Marcus Meissner <[EMAIL PROTECTED]> ecrit :
[...]
> if( request_region(iobase, 256, card_names[card_type]) == NULL )
> {
> printk(KERN_WARNING "maestro: can't allocate 256 bytes I/O at
>0x%4.4x\n", iobase);
> - return 0;
> - }
> -
> - /* this was
Marcus Meissner [EMAIL PROTECTED] ecrit :
[...]
if( request_region(iobase, 256, card_names[card_type]) == NULL )
{
printk(KERN_WARNING maestro: can't allocate 256 bytes I/O at
0x%4.4x\n, iobase);
- return 0;
- }
-
- /* this was tripping up
The patch makes the driver use the dma mapping interface.
It compiles.
No adequate adapter for testing.
--- linux-2.4.4-ac11/drivers/net/fealnx.c Sat May 19 14:36:37 2001
+++ linux-2.4.4-ac11/drivers/net/fealnx.c Sun May 20 15:53:26 2001
@@ -46,6 +46,8 @@ static int
Richard B. Johnson <[EMAIL PROTECTED]> ecrit :
[...]
> when the hardware I/O is used. This shows that the network code, alone,
> cannot be improved very much to provide an improvement in throughput.
It shows that cached code performs well with ~0us latency device/memory.
Networking is about
Richard B. Johnson [EMAIL PROTECTED] ecrit :
[...]
when the hardware I/O is used. This shows that the network code, alone,
cannot be improved very much to provide an improvement in throughput.
It shows that cached code performs well with ~0us latency device/memory.
Networking is about latency
[EMAIL PROTECTED] <[EMAIL PROTECTED]> ecrit :
> Is there any way of issuing a PCI reset (safely) without rebooting? I am
No.
[...]
> without having to go through the hassle of a reboot. Is this wishful
> thinking?
Yes. Try to narrow the circunstances under which the device locks and avoid
[EMAIL PROTECTED] [EMAIL PROTECTED] ecrit :
Is there any way of issuing a PCI reset (safely) without rebooting? I am
No.
[...]
without having to go through the hassle of a reboot. Is this wishful
thinking?
Yes. Try to narrow the circunstances under which the device locks and avoid
them at
Eric S. Raymond <[EMAIL PROTECTED]> ecrit :
> Francois Romieu <[EMAIL PROTECTED]>:
[...]
> > Somebody will have less work [*] [ ]
>
> Yes, anybody trying to figure out how to get a fix made.
Provided it's kept up-to-date. I.e. it calls for some tools (and
Eric S. Raymond <[EMAIL PROTECTED]> ecrit :
[...]
> One of the problems this `overdesign' can help solve is actually identifying
> the parts that have semi-permanent maintainers, and the parts that don't.
>
> One way to use the meta-information, for example, would be to use it to
> periodically
Henning P. Schmiedehausen <[EMAIL PROTECTED]> ecrit :
[...]
> What's wrong with:
>
[xml]
I'd rather use c/etags.
Seriously, it won't create maintainers automagically.
I don't see the benefit.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Henning P. Schmiedehausen [EMAIL PROTECTED] ecrit :
[...]
What's wrong with:
[xml]
I'd rather use c/etags.
Seriously, it won't create maintainers automagically.
I don't see the benefit.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Eric S. Raymond [EMAIL PROTECTED] ecrit :
[...]
One of the problems this `overdesign' can help solve is actually identifying
the parts that have semi-permanent maintainers, and the parts that don't.
One way to use the meta-information, for example, would be to use it to
periodically poll
Eric S. Raymond [EMAIL PROTECTED] ecrit :
Francois Romieu [EMAIL PROTECTED]:
[...]
Somebody will have less work [*] [ ]
Yes, anybody trying to figure out how to get a fix made.
Provided it's kept up-to-date. I.e. it calls for some tools (and these
require the suggested changes
Stefan Jaschke <[EMAIL PROTECTED]> écrit :
> On Friday 20 April 2001 16:33, Francois Romieu wrote:
> > Stefan Jaschke <[EMAIL PROTECTED]> ecrit :
> > > I copied epic100.c from 2.4.2 into the 2.4.4-pre4 tree and it compiles
> > > and works without problems.
Stefan Jaschke <[EMAIL PROTECTED]> ecrit :
[...]
> I copied epic100.c from 2.4.2 into the 2.4.4-pre4 tree and it compiles and works
>without
> problems.
> This gives me a workable solution :-)
Thanks for the info.
Now, why do you get so much Receive Queue Empty indications...
--
Ueimor
-
Stefan Jaschke <[EMAIL PROTECTED]> ecrit :
[...]
> I don't believe the motherboard or the BIOS have anything to do with, simply
It may give a clue because the machine I wrote this mail from is a
2.4.3 + 2*EtherPower II it looks rather fine (old asus motherbord, BX,
backuped peaceful prod
Stefan Jaschke [EMAIL PROTECTED] ecrit :
[...]
I don't believe the motherboard or the BIOS have anything to do with, simply
It may give a clue because the machine I wrote this mail from is a
2.4.3 + 2*EtherPower II it looks rather fine (old asus motherbord, BX,
backuped peaceful prod server):
Stefan Jaschke [EMAIL PROTECTED] ecrit :
[...]
I copied epic100.c from 2.4.2 into the 2.4.4-pre4 tree and it compiles and works
without
problems.
This gives me a workable solution :-)
Thanks for the info.
Now, why do you get so much Receive Queue Empty indications...
--
Ueimor
-
To
Stefan Jaschke [EMAIL PROTECTED] écrit :
On Friday 20 April 2001 16:33, Francois Romieu wrote:
Stefan Jaschke [EMAIL PROTECTED] ecrit :
I copied epic100.c from 2.4.2 into the 2.4.4-pre4 tree and it compiles
and works without problems.
This gives me a workable solution :-)
Thanks
Linas Vepstas <[EMAIL PROTECTED]> écrit :
[...]
> I want to report a trio of raid-related problems. The third one is
> very serious, and effectively prevents 2.4.3 from being usable (by me).
>
[...]
> The problem: this dramatically slows fsck after an unclean shut-down.
> You can hear the
Linas Vepstas [EMAIL PROTECTED] écrit :
[...]
I want to report a trio of raid-related problems. The third one is
very serious, and effectively prevents 2.4.3 from being usable (by me).
[...]
The problem: this dramatically slows fsck after an unclean shut-down.
You can hear the drives
Hello,
it compiles fine and there is no MAINTAINER entry for it nor specific
email address in the source file.
diff -u --recursive linux-2.4.3-ac5.orig/drivers/char/keyboard.c
linux-2.4.3-ac5/drivers/char/keyboard.c
--- linux-2.4.3-ac5.orig/drivers/char/keyboard.cThu Apr 12 20:23:06
Hello,
it compiles fine and there is no MAINTAINER entry for it nor specific
email address in the source file.
diff -u --recursive linux-2.4.3-ac5.orig/drivers/char/keyboard.c
linux-2.4.3-ac5/drivers/char/keyboard.c
--- linux-2.4.3-ac5.orig/drivers/char/keyboard.cThu Apr 12 20:23:06
Krzysztof Halasa <[EMAIL PROTECTED]> écrit :
[...]
> But it's still more complicated than the first one and I'm not sure
> if doing that is worth it
>
> > struc sub_req {
> > int sub_ioctl;
>
> ... as we lose 4 bytes here (currently the union of structs in ifreq
> is limited to 16 bytes)
Krzysztof Halasa [EMAIL PROTECTED] crit :
[...]
But it's still more complicated than the first one and I'm not sure
if doing that is worth it
struc sub_req {
int sub_ioctl;
... as we lose 4 bytes here (currently the union of structs in ifreq
is limited to 16 bytes)
I missed
Krzysztof Halasa <[EMAIL PROTECTED]> écrit :
[...]
> > Comments welcome. IMHO domain-specific ioctls are a better direction
> > than the current make-sockios.h-huge-with-new-ioctls approach.
>
> I think we should separate two things there:
> - the place (files) where SIOCxxx values are defined
Krzysztof Halasa [EMAIL PROTECTED] crit :
[...]
Comments welcome. IMHO domain-specific ioctls are a better direction
than the current make-sockios.h-huge-with-new-ioctls approach.
I think we should separate two things there:
- the place (files) where SIOCxxx values are defined
- the way
Daniel Nofftz <[EMAIL PROTECTED]> écrit :
[...]
> i can`t get my smc etherpower ii working with the 2.4.3 kernel.
> now i have downgraded to 2.4.2 and it works again ...
> does anyone have a suggestion, what the problem is ?
[...]
> Mar 31 19:23:29 hyperion kernel: eth0: Setting half-duplex based
Daniel Nofftz [EMAIL PROTECTED] crit :
[...]
i can`t get my smc etherpower ii working with the 2.4.3 kernel.
now i have downgraded to 2.4.2 and it works again ...
does anyone have a suggestion, what the problem is ?
[...]
Mar 31 19:23:29 hyperion kernel: eth0: Setting half-duplex based on MII
Krzysztof Halasa <[EMAIL PROTECTED]> écrit :
[...]
> That's a physical interface like V.35 or RS232.
Ok.
[...]
> > * n200, t200 ?
>
> What's that?
Parameters for retransmission of a trame specified in Q922. t200 is the
timeout value and n200 the maximal number of retransmissions. They can
be
Krzysztof Halasa [EMAIL PROTECTED] crit :
[...]
That's a physical interface like V.35 or RS232.
Ok.
[...]
* n200, t200 ?
What's that?
Parameters for retransmission of a trame specified in Q922. t200 is the
timeout value and n200 the maximal number of retransmissions. They can
be negocied
Krzysztof Halasa <[EMAIL PROTECTED]> écrit :
[...]
> making it universal for all types of interfaces (now, we have different
> configuration mechanisms even between different HDLC cards).
Alas :o(
> +struct hdlc_physical /* 10 bytes */
> +{
> + unsigned int interface;
> +
Krzysztof Halasa [EMAIL PROTECTED] crit :
[...]
making it universal for all types of interfaces (now, we have different
configuration mechanisms even between different HDLC cards).
Alas :o(
+struct hdlc_physical /* 10 bytes */
+{
+ unsigned int interface;
+ unsigned int
John Plate <[EMAIL PROTECTED]> écrit :
[do_try_to_free_pages]
Known issue on < 2.2.19pre kernels (do a search for "do_try_to_free_pages"
on the ML archive). It doesn't require RAID btw. Upgrade to 2.2.19prexx, it
performs better.
--
Ueimor
-
To unsubscribe from this list: send the line
John Plate [EMAIL PROTECTED] crit :
[do_try_to_free_pages]
Known issue on 2.2.19pre kernels (do a search for "do_try_to_free_pages"
on the ML archive). It doesn't require RAID btw. Upgrade to 2.2.19prexx, it
performs better.
--
Ueimor
-
To unsubscribe from this list: send the line
LA Walsh <[EMAIL PROTECTED]> écrit :
> Here is the 'alternate' output when the ncr53c8xx driver is
> compiled in:
>
> SCSI subsystem driver Revision: 1.00
> scsi-ncr53c7,8xx : at PCI bus 0, device 8, function 0
> scsi-ncr53c7,8xx : warning : revision of 35 is greater than 2.
> scsi-ncr53c7,8xx :
LA Walsh [EMAIL PROTECTED] crit :
Here is the 'alternate' output when the ncr53c8xx driver is
compiled in:
SCSI subsystem driver Revision: 1.00
scsi-ncr53c7,8xx : at PCI bus 0, device 8, function 0
scsi-ncr53c7,8xx : warning : revision of 35 is greater than 2.
scsi-ncr53c7,8xx : NCR53c810
Jeff Garzik <[EMAIL PROTECTED]> écrit :
> You should use this patch instead, from Alan's tree, for updating
> include/linux/if_arp.h...
It adds confusion: do you imagine the poor soul who discovers hdlc in Linux
and sees ARPHRD_CISCO and ARPHRD_HDLC for the same use after some hours
of
- hdlc.c requires ARPHRD_CISCO (Cisco HDLC) to compile. This should*
be ARPHRD_HDLC
- the PCI_VENDOR/DEVICE_xxx for drivers/net/wan/dscc4.c haven't been
included in the pci_ids db
- drivers/net/wan/dscc4.c relies on ARPHRD_RAWHDLC (it's initialized
as a transparent hdlc driver and I know no
- hdlc.c requires ARPHRD_CISCO (Cisco HDLC) to compile. This should*
be ARPHRD_HDLC
- the PCI_VENDOR/DEVICE_xxx for drivers/net/wan/dscc4.c haven't been
included in the pci_ids db
- drivers/net/wan/dscc4.c relies on ARPHRD_RAWHDLC (it's initialized
as a transparent hdlc driver and I know no
Jeff Garzik [EMAIL PROTECTED] crit :
You should use this patch instead, from Alan's tree, for updating
include/linux/if_arp.h...
It adds confusion: do you imagine the poor soul who discovers hdlc in Linux
and sees ARPHRD_CISCO and ARPHRD_HDLC for the same use after some hours
of code-greping
Rama Krishna Mandava <[EMAIL PROTECTED]> écrit :
[...]
>can memcpy ,memset functions be used in drivermodules code of
> linux ? if so header file string.h is enough to be included?
Take a look at /include/linux/string.h. You just need to:
#include
--
Ueimor
-
To unsubscribe from
Rama Krishna Mandava [EMAIL PROTECTED] crit :
[...]
can memcpy ,memset functions be used in drivermodules code of
linux ? if so header file string.h is enough to be included?
Take a look at kernel_tree/include/linux/string.h. You just need to:
#include linux/string.h
--
Ueimor
-
Hello,
Context:
HDLC PCI adapter + line at 2 Mb/s + external traffic generator that fills
the line with 5 to x1000 bytes frame.
I want to see how my code bahaves during rare (?) events: an overflow of
the RX fifo (256 bytes) and a TX underrun. It's my understanding that if the
adapter pains
Hello,
Context:
HDLC PCI adapter + line at 2 Mb/s + external traffic generator that fills
the line with 5 to x1000 bytes frame.
I want to see how my code bahaves during rare (?) events: an overflow of
the RX fifo (256 bytes) and a TX underrun. It's my understanding that if the
adapter pains
Dennis <[EMAIL PROTECTED]> écrit :
[...]
> When is that specification for 2.4 drivers going to be available? Talk
> about "stifling the marketplace"!!! Vendors cant even write reliable
> drivers if they want to.
May be said vendors should give a look at l-k between 2.2 and 2.4 instead
of
Alan Cox <[EMAIL PROTECTED]> écrit :
[...]
> > For example, if there were six different companies that marketed ethernet
> > drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> > with different "features" that were of value to you. Instead, you have
> > crappy GPL code
Alan Cox [EMAIL PROTECTED] crit :
[...]
For example, if there were six different companies that marketed ethernet
drivers for the eepro100, you'd have a choice of which one to buy..perhaps
with different "features" that were of value to you. Instead, you have
crappy GPL code that locks
Dennis [EMAIL PROTECTED] crit :
[...]
When is that specification for 2.4 drivers going to be available? Talk
about "stifling the marketplace"!!! Vendors cant even write reliable
drivers if they want to.
May be said vendors should give a look at l-k between 2.2 and 2.4 instead
of spending
[EMAIL PROTECTED] <[EMAIL PROTECTED]> écrit :
[...]
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/sound/es1370.c
>linux-dj/drivers/sound/es1370.c
> --- linux/drivers/sound/es1370.c Sat Feb 10 02:49:52 2001
> +++ linux-dj/drivers/sound/es1370.c Sat Feb 10 03:05:52 2001
> @@
[EMAIL PROTECTED] [EMAIL PROTECTED] crit :
[...]
diff -urN --exclude-from=/home/davej/.exclude linux/drivers/sound/es1370.c
linux-dj/drivers/sound/es1370.c
--- linux/drivers/sound/es1370.c Sat Feb 10 02:49:52 2001
+++ linux-dj/drivers/sound/es1370.c Sat Feb 10 03:05:52 2001
@@ -117,6
ARND BERGMANN <[EMAIL PROTECTED]> écrit :
[...]
> > > > > Working epic100 drivers:
> > > > > - 2.4.0
> > > > > - 2.4.0-ac9
> > > >
> > > > Could you give a look at ac12 (fine here) ?
> > > >
> > > No, does not work, same problem.
> >
> > The modifications between ac9 and ac12 come from the
ARND BERGMANN [EMAIL PROTECTED] crit :
[...]
Working epic100 drivers:
- 2.4.0
- 2.4.0-ac9
Could you give a look at ac12 (fine here) ?
No, does not work, same problem.
The modifications between ac9 and ac12 come from the new DMA
mapping.
What about
Jeff Garzik <[EMAIL PROTECTED]> écrit :
[...]
> Patch looks ok. Further change: move pci_enable_device above the
> request_region call. request_region calls pci_resource_start(), which
> may not return a proper value if called before pci_enable_device.
---
Dimitromanolakis Apostolos <[EMAIL PROTECTED]> écrit :
[...]
> Your patch had some problem in the maxiradio_radio_init function as
> pci_register_driver returns the number of devices found and not 0 when
> succesful. I fixed it and here is my patch against the original driver.
Patch-o-the-month
ARND BERGMANN <[EMAIL PROTECTED]> écrit :
> On Thu, 8 Feb 2001, Francois Romieu wrote:
>
> > >
> > > Working epic100 drivers:
> > > - 2.4.0
> > > - 2.4.0-ac9
> >
> > Could you give a look at ac12 (fine here) ?
> >
> No,
ARND BERGMANN [EMAIL PROTECTED] crit :
On Thu, 8 Feb 2001, Francois Romieu wrote:
Working epic100 drivers:
- 2.4.0
- 2.4.0-ac9
Could you give a look at ac12 (fine here) ?
No, does not work, same problem.
The modifications between ac9 and ac12 come from the new DMA
Dimitromanolakis Apostolos [EMAIL PROTECTED] crit :
[...]
Your patch had some problem in the maxiradio_radio_init function as
pci_register_driver returns the number of devices found and not 0 when
succesful. I fixed it and here is my patch against the original driver.
Patch-o-the-month
Jeff Garzik [EMAIL PROTECTED] crit :
[...]
Patch looks ok. Further change: move pci_enable_device above the
request_region call. request_region calls pci_resource_start(), which
may not return a proper value if called before pci_enable_device.
---
ARND BERGMANN <[EMAIL PROTECTED]> écrit :
> There seems to be some movement in the driver and the latest one
> is not working for me (again), so I'm giving a subjective status report
> for the versions I have tried lately:
>
> Working epic100 drivers:
> - 2.4.0
> - 2.4.0-ac9
Could you give a
The Wed, Feb 07, 2001 at 10:48:17PM -0500, Jeff Garzik wrote :
[...]
> > diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/epic100.c
>linux-dj/drivers/net/epic100.c
> > --- linux/drivers/net/epic100.c Wed Feb 7 21:55:56 2001
> > +++ linux-dj/drivers/net/epic100.c Wed Feb 7
Changes:
- pci_enable_device return value wasn't checked,
- unbalanced video_register_device if late failure in radio_install,
- request_region is now done on the whole resource size (if it's wrong, the
magic value "4" deserves a small comment imho),
- new pci interface beautification (may help
Changes:
- pci_enable_device return value wasn't checked,
- unbalanced video_register_device if late failure in radio_install,
- request_region is now done on the whole resource size (if it's wrong, the
magic value "4" deserves a small comment imho),
- new pci interface beautification (may help
Maciej W. Rozycki <[EMAIL PROTECTED]> écrit :
[...]
> While working on the CPU capabilities changes I noticed the W89c840
> driver prints a different cache alignment from what it really sets. It's
> possible that it's the intended behaviour, but I really doubt it. I don't
> have such a board
Maciej W. Rozycki [EMAIL PROTECTED] crit :
[...]
While working on the CPU capabilities changes I noticed the W89c840
driver prints a different cache alignment from what it really sets. It's
possible that it's the intended behaviour, but I really doubt it. I don't
have such a board and I
Andrew Morton <[EMAIL PROTECTED]> écrit :
[...]
> The 3c905C is a well manufactured and very feature-rich NIC which at
> present appears to have fewer problem reports than eepro100, 8139 or tulip.
I guess that the lack of problem reports for the epic chipset comes from
a smaller user base. FWIW,
Andrew Morton [EMAIL PROTECTED] écrit :
[...]
The 3c905C is a well manufactured and very feature-rich NIC which at
present appears to have fewer problem reports than eepro100, 8139 or tulip.
I guess that the lack of problem reports for the epic chipset comes from
a smaller user base. FWIW, I
Rasmus Andersen <[EMAIL PROTECTED]> écrit :
[...]
> There are some other cleanups I want to do, and I need to make my indentation
> match the drivers, but that will be after the basic conversion is done.
>
>
> --- linux-240-t13-pre1-clean/drivers/net/rcpci45.cSat Nov 4 23:27:08 2000
> +++
Rasmus Andersen [EMAIL PROTECTED] écrit :
[...]
There are some other cleanups I want to do, and I need to make my indentation
match the drivers, but that will be after the basic conversion is done.
--- linux-240-t13-pre1-clean/drivers/net/rcpci45.cSat Nov 4 23:27:08 2000
+++
Ivan Passos <[EMAIL PROTECTED]> écrit :
[...]
> Anyhow, the parameters we currently need to configure on our board (the
> PC300) are as follows:
>
> - Media: V.35, RS-232, X.21, T1, E1
drivers/net/wan/lmc/lmc_media.c:65
char *lmc_t1_cables[] = {
"V.10/RS423", "EIA530A", "reserved", "X.21",
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":
>
> bash-2.04# ifconfig --help
> Usage:
> ifconfig [-a] [-i] [-v] [-s] [[] ]
> ...
> [mem_start ] [io_addr ] [irq ]
Chris Wedgwood <[EMAIL PROTECTED]> écrit :
[...]
> o across different networks cards -- I've been thinking about it of
> late as I had to battle with this earlier this week; depending on
> what network card you use, you need different magic incarnations to
> do the above.
>
> A standard
[netdev Cced]
The Thu, Nov 30, 2000 at 11:16:52AM -0800, Ivan Passos wrote :
[...]
> For synchronous network interfaces, besides configuring network parameters
> such as IP address, netmask, MTU, etc., the system should also configure
> parameters specific to these sync i/f's, such as media (e.g
[netdev Cced]
The Thu, Nov 30, 2000 at 11:16:52AM -0800, Ivan Passos wrote :
[...]
For synchronous network interfaces, besides configuring network parameters
such as IP address, netmask, MTU, etc., the system should also configure
parameters specific to these sync i/f's, such as media (e.g
Chris Wedgwood [EMAIL PROTECTED] écrit :
[...]
o across different networks cards -- I've been thinking about it of
late as I had to battle with this earlier this week; depending on
what network card you use, you need different magic incarnations to
do the above.
A standard interface is
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":
bash-2.04# ifconfig --help
Usage:
ifconfig [-a] [-i] [-v] [-s] interface [[AF] address]
...
[mem_start NN] [io_addr
Hi,
The Tue, Nov 28, 2000 at 10:52:46AM +0100, Lukasz Trabinski wrote :
[...]
> I have the same problem with SMSC EPIC/100 83c170 Ethernet controller:
>
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Transmit timeout using MII device, Tx status 0003.
> eth0: Restarting the EPIC chip, Rx
Hi,
The Tue, Nov 28, 2000 at 10:52:46AM +0100, Lukasz Trabinski wrote :
[...]
I have the same problem with SMSC EPIC/100 83c170 Ethernet controller:
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout using MII device, Tx status 0003.
eth0: Restarting the EPIC chip, Rx
Hello,
the following updates the epic100.c driver to the DMA mapping api.
It compiles. It survives ping flood (small/big sizes), insmod/rmmod and seems
to work as it should on an intel machine. Big-endian testers welcome.
--- linux-2.4.0-test11.orig/drivers/net/epic100.c Sun Nov 26
Hello,
the following updates the epic100.c driver to the DMA mapping api.
It compiles. It survives ping flood (small/big sizes), insmod/rmmod and seems
to work as it should on an intel machine. Big-endian testers welcome.
--- linux-2.4.0-test11.orig/drivers/net/epic100.c Sun Nov 26
Hi,
The Sat, Nov 18, 2000 at 01:46:40PM +0200, Kaj-Michael Lang wrote :
> This patch adds a swap kernel commandline option, so that you can add a
> swap partition before init starts running on a low-memory machine.
Did you try and add swap from an initrd image ? It should work and it's
already
Hi,
The Sat, Nov 18, 2000 at 01:46:40PM +0200, Kaj-Michael Lang wrote :
This patch adds a swap kernel commandline option, so that you can add a
swap partition before init starts running on a low-memory machine.
Did you try and add swap from an initrd image ? It should work and it's
already
CPU A: assume de->count = 1 (in de_put)
fs/proc/inode.c::44 if (!--de->count) {
de->count = 0
CPU B: (in remove_proc_entry)
fs/proc/generic.c::577 if (!de->count)
fs/proc/generic.c::578 free_proc_entry(de);
CPU A: (in de_put)
fs/proc/inode.c::45 if (de->deleted) { <--
CPU A: assume de-count = 1 (in de_put)
fs/proc/inode.c::44 if (!--de-count) {
de-count = 0
CPU B: (in remove_proc_entry)
fs/proc/generic.c::577 if (!de-count)
fs/proc/generic.c::578 free_proc_entry(de);
CPU A: (in de_put)
fs/proc/inode.c::45 if (de-deleted) { --
The Sun, Nov 12, 2000 at 06:00:07PM +0200, Mircea Damian wrote :
[...]
> I just want to say that the file 'Documentation/networking/ppp.txt' (as it
> is mentioned in Configure.help at CONFIG_PPP option) does not exists.
--- /usr/src/linux-2.4.0-test11-pre4.orig/Documentation/Configure.help Mon
- sound modules: adding __init without doesn't seem to work;
- typo in net/ax25/sysctl_net_ax25.c.
diff -u -N --recursive linux-2.4.0-test11-pre4.orig/drivers/sound/gus_midi.c
linux-2.4.0-test11-pre4/drivers/sound/gus_midi.c
--- linux-2.4.0-test11-pre4.orig/drivers/sound/gus_midi.c Mon
The Mon, Nov 13, 2000 at 05:29:48PM +0530, [EMAIL PROTECTED] wrote :
[...]
> When i run following code many times.
> System becomes useless till all of the instance of this programming are
> killed by vmm.
[malloc bomb]
Check some archives of the linux-kernel list for "overcommit".
--
Ueimor
-
The Mon, Nov 13, 2000 at 05:29:48PM +0530, [EMAIL PROTECTED] wrote :
[...]
When i run following code many times.
System becomes useless till all of the instance of this programming are
killed by vmm.
[malloc bomb]
Check some archives of the linux-kernel list for "overcommit".
--
Ueimor
-
To
801 - 900 of 914 matches
Mail list logo
