Re: When the FUD is all around (sniff).
On Tue, 26 Jun 2001 14:33:03 +0200 Alessandro Suardi <[EMAIL PROTECTED]> wrote: > > I have trouble in finding words to describe such blatant ignorance. A Troll ? oh.. geez, this was not something on the internet... -- Fabrice Gautier <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: When the FUD is all around (sniff).
On Tue, 26 Jun 2001 14:33:03 +0200 Alessandro Suardi [EMAIL PROTECTED] wrote: I have trouble in finding words to describe such blatant ignorance. A Troll ? oh.. geez, this was not something on the internet... -- Fabrice Gautier [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Controversy over dynamic linking -- how to end the panic
On Thu, 21 Jun 2001 14:14:42 -0400 "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > > > >As copyright holder of the Linux kernel, Linus is the only person with > >standing to sue for license violation. [...] This means > >that in order for them to lose, a court must rule that module linking > >propagates derivative-work status *and* Linus must reverse himself and > >sue. I always thought that, Linus was not the sole copyright holder on the linux kernel. Hence, didn't think hat he is not the only person to be able to sue. Could not "kernel hacker x" sue if indeed some part of his work was used in (what he assumes to be) non GPL compliant derivative work ? Scenario: hacker X write ethernet driver for card made by constructor Y. Constructor Y provide binary module to exploit super capability of their card. Could hacker X sue company Y ? (well more interresting could be to replace hacker X by company X) -- Fabrice Gautier <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Controversy over dynamic linking -- how to end the panic
On Thu, 21 Jun 2001 14:14:42 -0400 Eric S. Raymond [EMAIL PROTECTED] wrote: As copyright holder of the Linux kernel, Linus is the only person with standing to sue for license violation. [...] This means that in order for them to lose, a court must rule that module linking propagates derivative-work status *and* Linus must reverse himself and sue. I always thought that, Linus was not the sole copyright holder on the linux kernel. Hence, didn't think hat he is not the only person to be able to sue. Could not kernel hacker x sue if indeed some part of his work was used in (what he assumes to be) non GPL compliant derivative work ? Scenario: hacker X write ethernet driver for card made by constructor Y. Constructor Y provide binary module to exploit super capability of their card. Could hacker X sue company Y ? (well more interresting could be to replace hacker X by company X) -- Fabrice Gautier [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PCI: Direct Access and STPC
Hi, I noticed that when building a kernel with CONFIG_PCI_DIRECT and not CONFIG_PCI_BIOS, the kernel doesn't detect any PCI bus when runing on a STPC embeded CPU. The STPC include a PCI chipset but the configuration methods usednin the kernel does not seems to match the STPC docs. The STPC use 0xCF8 and 0xCFC registers to access PCI configuration space. This seems to match the code of pci_conf1_read_config_byte but the sanity_check fail pci_check_direct. The fact is that the north bridge in the STPC have a class code of 0, so is not detected as a host bridge. For my own tests i've removed the sanity check and so i get the following result in /proc/pci: PCI devices found: Bus 0, device 11, function 0: Non-VGA unclassified device: PCI device 100e:0564 (Weitek) (rev 0). Bus 0, device 12, function 0: ISA bridge: PCI device 100e:55cc (Weitek) (rev 0). Bus 0, device 12, function 1: IDE interface: PCI device 100e:55cc (Weitek) (rev 0). I/O at 0xfc00 [0xfc07]. I/O at 0xfc20 [0xfc23]. I/O at 0xfc40 [0xfc47]. I/O at 0xfc60 [0xfc63]. I/O at 0xfc80 [0xfc8f]. I've seen some fixup functions that seems to correct some IDs. I guess in my case I would need one to correct the device CLASS for the north bridge. Is that correct ? Thanks. -- Fabrice Gautier <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PCI: Direct Access and STPC
Hi, I noticed that when building a kernel with CONFIG_PCI_DIRECT and not CONFIG_PCI_BIOS, the kernel doesn't detect any PCI bus when runing on a STPC embeded CPU. The STPC include a PCI chipset but the configuration methods usednin the kernel does not seems to match the STPC docs. The STPC use 0xCF8 and 0xCFC registers to access PCI configuration space. This seems to match the code of pci_conf1_read_config_byte but the sanity_check fail pci_check_direct. The fact is that the north bridge in the STPC have a class code of 0, so is not detected as a host bridge. For my own tests i've removed the sanity check and so i get the following result in /proc/pci: PCI devices found: Bus 0, device 11, function 0: Non-VGA unclassified device: PCI device 100e:0564 (Weitek) (rev 0). Bus 0, device 12, function 0: ISA bridge: PCI device 100e:55cc (Weitek) (rev 0). Bus 0, device 12, function 1: IDE interface: PCI device 100e:55cc (Weitek) (rev 0). I/O at 0xfc00 [0xfc07]. I/O at 0xfc20 [0xfc23]. I/O at 0xfc40 [0xfc47]. I/O at 0xfc60 [0xfc63]. I/O at 0xfc80 [0xfc8f]. I've seen some fixup functions that seems to correct some IDs. I guess in my case I would need one to correct the device CLASS for the north bridge. Is that correct ? Thanks. -- Fabrice Gautier [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial console problems with 2.4.4
On 03 May 2001 02:15:03 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote: > > I get the impression that something in 2.4.3 fixed CREAD handling, and we > started noticing the buggy user space. That's my impression too... > > > I wish I knew where the breakage actually occured. > > > > Just look at this diff on serial.c between 2.4.2 and 2.4.3: > > If it was a real diff between 2.4.2 and 2.4.3 I would agree, however it looks > like your attempt to fix 2.4.3. Err... Yes sorry, in fact this was a workaround proposed by Kanoj, the maintener of serial.c (I think)... Regards. -- Fabrice Gautier <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial console problems with 2.4.4
On 03 May 2001 02:15:03 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote: I get the impression that something in 2.4.3 fixed CREAD handling, and we started noticing the buggy user space. That's my impression too... I wish I knew where the breakage actually occured. Just look at this diff on serial.c between 2.4.2 and 2.4.3: If it was a real diff between 2.4.2 and 2.4.3 I would agree, however it looks like your attempt to fix 2.4.3. Err... Yes sorry, in fact this was a workaround proposed by Kanoj, the maintener of serial.c (I think)... Regards. -- Fabrice Gautier [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: serial console problems with 2.4.4
On 02 May 2001 10:37:21 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Fabrice Gautier <[EMAIL PROTECTED]> writes:
> > So this this probably a sulogin/mingetty problem. They should set the
> > CREAD flag in your tty c_cflag.
> >
> > the patch for busybox repalced the line
> > tty.c_cflag |= HUPCL|CLOCAL
> > by
> > tty.c_cflag |= CREAD|HUPCL|CLOCAL
> >
> > Hope this help.
>
> This part is correct.
>
> However the kernel sets CREAD by default.
Are your sure? Wasn't this the behaviour for 2.4.2 but changed in 2.4.3
> sysvinit (and possibly other inits) clears CREAD.
In my case I was using busybox as init. So there is no sysinit or any other
init called before this line.
> I wish I knew where the breakage actually occured.
Just look at this diff on serial.c between 2.4.2 and 2.4.3:
--- serial.cSat Apr 21 17:22:53 2001
+++ ../../../linux-2.4.2/drivers/char/serial.c Sat Feb 17 01:02:36 2001
@@ -1764,8 +1765,8 @@
/*
* !!! ignore all characters if CREAD is not set
*/
-// if ((cflag & CREAD) == 0)
-// info->ignore_status_mask |= UART_LSR_DR;
+ if ((cflag & CREAD) == 0)
+ info->ignore_status_mask |= UART_LSR_DR;
save_flags(flags); cli();
if (uart_config[info->state->type].flags & UART_STARTECH) {
serial_outp(info, UART_LCR, 0xBF);
--
Fabrice Gautier <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: serial console problems with 2.4.4
On Wed, 02 May 2001 11:54:11 +0200
Reto Baettig <[EMAIL PROTECTED]> wrote:
> Hi
>
> I just installed 2.4.4 on our alpha SMP boxes (ES40) and now I have
> problems with the serial console:
I get same kind of problem when upgrading from 2.4.2 to 2.4.3 and using
busybox as init/getty
The problem was a bug in busybox. The console initialisation code was
not correct.
>
> sulogin does not accept input from the serial line
> mingetty does not accept input from the serial line
> agetty works fine
So this this probably a sulogin/mingetty problem. They should set the
CREAD flag in your tty c_cflag.
the patch for busybox repalced the line
tty.c_cflag |= HUPCL|CLOCAL
by
tty.c_cflag |= CREAD|HUPCL|CLOCAL
Hope this help.
--
Fabrice Gautier <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: serial console problems with 2.4.4
On 02 May 2001 10:37:21 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
Fabrice Gautier [EMAIL PROTECTED] writes:
So this this probably a sulogin/mingetty problem. They should set the
CREAD flag in your tty c_cflag.
the patch for busybox repalced the line
tty.c_cflag |= HUPCL|CLOCAL
by
tty.c_cflag |= CREAD|HUPCL|CLOCAL
Hope this help.
This part is correct.
However the kernel sets CREAD by default.
Are your sure? Wasn't this the behaviour for 2.4.2 but changed in 2.4.3
sysvinit (and possibly other inits) clears CREAD.
In my case I was using busybox as init. So there is no sysinit or any other
init called before this line.
I wish I knew where the breakage actually occured.
Just look at this diff on serial.c between 2.4.2 and 2.4.3:
--- serial.cSat Apr 21 17:22:53 2001
+++ ../../../linux-2.4.2/drivers/char/serial.c Sat Feb 17 01:02:36 2001
@@ -1764,8 +1765,8 @@
/*
* !!! ignore all characters if CREAD is not set
*/
-// if ((cflag CREAD) == 0)
-// info-ignore_status_mask |= UART_LSR_DR;
+ if ((cflag CREAD) == 0)
+ info-ignore_status_mask |= UART_LSR_DR;
save_flags(flags); cli();
if (uart_config[info-state-type].flags UART_STARTECH) {
serial_outp(info, UART_LCR, 0xBF);
--
Fabrice Gautier [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: serial console problems with 2.4.4
On Wed, 02 May 2001 11:54:11 +0200 Reto Baettig [EMAIL PROTECTED] wrote: Hi I just installed 2.4.4 on our alpha SMP boxes (ES40) and now I have problems with the serial console: I get same kind of problem when upgrading from 2.4.2 to 2.4.3 and using busybox as init/getty The problem was a bug in busybox. The console initialisation code was not correct. sulogin does not accept input from the serial line mingetty does not accept input from the serial line agetty works fine So this this probably a sulogin/mingetty problem. They should set the CREAD flag in your tty c_cflag. the patch for busybox repalced the line tty.c_cflag |= HUPCL|CLOCAL by tty.c_cflag |= CREAD|HUPCL|CLOCAL Hope this help. -- Fabrice Gautier [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in serial.c
Same thing for me. I'm using busybox as init/getty/shell. Everything works fine with 2.4.2. With 2.4.3 console output is fine but not input. Thanks -- Fabrice Gautier <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in serial.c
Same thing for me. I'm using busybox as init/getty/shell. Everything works fine with 2.4.2. With 2.4.3 console output is fine but not input. Thanks -- Fabrice Gautier [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
