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
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
SAB/SA
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) wit
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 2.6.18
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 c
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() ne
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: 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
CFL
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 uartcl
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 se
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
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 th
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 shou
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 accom
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 clai
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 htt
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&lr=lang_en&safe=off&selm=
> > 1033074519.2698.5.
> > camel%40localhost.loc
Recently I ran across
http://groups.google.ca/groups?hl=en&lr=lang_en&safe=off&selm=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 wi
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
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.
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 c
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 th
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 out
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 ba
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 ma
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
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 sour
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
http://www-dt.e-technik.uni-dortmund.de/
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 c
From: "Alan Cox" <[EMAIL PROTECTED]>
> > The only thing I'm not sure is that I believe the SPARC people uses
> > ttyS* for Zilog 8530-based serial ports. I don't know if we want to
> > define this as NS8250-family serial ports in light of that; I more
> > tended to think of it as the "default" se
34 matches
Mail list logo
