On Sat, 17 Feb 2007, Tilman Schmidt wrote:
> Alright, then so be it. But that raises another question:
> asyncdata.o is only needed for M105 and M101, not for the base
> driver. How do I express in Kbuild that asyncdata.o is to be added
> to gigaset-y only if CONFIG_GIGASET_M105 and
On Sat, 17 Feb 2007, Tilman Schmidt wrote:
Alright, then so be it. But that raises another question:
asyncdata.o is only needed for M105 and M101, not for the base
driver. How do I express in Kbuild that asyncdata.o is to be added
to gigaset-y only if CONFIG_GIGASET_M105 and
Bill Davidsen wrote:
> Philippe De Muyter wrote:
>> On Tue, Feb 06, 2007 at 10:41:30PM +0200, Ahmed S. Darwish wrote:
>>> On Tue, Feb 06, 2007 at 09:52:17AM -0800, Joe Perches wrote:
On Tue, 2007-02-06 at 18:04 +0200, Ahmed S. Darwish wrote:
> A patch to use ARRAY_SIZE macro already
Bill Davidsen wrote:
Philippe De Muyter wrote:
On Tue, Feb 06, 2007 at 10:41:30PM +0200, Ahmed S. Darwish wrote:
On Tue, Feb 06, 2007 at 09:52:17AM -0800, Joe Perches wrote:
On Tue, 2007-02-06 at 18:04 +0200, Ahmed S. Darwish wrote:
A patch to use ARRAY_SIZE macro already defined in kernel.h
> That's usually solved through #define's (see e.g. lib/extable.c).
Well, you can obviously solve pretty much everything with #define's, but
it's usually also the ugliest solution.
>From my point of view, the preferences for solving issues like the
extable.c one are:
o Do it automatically.
On Sat, 5 Mar 2005, Adrian Bunk wrote:
> This warning sounds like a good plan (but it won't let many objects stay
> inside lib-y).
The patch is simple (except that the warning it throws looks rather ugly),
see appended.
However, I spoke too soon. There actually is a legitimate use for
On Sat, 5 Mar 2005, Adrian Bunk wrote:
> And this can break as soon as the "unused" object files contains
> EXPORT_SYMBOL's.
>
> Is it really worth it doing it in this non-intuitive way?
I don't think it non-intuitive, it's how libraries work. However, as you
say, it is broken for files
On Sat, 5 Mar 2005, Adrian Bunk wrote:
And this can break as soon as the unused object files contains
EXPORT_SYMBOL's.
Is it really worth it doing it in this non-intuitive way?
I don't think it non-intuitive, it's how libraries work. However, as you
say, it is broken for files containing
On Sat, 5 Mar 2005, Adrian Bunk wrote:
This warning sounds like a good plan (but it won't let many objects stay
inside lib-y).
The patch is simple (except that the warning it throws looks rather ugly),
see appended.
However, I spoke too soon. There actually is a legitimate use for
That's usually solved through #define's (see e.g. lib/extable.c).
Well, you can obviously solve pretty much everything with #define's, but
it's usually also the ugliest solution.
From my point of view, the preferences for solving issues like the
extable.c one are:
o Do it automatically. If
On Fri, 4 Mar 2005, Adrian Bunk wrote:
> > [...] So ld looks into the lib .a archive, determines that none of
> > the symbols in that object file are needed to resolve a reference and
> > drops the entire .o file.
> Silly question:
> What's the advantage of lib-y compared to obj-y?
Basically
On Fri, 4 Mar 2005, Rusty Russell wrote:
> On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
> > Why doesn't an EXPORT_SYMBOL create a reference?
>
> It does: EXPORT_SYMBOL(x) drops the address of "x", including
> __attribute_used__, in the __ksymtab section.
Well, the problem is that this
On Fri, 4 Mar 2005, Rusty Russell wrote:
On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
Why doesn't an EXPORT_SYMBOL create a reference?
It does: EXPORT_SYMBOL(x) drops the address of x, including
__attribute_used__, in the __ksymtab section.
Well, the problem is that this is still
On Fri, 4 Mar 2005, Adrian Bunk wrote:
[...] So ld looks into the lib .a archive, determines that none of
the symbols in that object file are needed to resolve a reference and
drops the entire .o file.
Silly question:
What's the advantage of lib-y compared to obj-y?
Basically exactly
On Tue, 8 Feb 2005, Sam Ravnborg wrote:
> The SCCS rules is the sole reason why -rR has not been enabled.
An easy way to make sure that the SCCS business is not a factor would be
to explicitly put the SCCS rules into the Makefile -- it's just two lines.
This way one could easily make sure
On Tue, 8 Feb 2005, Sam Ravnborg wrote:
The SCCS rules is the sole reason why -rR has not been enabled.
An easy way to make sure that the SCCS business is not a factor would be
to explicitly put the SCCS rules into the Makefile -- it's just two lines.
This way one could easily make sure there
On Sat, 7 Jul 2001, Russell King wrote:
> Seems like its something that appeared between 2.4.5 and 2.4.6. Anyone
> know the correct fix, other than reversing the change?
It should be fine.
> Since all net cards are modules, object list for pcmcia_net.o is empty and
> kernel can't be linked.
On Sat, 7 Jul 2001, Russell King wrote:
Seems like its something that appeared between 2.4.5 and 2.4.6. Anyone
know the correct fix, other than reversing the change?
It should be fine.
Since all net cards are modules, object list for pcmcia_net.o is empty and
kernel can't be linked.
On Fri, 29 Jun 2001, Alan Cox wrote:
> 2.4.5-ac20
> o Commence resync with 2.4.6pre5
I updated my laptop to 2.4.5-ac21 today. After reboot, I found a strange
problem: My network card wouldn't initialize properly (eepro100).
Jun 29 21:26:31 vaio kernel: eepro100.c: $Revision: 1.36 $
On Fri, 29 Jun 2001, Alan Cox wrote:
2.4.5-ac20
o Commence resync with 2.4.6pre5
I updated my laptop to 2.4.5-ac21 today. After reboot, I found a strange
problem: My network card wouldn't initialize properly (eepro100).
Jun 29 21:26:31 vaio kernel: eepro100.c: $Revision: 1.36 $
On Tue, 12 Jun 2001, Boenisch Joerg wrote:
> I hope not to be off topic! (In that case could you tell me where to ask?)
You can try [EMAIL PROTECTED] or the newsgroup
de.alt.comm.isdn4linux.de, but I can't guarantee success there, either.
> Kernel of course is compiled with ISDN support and
On Tue, 12 Jun 2001, Boenisch Joerg wrote:
I hope not to be off topic! (In that case could you tell me where to ask?)
You can try [EMAIL PROTECTED] or the newsgroup
de.alt.comm.isdn4linux.de, but I can't guarantee success there, either.
Kernel of course is compiled with ISDN support and
On Tue, 5 Jun 2001, W. Michael Petullo wrote:
> > But the problem still remains. How do I make my /sbin/init run with PID 1
> > using initial ramdisk under the new root change mechanism? I don't want to
> > use the old change_root mechanism...
>
> I had the same problem when doing some
On Tue, 5 Jun 2001, W. Michael Petullo wrote:
But the problem still remains. How do I make my /sbin/init run with PID 1
using initial ramdisk under the new root change mechanism? I don't want to
use the old change_root mechanism...
I had the same problem when doing some development for
On Thu, 31 May 2001, CZUCZY Gergely wrote:
> May 27 15:00:50 kign kernel: ippp0: dialing 1 0651201201...
> May 27 15:00:51 kign kernel: isdn_net: ippp0 connected
> May 27 15:00:51 kign ipppd[391]: Local number: 2536889, Remote
> number: 0651201201, Type: outgoing
> May 27 15:00:51 kign
On Thu, 31 May 2001, CZUCZY Gergely wrote:
May 27 15:00:50 kign kernel: ippp0: dialing 1 0651201201...
May 27 15:00:51 kign kernel: isdn_net: ippp0 connected
May 27 15:00:51 kign ipppd[391]: Local number: 2536889, Remote
number: 0651201201, Type: outgoing
May 27 15:00:51 kign ipppd[391]:
On Mon, 28 May 2001, Rasmus Andersen wrote:
> The patch below fixes what I believe is a bug in hysdn_net.c.
> I cannot see how we can proceed under _any_ circumstances
> after the kmalloc fails. Applies against 245ac1.
Yep, you're obviously right. Thanks, I'll check in your patch into our
CVS,
On Mon, 28 May 2001, Rasmus Andersen wrote:
The patch below fixes what I believe is a bug in hysdn_net.c.
I cannot see how we can proceed under _any_ circumstances
after the kmalloc fails. Applies against 245ac1.
Yep, you're obviously right. Thanks, I'll check in your patch into our
CVS, and
On Fri, 18 May 2001, Eric S. Raymond wrote:
> That being the case, we do face a question of design
> philosophy, expressed as a policy question about how to design
> rulesets. Actually two questions:
>
> 1. When we have a platform symbol for a reference design like MVME147, do
>we stick to
On Fri, 18 May 2001, Eric S. Raymond wrote:
That being the case, we do face a question of design
philosophy, expressed as a policy question about how to design
rulesets. Actually two questions:
1. When we have a platform symbol for a reference design like MVME147, do
we stick to its
On Wed, 16 May 2001, Alexander Viro wrote:
> a) I2C stuff got converted to module_init() nicely. That took
> a lot of cruft away.
Definitely makes sense.
> b) init order is preserved. However, that worked only because
> none of the i2c initialization functions touch stuff from
On Wed, 16 May 2001, Alexander Viro wrote:
a) I2C stuff got converted to module_init() nicely. That took
a lot of cruft away.
Definitely makes sense.
b) init order is preserved. However, that worked only because
none of the i2c initialization functions touch stuff from random.c
On Wed, 9 May 2001, Jochen Striepe wrote:
> is there any Linux driver for the AVM Fritz! PCI v2.0 ISDN card
> available? Using vanilla 2.2.19's HiSax driver doesn't seem to work,
> and I found nothing at AVM's web page [1]. Did I miss someting?
>
> [1] http://www.avm.de/
You're right, the HiSax
On Wed, 9 May 2001, Jochen Striepe wrote:
is there any Linux driver for the AVM Fritz! PCI v2.0 ISDN card
available? Using vanilla 2.2.19's HiSax driver doesn't seem to work,
and I found nothing at AVM's web page [1]. Did I miss someting?
[1] http://www.avm.de/
You're right, the HiSax
On Tue, 1 May 2001, J . A . Magallon wrote:
> On 05.01 Keith Owens wrote:
> >
> > The patch appears to work but is it worth applying now? The existing
> > 2.4 rules work fine and the entire kbuild system will be rewritten for
> > 2.5, including the case you identified here. It struck me as a
On Tue, 1 May 2001, J . A . Magallon wrote:
On 05.01 Keith Owens wrote:
The patch appears to work but is it worth applying now? The existing
2.4 rules work fine and the entire kbuild system will be rewritten for
2.5, including the case you identified here. It struck me as a decent
:
The attached patch allows to get rid of the "list-multi := ..." lines and
link-rules for multi-part objects in all the Makefiles without breaking
any current Makefile.
-- Forwarded message --
Date: Tue, 24 Apr 2001 15:05:07 +0200 (CEST)
From: Kai Germaschewski <[EM
Newer gcc's (particularly the RH 7.0/7.1 2.96 versions) complain about
implicit declaration of the function abs, and AFAICS they're right.
What do people think about the appended patch to fix this?
(There's more users than just isdn_audio.c, that's why I added a common
header file).
--Kai
Newer gcc's (particularly the RH 7.0/7.1 2.96 versions) complain about
implicit declaration of the function abs, and AFAICS they're right.
What do people think about the appended patch to fix this?
(There's more users than just isdn_audio.c, that's why I added a common
header file).
--Kai
:
The attached patch allows to get rid of the list-multi := ... lines and
link-rules for multi-part objects in all the Makefiles without breaking
any current Makefile.
-- Forwarded message --
Date: Tue, 24 Apr 2001 15:05:07 +0200 (CEST)
From: Kai Germaschewski [EMAIL PROTECTED
On Fri, 27 Apr 2001, David S. Miller wrote:
> Kai, can you try this patch out? I think it does the right
> thing. What I'm mostly interested in is if your ipchains
> setup works for the resulting kernel, I've already checked
> that it links properly. :-)
If you get this mail, it works okay
On Fri, 27 Apr 2001, David S. Miller wrote:
>> net/network.o: In function `ip_nat_setup_info':
>> net/network.o(.text+0x37b3e): undefined reference to `helpers'
>> net/network.o(.text+0x37b54): undefined reference to `helpers'
>
> Your configuration seems impossible, somehow the config system
On Fri, 27 Apr 2001, David S. Miller wrote:
net/network.o: In function `ip_nat_setup_info':
net/network.o(.text+0x37b3e): undefined reference to `helpers'
net/network.o(.text+0x37b54): undefined reference to `helpers'
Your configuration seems impossible, somehow the config system allowed
On Fri, 27 Apr 2001, David S. Miller wrote:
Kai, can you try this patch out? I think it does the right
thing. What I'm mostly interested in is if your ipchains
setup works for the resulting kernel, I've already checked
that it links properly. :-)
If you get this mail, it works okay :-)
On Thu, 19 Apr 2001, Eric S. Raymond wrote:
> The following patch cleans dead symbols out of the defconfigs in the 2.4.4pre4
> source tree. It corrects a typo involving CONFIG_GEN_RTC. Another typo
> involving CONFIG_SOUND_YMPCI doesn't need to be corrected, as the symbol
> is never set in
On Thu, 19 Apr 2001, Eric S. Raymond wrote:
The following patch cleans dead symbols out of the defconfigs in the 2.4.4pre4
source tree. It corrects a typo involving CONFIG_GEN_RTC. Another typo
involving CONFIG_SOUND_YMPCI doesn't need to be corrected, as the symbol
is never set in these
On Fri, 30 Mar 2001, hugang wrote:
> Hello all:
>
> ---
> OPEN: 10.0.0.2 -> 202.99.16.1 UDP, port: 1024 -> 53
> ippp0: dialing 1 86310163...
> isdn: HiSax,ch0 cause: E001B <--- error !!
> isdn_net: local hangup ippp0
> ippp0: Chargesum
On Fri, 30 Mar 2001, hugang wrote:
Hello all:
---
OPEN: 10.0.0.2 - 202.99.16.1 UDP, port: 1024 - 53
ippp0: dialing 1 86310163...
isdn: HiSax,ch0 cause: E001B --- error !!
isdn_net: local hangup ippp0
ippp0: Chargesum is 0
On Wed, 21 Mar 2001, Joern Heissler wrote:
> I've got a strange problem with /dev/isdninfo:
>
> joern:~# cat /dev/isdninfo
> idmap: Hisax...
> chmap: 0 1 ...
>
> --> cat /dev/isdninfo works :-)
>
> Here's the problem:
>
> open("/dev/isdninfo", O_RDONLY) = 3
> read(3, "", 200) = 0
>
> Could
On Wed, 21 Mar 2001, Joern Heissler wrote:
I've got a strange problem with /dev/isdninfo:
joern:~# cat /dev/isdninfo
idmap: Hisax...
chmap: 0 1 ...
-- cat /dev/isdninfo works :-)
Here's the problem:
open("/dev/isdninfo", O_RDONLY) = 3
read(3, "", 200) = 0
Could someone please
On Sun, 18 Mar 2001, Andrew Morton wrote:
> I'm planning on poking through everything which has been
> identified as a posible problem. But I won't start for
> several weeks - give the maintainers (if any) time to
> address these things.
I took a look at the ISDN issues, here's a patch which
On Sun, 18 Mar 2001, Andrew Morton wrote:
I'm planning on poking through everything which has been
identified as a posible problem. But I won't start for
several weeks - give the maintainers (if any) time to
address these things.
I took a look at the ISDN issues, here's a patch which
Could people (particularly the affected maintainers) please look over the
appended patch, which I'm planning to submit to Linus at an appropriate
time.
It contains a couple of small Makefile fixes, particularly
o $(list-multi) is supposed to list composite modules, i.e. modules
which are
Could people (particularly the affected maintainers) please look over the
appended patch, which I'm planning to submit to Linus at an appropriate
time.
It contains a couple of small Makefile fixes, particularly
o $(list-multi) is supposed to list composite modules, i.e. modules
which are
On Tue, 13 Feb 2001 [EMAIL PROTECTED] wrote:
> SMP machine, 2x P3/700 on an Abit VP6.
> Never any trouble with the earlier 2.2.19pre's.
>
> a strace shows the hang to be in the delete_module("hisax") call.
I got another report of the same problem already. I'll try to sort it out
tomorrow.
On Tue, 13 Feb 2001 [EMAIL PROTECTED] wrote:
SMP machine, 2x P3/700 on an Abit VP6.
Never any trouble with the earlier 2.2.19pre's.
a strace shows the hang to be in the delete_module("hisax") call.
I got another report of the same problem already. I'll try to sort it out
tomorrow.
What
On Sun, 11 Feb 2001, Kurt Roeckx wrote:
> I suddenly started to get those oopses. It didn't seem to cause
> any problems tho.
> Feb 11 15:04:01 Q kernel: Call Trace: [cached_lookup+14/80]
> [path_walk+1337/1944] [getname+91/152] [__user_walk+58/84]
> [sys_newstat+21/108]
> [system_call+51/64]
On Sun, 11 Feb 2001, Kurt Roeckx wrote:
I suddenly started to get those oopses. It didn't seem to cause
any problems tho.
Feb 11 15:04:01 Q kernel: Call Trace: [cached_lookup+14/80]
[path_walk+1337/1944] [getname+91/152] [__user_walk+58/84]
[sys_newstat+21/108]
[system_call+51/64]
On Wed, 7 Feb 2001, David Woodhouse wrote:
> [EMAIL PROTECTED] said:
> > On one of my linux boxen, that is used as an ISDN router after a 3
> > days of up time I get this:
>
> Read http://www.tux.org/lkml/#s4-3
>
> Particularly the "Don't even bother..." part.
The Call Trace was decoded by
On Wed, 7 Feb 2001, Linus Torvalds wrote:
> No. The optimization is entirely legal - but the fact that
> "constant_test_bit()" uses a "volatile unsigned int *" is the reason why
> gcc thinks it can't optimize it.
This thing did attract me somewhat and I decided to learn a little about
On Wed, 7 Feb 2001, David Woodhouse wrote:
[EMAIL PROTECTED] said:
On one of my linux boxen, that is used as an ISDN router after a 3
days of up time I get this:
Read http://www.tux.org/lkml/#s4-3
Particularly the "Don't even bother..." part.
The Call Trace was decoded by klogd,
On Fri, 2 Feb 2001, infernix wrote:
> However, the patch hasn't been implemented yet, neither in 2.4.1 or in
> 2.4.1-ac1, because the obvious "HACK,HACK,HACK" sentence is still present :)
> Could someone see to it that this mail reaches the kernel's isdn_ppp.c
> maintainer and get this thing
On Fri, 2 Feb 2001, infernix wrote:
However, the patch hasn't been implemented yet, neither in 2.4.1 or in
2.4.1-ac1, because the obvious "HACK,HACK,HACK" sentence is still present :)
Could someone see to it that this mail reaches the kernel's isdn_ppp.c
maintainer and get this thing
On 18 Jan 2001, Kai Henningsen wrote:
> > This info is just plain wrong. Unfortunately, ISDN syncPPP isn't using the
> > generic PPP layer yet.
>
> So, is this still planned? Any sort of timeline?
Yes, however, it's always planned to dump the old ISDN link layer at some
point and switch over
On 18 Jan 2001, Kai Henningsen wrote:
This info is just plain wrong. Unfortunately, ISDN syncPPP isn't using the
generic PPP layer yet.
So, is this still planned? Any sort of timeline?
Yes, however, it's always planned to dump the old ISDN link layer at some
point and switch over to a
On Tue, 23 Jan 2001, Ingo Oeser wrote:
> To quote drivers/isdn/hisax/config.c:1710-1713
> static struct pci_device_id hisax_pci_tbl[] __initdata = {
> #ifdef CONFIG_HISAX_FRTIZPCI
> {PCI_VENDOR_ID_AVM, PCI_DEVICE_ID_AVM_FRITZ, PCI_ANY_ID,
>PCI_ANY_ID},
> #endif
>
> To
On Tue, 23 Jan 2001, Ingo Oeser wrote:
To quote drivers/isdn/hisax/config.c:1710-1713
static struct pci_device_id hisax_pci_tbl[] __initdata = {
#ifdef CONFIG_HISAX_FRTIZPCI
{PCI_VENDOR_ID_AVM, PCI_DEVICE_ID_AVM_FRITZ, PCI_ANY_ID,
PCI_ANY_ID},
#endif
To quote my
On Wed, 17 Jan 2001, Derek Wildstar wrote:
> With 2.4.0 thru 2.4.1-pre8 (could possibly be sooner than 2.4.0)
>
> PCMCIA_CONFIG_NETCARD is getting defined with CONFIG_PCMCIA, even when no
> PCMCIA net cards are selected:
>
> 458 # PCMCIA network device support
> 459 #
> 460
On Wed, 17 Jan 2001, Derek Wildstar wrote:
With 2.4.0 thru 2.4.1-pre8 (could possibly be sooner than 2.4.0)
PCMCIA_CONFIG_NETCARD is getting defined with CONFIG_PCMCIA, even when no
PCMCIA net cards are selected:
458 # PCMCIA network device support
459 #
460
On 13 Jan 2001, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Joe Pranevich) wrote on 06.01.01 in
><[EMAIL PROTECTED]>:
>
> >much of the code, including a long awaited combination of the PPP
> >layers from the ISDN layer and the serial device PPP layer, such as
>
> I've heard about that
On Mon, 15 Jan 2001, Ronny Buchmann wrote:
> i have the following problem with kernel 2.4.0 (also with -ac6):
>
> kernel BUG at slab.c:1095!
> invalid operand:
> CPU: 0
I could reproduce the problem, the appended patch fixes it here. Linus,
could you please apply this for 2.4.1?
> ..
On 13 Jan 2001, Kai Henningsen wrote:
[EMAIL PROTECTED] (Joe Pranevich) wrote on 06.01.01 in
[EMAIL PROTECTED]:
much of the code, including a long awaited combination of the PPP
layers from the ISDN layer and the serial device PPP layer, such as
I've heard about that before, but
On Mon, 15 Jan 2001, Ronny Buchmann wrote:
i have the following problem with kernel 2.4.0 (also with -ac6):
kernel BUG at slab.c:1095!
invalid operand:
CPU: 0
I could reproduce the problem, the appended patch fixes it here. Linus,
could you please apply this for 2.4.1?
..
(if
On Wed, 10 Jan 2001, rdunlap wrote:
> Here's a patch to 2.2.19-pre7 that is essentially a backport of the
> 2.4.0 gate-A20 code.
>
> This speeds up booting on my fast-A20 board (Celeron 500 MHz, no KBC)
> from 2 min:15 seconds to .
>
> Kai, you reported that your system was OK with
Obvious, I guess.
--Kai
diff -ur linux-2.4.1-pre2/net/sunrpc/sunrpc_syms.c
linux-2.4.1-pre2-makefixes-3/net/sunrpc/sunrpc_syms.c
--- linux-2.4.1-pre2/net/sunrpc/sunrpc_syms.c Sat Apr 22 01:08:52 2000
+++ linux-2.4.1-pre2-makefixes-3/net/sunrpc/sunrpc_syms.c Fri Jan 12 01:00:40
+2001
Obvious, I guess.
--Kai
diff -ur linux-2.4.1-pre2/net/sunrpc/sunrpc_syms.c
linux-2.4.1-pre2-makefixes-3/net/sunrpc/sunrpc_syms.c
--- linux-2.4.1-pre2/net/sunrpc/sunrpc_syms.c Sat Apr 22 01:08:52 2000
+++ linux-2.4.1-pre2-makefixes-3/net/sunrpc/sunrpc_syms.c Fri Jan 12 01:00:40
+2001
On Sat, 6 Jan 2001, Daniel Stodden wrote:
> --- linux-2.4/drivers/isdn/hisax/Makefile.orig Sat Jan 6 02:47:31 2001
> +++ linux-2.4/drivers/isdn/hisax/Makefile Sat Jan 6 02:21:22 2001
> @@ -34,7 +34,7 @@
> hisax-objs-$(CONFIG_HISAX_ASUSCOM) += asuscom.o isac.o arcofi.o hscx.o
>
On Sat, 6 Jan 2001, Daniel Stodden wrote:
--- linux-2.4/drivers/isdn/hisax/Makefile.orig Sat Jan 6 02:47:31 2001
+++ linux-2.4/drivers/isdn/hisax/Makefile Sat Jan 6 02:21:22 2001
@@ -34,7 +34,7 @@
hisax-objs-$(CONFIG_HISAX_ASUSCOM) += asuscom.o isac.o arcofi.o hscx.o
On Sat, 6 Jan 2001, Jochen Friedrich wrote:
> Hi,
>
> problem is that CONFIG_PCMCIA_NETCARD=y, although all drivers are
> compiled as modules, so there's no drivers/net/pcmcia/pcmcia_net.o...
This should fix it.
--- drivers/net/Makefile% Fri Jan 5 15:10:11 2001
+++ drivers/net/Makefile
On Sat, 6 Jan 2001, Jochen Friedrich wrote:
Hi,
problem is that CONFIG_PCMCIA_NETCARD=y, although all drivers are
compiled as modules, so there's no drivers/net/pcmcia/pcmcia_net.o...
This should fix it.
--- drivers/net/Makefile% Fri Jan 5 15:10:11 2001
+++ drivers/net/Makefile
On Fri, 5 Jan 2001, David S. Miller wrote:
> The sparc64 config should never allow you to build the amd7930 and
> dbri sbus sound drivers, that is a bug, and I'll fix that.
However, there's supposedly the same problem for sparc32, because the ISDN
support for the amd7930 apparantly never worked
On Fri, 5 Jan 2001, David S. Miller wrote:
The sparc64 config should never allow you to build the amd7930 and
dbri sbus sound drivers, that is a bug, and I'll fix that.
However, there's supposedly the same problem for sparc32, because the ISDN
support for the amd7930 apparantly never worked
On Wed, 3 Jan 2001, Andrea Baldoni wrote:
> The iprofd contained in isdnutils 3.0 use the same buffer and buffer size
> in GETting and SETting via IOCTL IIOC[GS]ETPRF the virtual modem profiles.
>
> The kernel use different sizes, so iprofd set incorrect data, resulting in a
> hang of the ttyI
On 3 Jan 2001, Eric W. Biederman wrote:
> Kai Germaschewski <[EMAIL PROTECTED]> writes:
>
> > I think the problem was that we relied on divert_if being initialized to
> > zero automatically, which didn't happen because it was not declared static
> > and theref
On 3 Jan 2001, Eric W. Biederman wrote:
Kai Germaschewski [EMAIL PROTECTED] writes:
I think the problem was that we relied on divert_if being initialized to
zero automatically, which didn't happen because it was not declared static
and therefore not in .bss (*is this true?*).
All
On Wed, 3 Jan 2001, Andrea Baldoni wrote:
The iprofd contained in isdnutils 3.0 use the same buffer and buffer size
in GETting and SETting via IOCTL IIOC[GS]ETPRF the virtual modem profiles.
The kernel use different sizes, so iprofd set incorrect data, resulting in a
hang of the ttyI from 1
On Tue, 2 Jan 2001, Gerold Jury wrote:
> I have reversed the patches part by part, the only thing that makes a
> difference is the diversion services.
> The reason for this remains unknown for me.
I think I found it. Could everybody who was getting the crash on ISDN line
hangup try if the
On Tue, 2 Jan 2001, Thorsten Kranzkowski wrote:
> On Tue, Jan 02, 2001 at 03:51:34AM +0100, Gerold Jury wrote:
> > The ISDN changes for the HISAX drivers
> > that came in since test12 have introduced a bug that causes a
> > AIEE-something and a complete kernel hang when i hangup the isdn line.
>
On Tue, 2 Jan 2001, Andreas Jellinghaus wrote:
> modules for pcmcia network cards are not build by the kernel.
I just tried, and I don't see this problem. What's your .config?
> subdir-$(CONFIG_PCMCIA) += pcmcia
>
> should be
>
> ifeq ($(CONFIG_PCMCIA),y)
> subdir-y += pcmcia
> subdir-m
On Tue, 2 Jan 2001, Andreas Jellinghaus wrote:
modules for pcmcia network cards are not build by the kernel.
I just tried, and I don't see this problem. What's your .config?
subdir-$(CONFIG_PCMCIA) += pcmcia
should be
ifeq ($(CONFIG_PCMCIA),y)
subdir-y += pcmcia
subdir-m +=
On Tue, 2 Jan 2001, Thorsten Kranzkowski wrote:
On Tue, Jan 02, 2001 at 03:51:34AM +0100, Gerold Jury wrote:
The ISDN changes for the HISAX drivers
that came in since test12 have introduced a bug that causes a
AIEE-something and a complete kernel hang when i hangup the isdn line.
I also
On Tue, 2 Jan 2001, Gerold Jury wrote:
I have reversed the patches part by part, the only thing that makes a
difference is the diversion services.
The reason for this remains unknown for me.
I think I found it. Could everybody who was getting the crash on ISDN line
hangup try if the
On Sat, 23 Dec 2000, ebi4 wrote:
> ld: cannot open drivers/ieee1394/ieee1394.a: No such file or directory
> make: *** [vmlinux] Error 1
I sent the following patch to Linus already. It should fix the problem.
--Kai
diff -ur linux-2.4.0-test13-pre3/drivers/ieee1394/Makefile
On Sat, 23 Dec 2000, ebi4 wrote:
ld: cannot open drivers/ieee1394/ieee1394.a: No such file or directory
make: *** [vmlinux] Error 1
I sent the following patch to Linus already. It should fix the problem.
--Kai
diff -ur linux-2.4.0-test13-pre3/drivers/ieee1394/Makefile
On Sat, 16 Dec 2000, Gunther Mayer wrote:
> apply this patch if like to fix this obvious error
> with "make xconfig" on plain tree:
> ./tkparse < ../arch/i386/config.in >> kconfig.tk
> drivers/isdn/Config.in: 98: can't handle dep_bool/dep_mbool/dep_tristate
>condition
>
On Sat, 16 Dec 2000, Gunther Mayer wrote:
apply this patch if like to fix this obvious error
with "make xconfig" on plain tree:
./tkparse ../arch/i386/config.in kconfig.tk
drivers/isdn/Config.in: 98: can't handle dep_bool/dep_mbool/dep_tristate
condition
make[1]: ***
On Sun, 10 Dec 2000, Mohammad A. Haque wrote:
> More fixes. Ignore previous.
diff -urw linux-2.4.0-test12.old/drivers/atm/ambassador.c
linux-2.4.0-test12/drivers/atm/ambassador.c
--- linux-2.4.0-test12.old/drivers/atm/ambassador.c Fri Jul 7 00:37:24 2000
+++
On Sun, 10 Dec 2000, Mohammad A. Haque wrote:
More fixes. Ignore previous.
diff -urw linux-2.4.0-test12.old/drivers/atm/ambassador.c
linux-2.4.0-test12/drivers/atm/ambassador.c
--- linux-2.4.0-test12.old/drivers/atm/ambassador.c Fri Jul 7 00:37:24 2000
+++
On Thu, 7 Dec 2000, Russell King wrote:
> Linus Torvalds writes:
> > - me: UHCI drivers really need to enable bus mastering.
>
> But it'll already be turned on if pci_assign_unassigned_resources() is
> called. This calls pdev_enable_device for every single device, which
> turns on the bus
On Thu, 7 Dec 2000, Russell King wrote:
Linus Torvalds writes:
- me: UHCI drivers really need to enable bus mastering.
But it'll already be turned on if pci_assign_unassigned_resources() is
called. This calls pdev_enable_device for every single device, which
turns on the bus master
1 - 100 of 120 matches
Mail list logo
