>- change parport_pc so that it doesn't request parport_serial at
> init. In this case, how will parport_serial get loaded at all?
> Perhaps with some recommended /etc/modules.conf lines (perhaps
> parport_lowlevel{1,2,3,...})?
This would be a bit bad, because it would require people to guess
>> It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can
>> insert calls to 'memcpy'
>
>IMHO omitting -fno-builtin when compiling the kernel was always a risky
>proposition... Since we provide our own copies of many of the builtins
>[which are used in the kernel] anyway... why
Has anybody used this successfully in a recent kernel? With 2.4.5 it seems to
detect the device successfully:
empeg.c: v1.0.0 Greg Kroah-Hartman <[EMAIL PROTECTED]>, Gary Brubaker
<[EMAIL PROTECTED]>
empeg.c: USB Empeg Mark I/II Driver
usbserial.c: Empeg converter detected
usbserial.c: Empeg c
>Suppose the signal handler modifies this context frame for example by
>storing into the PC slot address of the panic routine
>then when handler will exit panic will be called with obvious results.
You can't execute panic() - or any other kernel function - in user mode.
The application can write
>--- include/asm-arm/atomic.h.old Sun May 27 22:30:58 2001
>+++ include/asm-arm/atomic.h Sun May 27 22:58:20 2001
>@@ -12,6 +12,7 @@
> * 13-04-1997 RMK Made functions atomic!
> * 07-12-1997 RMK Upgraded for v2.1.
> * 26-08-1998 PJB Added #ifdef __KERN
>I am trying to use the data port of parallel port to receive data, so I=
> set the bit 5 of the control port to enable the bi-directional port, b=
>ut it doesn't work. My parallel supports SPP/EPP/ECP mode, does it sup=
>port bi-directional mode? if yes, how can I config it?
You might have to
>I attached the problem occured with parport and devfs.
>I don't exactly know where the problem in the parport source
>is. If someone has a patch for it, I will test it.
I don't think this is a bug. You need to load the `lp' module.
p.
-
To unsubscribe from this list: send the line "unsubscri
>And of course since much of the code in the kernel is built on the
>copy a good example neglecting the locking without a big comment,
>invites trouble elsewhere like in elf_load_library. Where we could
>have multiple threads running.
Out of interest: does anything, anywhere, actually use elf_
>There are no gcc 2.97 snapshots that compile the kernel correctly because
>they have the broken bitfield packing ABI change.
Oh right. I didn't know about that particular nicety.
>My belief however is that several million people have gcc 2.96-69+, about 50
>are likely to have random cvs snaps
>Its because you're using a version of gcc which doesn't have
>__builtin_expect (eg, egcs 1.1.2, some versions of gcc 2.95).
No 2.95.x has __builtin_expect. There might be some 2.95-derived GNUpro that
supports it but I doubt anyone is using those to build kernels.
p.
-
To unsubscribe from t
>+Support for Cobalt Micro Server
>+CONFIG_COBALT_MICRO_SERVER
>+ Support for ARM-based Cobalt boxes (they have been bought by Sun and
>+ are now the "Server Appliance Business Unit") including the 2700 series
Aren't those machines MIPS based?
p.
-
To unsubscribe from this list: send the lin
>#include
>#include
>int main ()
>{
>; // contains no C programs,
>}
>and give the command " cc -D__KERNEL__ -I/usr/src/linux/include to compiler
>the program .
You can't mix environments. Either you're building part of the kernel, in which
case you need to use -D__KERNEL__ and headers, o
Cross-compiles need to use the target linker here.
p.
--- linux/drivers/net/Makefile~ Sun Apr 8 17:48:31 2001
+++ linux/drivers/net/Makefile Sun Apr 8 19:31:29 2001
@@ -1445,7 +1445,7 @@
rm -f core *.o *.a *.s
wanpipe.o: $(WANPIPE_OBJS)
- ld -r -o $@ $(WANPIPE_OBJS)
+ $
>I'm not wonderfully impressed with the way that you can't load the FPU
>emulation module on ARM at the moment without having some form of FPU
>emulation in your kernel already, either :)
Floating point on ARM is indeed something of a crock, but that particular case
used to work -- can you tell
>of action to take. Seeing as you work for suse, would you know
>where this 'syscall(3)' interface should be documented? Is it
>supposed to be present in all distro's?
It's documented in the glibc manual. Yes, it should be present in all glibc
based distributions.
p.
-
To unsubscribe fro
>if [ "$CONFIG_PRINTER" != "n" ]; then
>- bool 'Support IEEE1284 status readback' CONFIG_PRINTER_READBACK
>+ bool 'Support IEEE1284 status readback' CONFIG_PARPORT_1284
>fi
This isn't really right. Although it's true that CONFIG_PARPORT_1284 enables
the stuff that used
--- linux/drivers/net/rtl8129.c Sat Nov 4 16:42:22 2000
+++ linux/drivers/net/rtl8129.c Sat Nov 4 16:48:21 2000
@@ -271,7 +271,7 @@ struct rtl8129_private {
unsigned char *tx_bufs; /* Tx bounce buffer region. */
dma_addr_t rx_ring_dma;
dma_addr_t t
The makefile in drivers/net goes like this:
obj-$(CONFIG_SLIP) += slip.o
ifeq ($(CONFIG_SLIP),y)
obj-$(CONFIG_SLIP_COMPRESSED) += slhc.o
else
ifeq ($(CONFIG_SLIP),m)
obj-$(CONFIG_SLIP_COMPRESSED) += slhc.o
endif
endif
CONFIG_SLIP_COMPRESSED is a `bool' value. The way the makefile is w
>Does it? At which point? To me it looks like it calls dev->do_ioctl
>or am I missing something?
It uses SIOCSIFMAP, which (I think) winds up in dev.c here:
case SIOCSIFMAP:
if (dev->set_config) {
if (!netif_device_present(dev))
>Does 'ifconfig eth0 media xxx' wind up calling dev->set_config?
Yes.
p.
-
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/
In message <[EMAIL PROTECTED]>, Russell King wri
tes:
>We already have a standard interface for this, but many drivers do not
>support it. Its called "ifconfig eth0 media xxx":
The Ethtool interface is rather better.
p.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Confusion between `int' and `long int'...
p.
Index: drivers/block/linear.c
===
RCS file: /cvsroot/pub/kernel/armlinux/drivers/block/linear.c,v
retrieving revision 1.7
diff -u -p -u -r1.7 linear.c
--- drivers/block/linear.c 2000
Here's the latest collection of drivers that assumed "char" is always signed.
p.
Index: drivers/net/eepro100.c
===
RCS file: /cvsroot/pub/kernel/armlinux/drivers/net/eepro100.c,v
retrieving revision 1.15
diff -u -p -u -r1.15 eepro10
Some of the joystick drivers weren't including all the headers they needed to
build on ARM.
p.
Index: drivers/char/joystick/gameport.c
===
RCS file: /cvsroot/pub/kernel/armlinux/drivers/char/joystick/gameport.c,v
retrieving revisio
24 matches
Mail list logo
