From: Stuart MacDonald <[EMAIL PROTECTED]>
I am no longer with CTI. The Support Department will handle all
inquiries regarding the WH.
Signed-off-by: Stuart MacDonald <[EMAIL PROTECTED]>
---
Applies to 2.6.21.
I'm also not subscribed to the list anymore so comments must be
r
From: Stuart MacDonald [EMAIL PROTECTED]
I am no longer with CTI. The Support Department will handle all
inquiries regarding the WH.
Signed-off-by: Stuart MacDonald [EMAIL PROTECTED]
---
Applies to 2.6.21.
I'm also not subscribed to the list anymore so comments must be
replied to me directly
From: On Behalf Of Satyam Sharma
> readable and obvious at first glance itself. For example, consider:
^^^
>
> if (veryverylengthycondition1 &&
> smallcond2 &&
> (conditionnumber3a ||
> condition3b)) {
>
From: On Behalf Of Satyam Sharma
readable and obvious at first glance itself. For example, consider:
^^^
if (veryverylengthycondition1
smallcond2
(conditionnumber3a ||
condition3b)) {
...
We have been investigating Linux support for the following chips:
Zilog Z16C30 (also known as the "USC" or just 16C30)
Zilog Z16C32 (also known as the "IUSC" or just 16C32)
http://www.zilog.com/products/family.asp?fam=200
Infineon"SEROCCO" family
We have been investigating Linux support for the following chips:
Zilog Z16C30 (also known as the USC or just 16C30)
Zilog Z16C32 (also known as the IUSC or just 16C32)
http://www.zilog.com/products/family.asp?fam=200
InfineonSEROCCO family
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
> On Tue, 10 Apr 2007 15:45:33 -0400 Stuart MacDonald wrote:
> > Where would be the appropriate place to submit this as a feature
> > request, to complement "git bisect visualize"; git, LKML or
> somewhere
> > else? I
From: Paolo Ornati [mailto:[EMAIL PROTECTED]
> I think this should work:
>
> 1) look at "git-bisect log" and take the last good/bad pair
>
> 2) "cat .git/refs/heads/bisect" to see where you are now
>
> 3) git-log --pretty=oneline GOOD..BAD
>
> 4) search for the current commit (found in #2)
From: Paolo Ornati [mailto:[EMAIL PROTECTED]
I think this should work:
1) look at git-bisect log and take the last good/bad pair
2) cat .git/refs/heads/bisect to see where you are now
3) git-log --pretty=oneline GOOD..BAD
4) search for the current commit (found in #2) with
From: Randy Dunlap [mailto:[EMAIL PROTECTED]
On Tue, 10 Apr 2007 15:45:33 -0400 Stuart MacDonald wrote:
Where would be the appropriate place to submit this as a feature
request, to complement git bisect visualize; git, LKML or
somewhere
else? I'm picturing an ncurses/menuconfig-style app
The git mailing list seems to be git-dev, and I can't find a git-users
list anywhere. If there's somewhere better to ask this, please point
me in the right direction.
I've been learning git over the last few days. Specifically, I'm
trying out git bisect to locate a change between 2.6.17 and
The git mailing list seems to be git-dev, and I can't find a git-users
list anywhere. If there's somewhere better to ask this, please point
me in the right direction.
I've been learning git over the last few days. Specifically, I'm
trying out git bisect to locate a change between 2.6.17 and
From: On Behalf Of Aaron Lehmann
> I've been able to narrow it down to the Realtek Ethernet card. I can't
> reproduce the problem using onboard Ethernet, whereas the Realtek card
> causes trouble in any slot. However, I still don't know whether it's a
> hardware or software issue, or whether it's
From: On Behalf Of Aaron Lehmann
I've been able to narrow it down to the Realtek Ethernet card. I can't
reproduce the problem using onboard Ethernet, whereas the Realtek card
causes trouble in any slot. However, I still don't know whether it's a
hardware or software issue, or whether it's
From: Oliver Neukum [mailto:[EMAIL PROTECTED]
> Am Mittwoch, 28. März 2007 15:10 schrieb Stuart MacDonald:
> > > We find that a failure in open() leads to release_dev()
> being called.
> > > release_dev() calls close():
> > >
> > > if (tty->d
From: [EMAIL PROTECTED]
> in tty_io.c::tty_open():
[snip]
> We find that a failure in open() leads to release_dev() being called.
> release_dev() calls close():
>
> if (tty->driver->close)
> tty->driver->close(tty, filp);
>
> So we have a file that's closed although open()
From: [EMAIL PROTECTED]
in tty_io.c::tty_open():
[snip]
We find that a failure in open() leads to release_dev() being called.
release_dev() calls close():
if (tty-driver-close)
tty-driver-close(tty, filp);
So we have a file that's closed although open() never
From: Oliver Neukum [mailto:[EMAIL PROTECTED]
Am Mittwoch, 28. März 2007 15:10 schrieb Stuart MacDonald:
We find that a failure in open() leads to release_dev()
being called.
release_dev() calls close():
if (tty-driver-close)
tty-driver-close(tty, filp
From: Richard Knutsson [mailto:[EMAIL PROTECTED]
Okay by me. Thanks Richard.
Signed-off-by: Stuart MacDonald <[EMAIL PROTECTED]>
..Stu
> Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
> ---
> Compile-tested with "allyes", "allmod" & "alln
From: Richard Knutsson [mailto:[EMAIL PROTECTED]
Okay by me. Thanks Richard.
Signed-off-by: Stuart MacDonald [EMAIL PROTECTED]
..Stu
Signed-off-by: Richard Knutsson [EMAIL PROTECTED]
---
Compile-tested with allyes, allmod allno on i386
diff --git a/drivers/usb/serial/whiteheat.c
b
From: On Behalf Of FN
> Currently I face the following situation -- I try to build 2 drivers
> from the same Makefile
> ---
> CWD := $(shell pwd)
> obj-m := driver1.o driver2.o
> driver1-y := d1/d2/d3/f1.o d1/d2/f2.o
> driver2-y := d1/d5/file1.o d1/d6/file2.o
CFLAGS_f1.o := -DMASK=0x123
From: On Behalf Of FN
Currently I face the following situation -- I try to build 2 drivers
from the same Makefile
---
CWD := $(shell pwd)
obj-m := driver1.o driver2.o
driver1-y := d1/d2/d3/f1.o d1/d2/f2.o
driver2-y := d1/d5/file1.o d1/d6/file2.o
CFLAGS_f1.o := -DMASK=0x123
From: Russell King [mailto:[EMAIL PROTECTED]
> After experimenting here, it turns out the reason is you're trying to
> configure a port with a zero base baud. Unfortunately, it starts off
> as zero.
That explains why adding the fourport module fixed Rob's issue, as the
fourport code sets a
From: Russell King [mailto:[EMAIL PROTECTED]
After experimenting here, it turns out the reason is you're trying to
configure a port with a zero base baud. Unfortunately, it starts off
as zero.
That explains why adding the fourport module fixed Rob's issue, as the
fourport code sets a uartclk
From: On Behalf Of Rob Prowel
> Russell King wrote:
> > You don't even need to do that. Just configure SERIAL_8250_NR_UARTS
> > and SERIAL_8250_RUNTIME_UARTS appropriately for your
> system. There's
> > absolutely no need to build any of the additional modules.
> >
> Unfortunately what I'm
From: On Behalf Of Rob Prowel
Russell King wrote:
You don't even need to do that. Just configure SERIAL_8250_NR_UARTS
and SERIAL_8250_RUNTIME_UARTS appropriately for your
system. There's
absolutely no need to build any of the additional modules.
Unfortunately what I'm seeing in
From: On Behalf Of v j
> On 2/14/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > We seem to have different definitions of open and closed.
>
> Open = 3rd party Linux drivers can be loaded. Closed = No third party
> Linux drivers can be loaded.
That is BSD-openness; the freedom to do anything
From: On Behalf Of v j
On 2/14/07, Randy Dunlap [EMAIL PROTECTED] wrote:
We seem to have different definitions of open and closed.
Open = 3rd party Linux drivers can be loaded. Closed = No third party
Linux drivers can be loaded.
That is BSD-openness; the freedom to do anything with the
From: On Behalf Of Joe Barr
> I'm forwarding this post by the author of a great little program for
> digital amateur radio on Linux, because I'm curious whether or not the
> problem he is seeing can be resolved outside the kernel.
From: w1hkj [mailto:[EMAIL PROTECTED]
> I am now convinced that
From: On Behalf Of Joe Barr
I'm forwarding this post by the author of a great little program for
digital amateur radio on Linux, because I'm curious whether or not the
problem he is seeing can be resolved outside the kernel.
From: w1hkj [mailto:[EMAIL PROTECTED]
I am now convinced that the
From: On Behalf Of Luke Kenneth Casson Leighton
> Subject: Re: tty line discipline driver advice sought, to do
> a 1-byte header and 2-byte CRC checksum on GSM data
drivers/char/n_tty.c
include/linux/tty_ldisc.h
include/linux/tty_flip.h
include/linux/tty.h
I can't see a reason why your code
From: On Behalf Of Luke Kenneth Casson Leighton
Subject: Re: tty line discipline driver advice sought, to do
a 1-byte header and 2-byte CRC checksum on GSM data
drivers/char/n_tty.c
include/linux/tty_ldisc.h
include/linux/tty_flip.h
include/linux/tty.h
I can't see a reason why your code
From: Jacques Goldberg
> To be ugly or to never be up to date, that's the question.
> We did patch 8250_pci.c but there is no way to build a
> stable list of
> the devices to be handled that way.
> We will thus spend some time on the hot unplug solution.
I think what you want might be
From: Jacques Goldberg
To be ugly or to never be up to date, that's the question.
We did patch 8250_pci.c but there is no way to build a
stable list of
the devices to be handled that way.
We will thus spend some time on the hot unplug solution.
I think what you want might be
From: [EMAIL PROTECTED]
> Remember that Linus has *always* reserved the right to change his mind
> if a "sufficiently good" idea came along. So it's not as
> much a "The Emperor
> Penguin Has Decreed" as "Nobody's made a sufficiently
> convincing case to Linus".
> (And I've never seen Linus
From: [EMAIL PROTECTED]
> I'd vote for Documentation/Policies
I'll second.
..Stu
-
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
From: [EMAIL PROTECTED]
I'd vote for Documentation/Policies
I'll second.
..Stu
-
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
From: [EMAIL PROTECTED]
Remember that Linus has *always* reserved the right to change his mind
if a sufficiently good idea came along. So it's not as
much a The Emperor
Penguin Has Decreed as Nobody's made a sufficiently
convincing case to Linus.
(And I've never seen Linus claim to be
From: Greg Folkert [mailto:[EMAIL PROTECTED]
> On Thu, 2005-02-24 at 15:03 -0500, Stuart MacDonald wrote:
> > Recently I ran across
> >
> > http://groups.google.ca/groups?hl=en=lang_en=off=
> > 1033074519.2698.5.
> > camel%40localhost.localdomain
> >
&g
Recently I ran across
http://groups.google.ca/groups?hl=en=lang_en=off=1033074519.2698.5.
camel%40localhost.localdomain
Is there a collection point for Linus' decrees?
The LSB (http://www.linuxbase.org/) seems to be mostly involved with
how a distro is laid out, and not much to do with the
Recently I ran across
http://groups.google.ca/groups?hl=enlr=lang_ensafe=offselm=1033074519.2698.5.
camel%40localhost.localdomain
Is there a collection point for Linus' decrees?
The LSB (http://www.linuxbase.org/) seems to be mostly involved with
how a distro is laid out, and not much to do with
From: Greg Folkert [mailto:[EMAIL PROTECTED]
On Thu, 2005-02-24 at 15:03 -0500, Stuart MacDonald wrote:
Recently I ran across
http://groups.google.ca/groups?hl=enlr=lang_ensafe=offselm=
1033074519.2698.5.
camel%40localhost.localdomain
Is there a collection point for Linus
From: "James R Bruce" <[EMAIL PROTECTED]>
> The overall size of the circular buffer would have to be decreased
> too, but that's more of a hack to fix it now; Which I guess is what it
> comes to.
I see what you're saying; AFAIUnderstand, the low latency patches
bypass the circular buffer. Or
From: James R Bruce [EMAIL PROTECTED]
The overall size of the circular buffer would have to be decreased
too, but that's more of a hack to fix it now; Which I guess is what it
comes to.
I see what you're saying; AFAIUnderstand, the low latency patches
bypass the circular buffer. Or make it
From: "Jonathan Lundell" <[EMAIL PROTECTED]>
> The other CPU servicing the interrupt, was the question. cli()
> doesn't affect that. This could presumably happen if shutdown() gets
> run on a non-interrupt-servicing CPU, or if interrupts are
> dynamically routed (eg round-robin).
Ah. Missed
From: "kees" <[EMAIL PROTECTED]>
> What may happen on a SMP machine if a serial port has been closed and the
> closing stage is at shutdown() in serial.c in the call to free_IRQ and
> BEFORE the IRQ is really shutdown, a new character arrives which causes an
> IRQ? Is it possible that the OTHER
From: kees [EMAIL PROTECTED]
What may happen on a SMP machine if a serial port has been closed and the
closing stage is at shutdown() in serial.c in the call to free_IRQ and
BEFORE the IRQ is really shutdown, a new character arrives which causes an
IRQ? Is it possible that the OTHER cpu
From: Jonathan Lundell [EMAIL PROTECTED]
The other CPU servicing the interrupt, was the question. cli()
doesn't affect that. This could presumably happen if shutdown() gets
run on a non-interrupt-servicing CPU, or if interrupts are
dynamically routed (eg round-robin).
Ah. Missed that.
Hm.
From: "Marcelo Tosatti" <[EMAIL PROTECTED]>
> The problem is that we _cannot_ base ourselves simply on practical results
> from a _limited_ amount of workloads. Also remember the tests we (at least
> I do) are benchmarks which try to use all resources all the time upon
> completion.
Isn't this
From: Marcelo Tosatti [EMAIL PROTECTED]
The problem is that we _cannot_ base ourselves simply on practical results
from a _limited_ amount of workloads. Also remember the tests we (at least
I do) are benchmarks which try to use all resources all the time upon
completion.
Isn't this the point
From: "Val Henson" <[EMAIL PROTECTED]>
> Anyone know where Ted Tso is? He hasn't posted in several weeks.
Haven't heard from him in a while. I've got a patch or two pending
as well, one of which modifies this code to check for 16c2850s.
Usually he just says he's really busy.
> > Kernel
From: Val Henson [EMAIL PROTECTED]
Anyone know where Ted Tso is? He hasn't posted in several weeks.
Haven't heard from him in a while. I've got a patch or two pending
as well, one of which modifies this code to check for 16c2850s.
Usually he just says he's really busy.
Kernel version?
From: "Val Henson" <[EMAIL PROTECTED]>
> Serial driver version 5.05a (2001-03-20) with MANY_PORTS SHARE_IRQ
> SERIAL_PCI enabled
Hmm. I've been looking at 5.05 (from http://serial.sourceforge.net),
I'm getting 2.4.4 and 2.4.5-pre2 to see what's in there.
> "Go kablooey" means that all serial
From: Val Henson [EMAIL PROTECTED]
Serial driver version 5.05a (2001-03-20) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
Hmm. I've been looking at 5.05 (from http://serial.sourceforge.net),
I'm getting 2.4.4 and 2.4.5-pre2 to see what's in there.
Go kablooey means that all serial output
From: "Val Henson" <[EMAIL PROTECTED]>
> This fixes a bug in the autoconfig_startech_uarts function in
> serial.c. The problem is that 0's are written to the baud rate
> registers in order to detect an XR16C850 or XR16C854. This makes the
> Exar ST16C654 go kablooey. Saving and restoring the
From: Val Henson [EMAIL PROTECTED]
This fixes a bug in the autoconfig_startech_uarts function in
serial.c. The problem is that 0's are written to the baud rate
registers in order to detect an XR16C850 or XR16C854. This makes the
Exar ST16C654 go kablooey. Saving and restoring the baud rate
I had similar questions recently when I was doing some
hacking; these are my guesses:
From: ; "Eliel" <[EMAIL PROTECTED]>
> Hello, I would like to know why you put this two functions:
> void scheduling_functions_start_here(void) { }
> ...
> void scheduling_functions_end_here(void) { }
Just as
I had similar questions recently when I was doing some
hacking; these are my guesses:
From: Sardaons; "Eliel" [EMAIL PROTECTED]
Hello, I would like to know why you put this two functions:
void scheduling_functions_start_here(void) { }
...
void scheduling_functions_end_here(void) { }
Just as
From: "Thomas Foerster" <[EMAIL PROTECTED]>
> But suddenly the box was offline. One technical assistant from our ISP
tried to reboot
> our server (he couldn't tell me if there had been any messages on the
screen), but the
> system always hangs on
>
> Freeing unused kernel memory: xxk freed
I
From: "Thomas Foerster" [EMAIL PROTECTED]
But suddenly the box was offline. One technical assistant from our ISP
tried to reboot
our server (he couldn't tell me if there had been any messages on the
screen), but the
system always hangs on
Freeing unused kernel memory: xxk freed
I have a
From: "Venkatesh Ramamurthy" <[EMAIL PROTECTED]>
> http://www.zdnet.com/enterprise/stories/main/0,10228,2692987,00.html
"As such, clients will not be allowed to alter the code in any form and
may not give any other party access to any aspect of that code."
Does this preclude one reading the
From: "Venkatesh Ramamurthy" [EMAIL PROTECTED]
http://www.zdnet.com/enterprise/stories/main/0,10228,2692987,00.html
"As such, clients will not be allowed to alter the code in any form and
may not give any other party access to any aspect of that code."
Does this preclude one reading the source
From: "Matthias Andree" <[EMAIL PROTECTED]>
> 3. patch the kernel with that 2.2.18-fix-serial-5.05-pre.patch, it takes
>a high fuzz factor (try patch -p1 -F10)
> 4. unpack serial-5.05
I don't have permission to fetch
2.2.18-fix-serial-5.05-pre.patch
at
From: "Matthias Andree" [EMAIL PROTECTED]
3. patch the kernel with that 2.2.18-fix-serial-5.05-pre.patch, it takes
a high fuzz factor (try patch -p1 -F10)
4. unpack serial-5.05
I don't have permission to fetch
2.2.18-fix-serial-5.05-pre.patch
at
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> Does that mean SPARC has a conflict between the 8250/16x50 driver and the
> Zilog driver? If so, the latter should probably move (ttyZ is still an
> unused name.)
If there's a conflict it would be with the minor numbers, which
I haven't been able to
65 matches
Mail list logo
