Andrew Morton [Mon, 29 Dec 2003 13:48:33 +0000 (05:48 -0800)]
[PATCH] Remove CLONE_FILES from init kernel thread creation
From: James Morris <jmorris@redhat.com>
The patch below removes the CLONE_FILES flag from the kernel_thread() call
which starts init.
This is to prevent other kernel threads from sharing file descriptors
opened by init (try 'lsof /dev/initctl' on a 2.6 system :-).
The reason this patch is being proposed is so that usermode helper apps
launched via kernel threads (e.g. modprobe, hotplug) do not then inherit
any such file descriptors. This is not a problem in itself so far (other
than being messy), but it is a problem for SELinux, which will otherwise
need to grant access to /dev/initctl by modprobe and hotplug, a somewhat
undesirable scenario.
As far as I can tell, there is no reason why init needs to be spawned with
CLONE_FILES. Please let me know if there are any objections to the
change, which I would like to propose for 2.6.0+ as a cleanup.
Andrew Morton [Mon, 29 Dec 2003 13:48:16 +0000 (05:48 -0800)]
[PATCH] new /proc/irq cpumask format; consolidate cpumask display and input code
From: Paul Jackson <pj@sgi.com>
This patch is a followup to one from Bill Irwin. On Nov
17, he had consolidated the half-dozen chunks of code
that displayed cpumasks in /proc/irq/prof_cpu_mask and
/proc/irq/<pid>/smp_affinity into a single routine, which he
called format_cpumask().
I believe that Andrew Morton has accepted Bill's patch into
his 2.6.0-test10-mm1 patch set as the "format_cpumask" patch.
I hope that the following patch will replace Bill's patch.
I look forward to Bill's feedback on this patch.
The following patch carries Bill's work further:
1) It also consolidates the input side (write syscalls).
2) It adapts a new format, same on input and output.
3) The core routines work for any multi-word bitmask,
not just cpumasks.
4) The core routines avoid overrunning their output
buffers.
Note esp. for David Mosberger:
The small patch I sent you and the linux-ia64 list
yesterday entitled: "check user access ok writing
/proc/irq/<pid>/smp_affinity" for arch ia64 only is
_separate_ from the following patch. Neither presumes the
other. However, they do collide on one line. Last one in
is a Monkey's Uncle and will need an updated patch from me
(or otherwise need to resolve the one obvious collision).
Details of the following patch:
Both the display and input of cpumasks on 9 arch's are
consolidated into a single pair of routines, which use the
same format for input and output, as recommended by Tony
Luck. The two common routines work on any multi-word bitmask
(array of unsigned longs). A pair of trivial inline wrappers
cpumask_snprintf() and cpumask_parse() hide this generality
for the common case of cpumask input and output.
My real motivation for consolidating this code will become
visible later - when I seek to add a nodemask_t that resembles
cpumask_t (just a different length). These common underlying
routines will be used there as well, following up on a suggestion
of Christoph Hellwig that I investigate implementing nodemask_t
as an ADT sharing infrastructure with cpumask_t. However, I
believe that this patch stands on its own merit, consolidating
a couple hundred lines of duplicated code, and making the
cpumask display format usable on very large systems.
There are two exceptions to the consolidation - the alpha and
sparc64 arch's manipulate bare unsigned longs, not cpumask_t's,
on input (write syscall), and do stuff that was more funky than
I could make sense of. So the input side of these two arch's
was left as-is. I'd welcome someone with access to either of
these systems to provide additional patches.
The new format consists of multiple 32 bit words, separated by
commas, displayed and input in hex. The following comment from
this patch describes this format further:
* The ascii representation of multi-word bit masks displays each
* 32bit word in hex (not zero filled), and for masks longer than
* one word, uses a comma separator between words. Words are
* displayed in big-endian order most significant first. And hex
* digits within a word are also in big-endian order, of course.
*
* Examples:
* A mask with just bit 0 set displays as "1".
* A mask with just bit 127 set displays as "80000000,0,0,0".
* A mask with just bit 64 set displays as "1,0,0".
* A mask with bits 0, 1, 2, 4, 8, 16, 32 and 64 set displays
* as "1,1,10117". The first "1" is for bit 64, the second
* for bit 32, the third for bit 16, and so forth, to the
* "7", which is for bits 2, 1 and 0.
* A mask with bits 32 through 39 set displays as "ff,0".
The essential reason for adding the comma breaks was to make
the long masks from our (SGI's) big 512 CPU systems parsable by
humans. An unbroken string of 128 hex digits is pretty difficult
to read. For those who are compiling systems with CONFIG_NR_CPUS
of 32 or less, there should be no visible change in format.
There are of course a thousand possible output formats that
meet similar criteria. If someone wants to lobby for and seek
consensus behind another such format, that's fine. Now that
the format is consolidated into a single pair of routines,
it should be easy to adapt whatever we choose.
Internally, the display routine uses snprintf to track the
remaining space in its output buffer, to avoid the risk of
overrunning it.
A new file, lib/mask.c, is added to the lib directory, to
hold the two common routines. I anticipate adding a few more
common routines for generic support of multi-word bit masks to
lib/mask.c, in subsequent patches that will add a nodemask_t
type as an ADT sharing implementation with cpumask_t.
Andrew Morton [Mon, 29 Dec 2003 13:48:07 +0000 (05:48 -0800)]
[PATCH] cpumask.h reorg
From: Paul Jackson <pj@sgi.com>
Push the cpumask implementation from linux/cpumask.h into asm/cpumask.h, so
that ia64 can do special things without breaking sparc64.
1) Each arch has its own include/asm-<arch>/cpumask.h file
2) That arch-specific header file can include <asm-generic/cpumask.h>,
if it wants to make use of the generic cpumask implementation.
3) Using code should continue to include linux/cpumask.h, which
in turn includes asm/cpumask.h. Some common implementation
independent cpumask related items, such as the cpu_online_map,
are declared directly in linux/cpumask.h.
Andrew Morton [Mon, 29 Dec 2003 13:47:43 +0000 (05:47 -0800)]
[PATCH] IDE MMIO fix
From: Alan Cox <alan@redhat.com>
IDE core code had the mmio==2 (ioremap) mode supported but two small changes
had been missed for ide-dma.c. Without this fix mmio IDE controllers bomb if
you have plenty of memory as it uses request_mem_region on an ioremap return.
Andrew Morton [Mon, 29 Dec 2003 13:47:28 +0000 (05:47 -0800)]
[PATCH] PIIX5 Doesn't work on IA64
From: Peter Chubb <peterc@gelato.unsw.edu.au>
The PIIX5 IDE controller on I2000 IA64 boxen using the 460GX chipset will
hang on startup if an ordinary harddrive is plugged into it (it seems to
workj for the LSI120 and the CDROM drives).
This is because the 460GX chipset contains a PCI expanssion bridge that
works like the 450NX PXB, and has the same PCI ID (but a later revision).
The PIIX driver, to work around interactions between PIIX4 and the 450NX
PXB, tries to disable DMA.
Unfortunately, the way it tries to disable DMA doesn't work, and the higher
layers think that DMA is still on, and so timeout waiting for DMA, and then
hang on bootup.
A simple workaround is to tighten the check for the buggy chipset, as in
the attached patch. However, someone with more time (and who actually
*understands* the IDE subsystem) needs to fix the real bug as well.
Andrew Morton [Mon, 29 Dec 2003 13:47:20 +0000 (05:47 -0800)]
[PATCH] ide-tape update
From: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
Stuart Hayes <stuart_hayes@dell.com>
- Check drive's write protect bit, try to return appropriate
errors when attempting to write a write-protected tape.
- Moved "idetape_read_position" call in idetape_chrdev_open
after the "wait_ready" call.
- Added IDETAPE_MEDIUM_PRESENT flag so driver would know
not to rewind tape after ejecting it.
- Fixed bug with ide_abort_pipeline (it was deleting stages
from tape->next_stage to end, instead of from
new_last_stage->next (tape->next_stage was set to NULL
by idetape_discard_read_pipeline before calling!).
- Made improvements to idetape_wait_ready.
- Added a few comments here and there.
- Made MTOFFL unlock tape drive door before attempting to eject.
- Added fixes to get Seagate STT3401A Travan working:
Handle drives that don't support 0-length reads/writes increased timeout
(retension takes ~10 minutes before irq is returned).
Fixed request mode page packet command byte 3.
Also remove code depending on NO_LONGER_REQUIRED to match 2.4.x (me).
Andrew Morton [Mon, 29 Dec 2003 13:47:04 +0000 (05:47 -0800)]
[PATCH] watchdog write() return value fixes
From: gleb@nbase.co.il (Gleb Natapov)
There is inconsistency in fops->write() implementation in different
watchdog drivers. Some of them return number of bytes written while others
return 1.
I think the correct implementation should always return number of bytes
written (we examine all the buffer after all) otherwise "echo V >
/dev/watchdog" doesn't work as expected (it doesn't stop watchdog).
Andrew Morton [Mon, 29 Dec 2003 13:46:40 +0000 (05:46 -0800)]
[PATCH] support centrino 1GHz
From: Jeremy Fitzhardinge <jeremy@goop.org>
I've been getting quite a lot of people mailing me about this CPU. It
seems Toshiba has released a machine with it. It would be nice if this
patch gets into a kernel soonish. It's very low-impact.
Andrew Morton [Mon, 29 Dec 2003 13:46:23 +0000 (05:46 -0800)]
[PATCH] seq_file version of /proc/interrupts
From: corbet@lwn.net (Jonathan Corbet)
This converts all architectures' /proc/interrupts implementation over to
seq_file. We need this for SMP machines with ridiculous numbers of CPUs and
if you convert one arch, you have to convert them all...
Andrew Morton [Mon, 29 Dec 2003 13:46:16 +0000 (05:46 -0800)]
[PATCH] eicon/ and hardware/eicon/ drivers using the same symbols
From: Adrian Bunk <bunk@fs.tum.de>
The legacy eicon driver in drivers/isdn/eicon is the old one and will be
removed as soon as all features went to the new driver. Anyway this old
driver was never meant to be non-module.
Andrew Morton [Mon, 29 Dec 2003 13:45:53 +0000 (05:45 -0800)]
[PATCH] use alloc_percpu in percpu_counters
From: Martin Hicks <mort@wildopensource.com>
Once NR_CPUS exceeds about 300 ext2 and ext3 will not compile, because the
percpu counters in the superblocks are so huge that they cannot be kmalloced.
Fix this by converting the percpu_counter mechanism to use alloc_percpu()
rather than an NR_CPUS-sized array.
Andrew Morton [Mon, 29 Dec 2003 13:45:44 +0000 (05:45 -0800)]
[PATCH] lockless semop
From: Manfred Spraul <manfred@colorfullife.com>
attached is the lockless semop patch. I did another test run with
idle=poll on an pentium III, and it remained unchanged: 99.9% direct
fast path, 0.1% race with wakeup against writing the final result code:
Current writev() of pipe/fifo can be interleaved with data from other
processes doing writes even when the requests size is <= PIPE_BUF. These
writes should in fact be atomic.
The readv() side is also supported for same behavior with read(). And it
is faster.
Andrew Morton [Mon, 29 Dec 2003 13:45:30 +0000 (05:45 -0800)]
[PATCH] optimize ia32 memmove
From: Manfred Spraul <manfred@colorfullife.com>
The memmove implementation of i386 is not optimized: it uses movsb, which is
far slower than movsd. The optimization is trivial: if dest is less than
source, then call memcpy(). markw tried it on a 4xXeon with dbt2, it saved
around 300 million cpu ticks in cache_flusharray():
Andrew Morton [Mon, 29 Dec 2003 13:45:14 +0000 (05:45 -0800)]
[PATCH] Fix for more than 256 CPUs
From: Paul Jackson <pj@sgi.com>
The patch is needed to build NR_CPUS > 256.
Without this fix, you get compile errors:
include/linux/cpumask.h: In function `next_online_cpu':
include/linux/cpumask.h:56: structure has no member named `val'
Andrew Morton [Mon, 29 Dec 2003 13:44:58 +0000 (05:44 -0800)]
[PATCH] Restore /proc/pid/maps formatting
The seq_file conversion of /proc/pid/maps caused altered behaviour with
respect to 2.4.22. Before the conversion, spaces and tabs in filenames were
displayed verbatim. After the conversion they are escaped as \040, etc.
Also, if the mmapped file has been unlinked the output appears as
Andrew Morton [Mon, 29 Dec 2003 13:44:34 +0000 (05:44 -0800)]
[PATCH] vmscan: reset refill_counter after refilling the inactive list
zone->refill_counter is only there to provide decent levels of work batching:
don't call refill_inactive_zone() just for a couple of pages.
But the logic in there allows it to build up to huge values and it can
overflow (go negative) which will disable refilling altogether until it wraps
positive again.
Just reset it to zero whenever we decide to do some refilling.
Andrew Morton [Mon, 29 Dec 2003 13:44:25 +0000 (05:44 -0800)]
[PATCH] serial console registration bugfix
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
uart_set_options() can dereference a null pointer. This happens if you
specify a console that hasn't previously been setup by early_serial_setup().
For example, on ia64, the HCDP typically tells us about line 0, so we calls
early_serial_setup() for it. If the user specifies "console=ttyS3", we
machine-check when trying to follow the uninitialized port->ops pointer.
It's not entirely clear to me whether we should return 0 or -ENODEV or
something. The advantage of returning zero is that if the user specifies
"console=ttyS0" and we just lack the HCDP, the console doesn't work as early
as usual, but it does start working after the serial driver detects the port
(though the baud/parity/etc from the command line are lost). Returning
-ENODEV seems to prevent it from ever working.
Andrew Morton [Mon, 29 Dec 2003 13:44:10 +0000 (05:44 -0800)]
[PATCH] Add `gcc -Os' config option
From: Adrian Bunk <bunk@fs.tum.de>
Allow the kernel to be built with `-Os'.
It requires CONFIG_EMBEDDED. This is to make it "hard to get at" because
one gcc version (3.2.x I think) from RH9 generates crashy kernels with this
option set.
Andrew Morton [Mon, 29 Dec 2003 13:44:02 +0000 (05:44 -0800)]
[PATCH] Fix proc_pid_lookup vs exit race
From: Manfred Spraul <manfred@colorfullife.com>
Fixes a race between proc_pid_lookup and sys_exit.
- The inodes and dentries for /proc/<pid>/whatever are cached in the dentry
cache. d_revalidate is used to protect against stale data: d_revalidate
returns invalid if the task exited.
Additionally, sys_exit flushes the dentries for the task that died -
otherwise the dentries would stay around until they arrive at the end of
the LRU, which could take some time. But there is one race:
- proc_pid_lookup finds a task and prepares new dentries for it. It must
drop all locks for that operation.
- the process exits, and the /proc/ dentries are flushed. Nothing
happens, because they are not yet in the hash tables.
- proc_pid_lookup adds the task to the dentry cache.
Result: dentry of a dead task in the hash tables.
The patch fixes that problem by flushing again if proc_pid_lookup notices
that the thread exited while it created the dentry. The patch should go
in, but it's not critical.
- task->proc_dentry must be the dentry of /proc/<pid>. That way sys_exit
can flush the whole subtree at exit time. proc_task_lookup is a direct
copy of proc_pid_lookup and handles /proc/<>/task/<pid>. It contains the
lines that set task->proc_dentry. This is bogus, and must be removed.
This hunk is much more critical, because creates a de-facto dentry leak
(they are recovered after flushing real dentries from the cache).
Andrew Morton [Mon, 29 Dec 2003 13:43:54 +0000 (05:43 -0800)]
[PATCH] Fix init_i82365 sysfs ordering oops
From: Russell King <rmk@arm.linux.org.uk>
This oops has been caused by the need to register the class before
registering any objects against it. Unfortunately, the class needs
to be registered asynchronously in a separate thread to avoid driver
model deadlock with yenta with cardbus cards inserted or standard
PCMCIA cards not being detected correctly due to a race.
I think the only real solution is to remove the class_device_create_file
calls from all socket drivers. This is just a simple commenting out of
the calls, and should be suitable for the remainder of the -test kernels.
Due to the number of cases that we're encountering with PCMCIA, I'm
beginning to wonder if the driver model could be fixed to be more kind
to PCMCIA by avoiding some of these ordering dependencies. None of this
would be a problem if the driver model would allow PCI device drivers to
register PCI devices while their probe or remove functions were executing.
Andrew Morton [Mon, 29 Dec 2003 13:43:38 +0000 (05:43 -0800)]
[PATCH] Fix dcache and icache bloat with deep directories
This fixes the recently-reported "fsstress memory leak" problem. It has been
there since November 2002.
shrink_dcache() has a heuristic to prevent the dcache (and hence icache) from
getting shrunk too far: it refuses to allow the dcache to shrink below
2*nr_used.
Problem is, _all_ non-leaf dentries (directories) count as used. So when you
have really deep directory hierarchies (fsstress creates these), nr_used is
really high, and there is no upper bound to the amount of pinned dcache.
The patch just rips out the heuristic. This means that dcache (and hence
icache (and hence pagecache)) will be shrunk more aggressively. This could
be a problem, and tons of testing is needed - a new heuristic may be needed.
However I am not able to reproduce the problem which cause me to add this
heuristic in the first place:
Simple testcase: run a huge `dd' while running a concurrent `watch -n1
cat /proc/meminfo'. The program text for `cat' gets loaded from disk once
per second.
Andrew Morton [Mon, 29 Dec 2003 13:43:08 +0000 (05:43 -0800)]
[PATCH] Use __GFP_REPEAT for cdrom buffer
The cdrom driver does an order-4 allocation and the open will fail if that
allocation does not succeed. This happened to me on an unstressed 900MB
machine.
So add the __GFP_REPEAT flag in there - this will cause the page allocator to
keep on freeing pages until the allocation succeeds.
It can in theory livelock but in practice I expect it is OK: the user should
just stop running dbench or whatever it is which is gobbling all the memory
and the mount/open will then succeed.
Andrew Morton [Mon, 29 Dec 2003 13:42:58 +0000 (05:42 -0800)]
[PATCH] scale the initial value of min_free_kbytes
This tunable refers to the amount of free memory which the VM will attempt to
sustain. It is mainly needed for atomic allocations (eg, networking
receive).
It is currently hardwired to 1024k, which is far too large for small machines
and too small for large machines.
Rework it to be 128k on tiny machines and 16M on huge machines.
Andrew Morton [Mon, 29 Dec 2003 13:42:34 +0000 (05:42 -0800)]
[PATCH] EFI support for ia32
From: Matt Tolentino <metolent@snoqualmie.dp.intel.com>
Attached is a patch that enables EFI boot-up support in ia32 kernels.
In order to continue to determine whether the kernel should initialize using
EFI tables, I've temporarily added a check on the LOADER_TYPE boot parameter.
Although I haven't requested that elilo be assigned an id for this yet, I've
used this to determine whether the kernel should use the EFI initialization
path as well as a check to see if the EFI_SYSTAB boot parameter contains
anything. If someone has a better suggestion for determining this, I'm
open...
This patch also uses the existing ioremapping functions to map the efi tables
into kernel virtual address space. I've added an option such that I could
use Dave Hansen's boot_ioremap() before paging_init(). After paging_init, I
then remap the efi memmap using bt_ioremap for use later. This has
eliminated the need for several functions...thanks for the suggestions and
thanks for your help Dave. Still this could use a look-see.
Andrew Morton [Mon, 29 Dec 2003 13:42:07 +0000 (05:42 -0800)]
[PATCH] make /proc/tty/driver/ S_IRUSR | S_IXUSR for root only
From: Chris Wright <chrisw@osdl.org>
Fix for CAN-2003-0461: /proc/tty/driver/serial in Linux 2.4.x reveals the
exact number of characters used in serial links, which could allow local
users to obtain potentially sensitive information such as the length of
passwords.
Andrew Morton [Mon, 29 Dec 2003 13:42:00 +0000 (05:42 -0800)]
[PATCH] fix suid leak in /proc
From: Chris Wright <chrisw@osdl.org>
Fix for CAN-2003-0501: The /proc filesystem in Linux allows local users to
obtain sensitive information by opening various entries in /proc/self
before executing a setuid program, which causes the program to fail to
change the ownership and permissions of those entries.
Andrew Morton [Mon, 29 Dec 2003 13:41:51 +0000 (05:41 -0800)]
[PATCH] fix unsigned issue with env_end - env_start
From: Chris Wright <chrisw@osdl.org>
Fix for CAN-2003-0462: A race condition in the way env_start and
env_end pointers are initialized in the execve system call and used in
fs/proc/base.c on Linux 2.4 allows local users to cause a denial of
service (crash).
Pete Zaitcev [Mon, 29 Dec 2003 05:16:58 +0000 (21:16 -0800)]
[SPARC]: Get sun4c functional again in 2.6.0
Move some elements of task_struct into thread_info so that
these elements are locked into the TLB in the trap handlers
and thus will not cause a watchdog reset.
Arnaud Quette [Mon, 29 Dec 2003 04:31:36 +0000 (20:31 -0800)]
[PATCH] USB: disable hiddev support for MGE UPS
following my recent posts on libusb-devel and hidups, here's
a patch to disable hiddev support for MGE UPSs. It only
declares VID/PID as QUIRK_IGNORE in hid-core's blacklist.
This simply prevent hiddev to be loaded when plugging
an MGE UPS.
David Brownell [Mon, 29 Dec 2003 04:30:55 +0000 (20:30 -0800)]
[PATCH] USB: let USB_{PEGASUS,USBNET} depend on NET_ETHERNET
Adrian Bunk wrote:
> I observed the following small problem in 2.6:
>
> - MII depends on NET_ETHERNET
> - USB_PEGASUS and USB_USBNET select MII, but they depend only on NET
>
> The patch below lets USB_PEGASUS and USB_USBNET depend on NET_ETHERNET
> instead of NET to fix this issue.
Actually how about this one instead? The PEGASUS bit is the same.
The difference is that MII (and CRC32) are only attributed to the
driver code that needs those ... AX8817X needs both, ZAURUS just
needs CRC32. The core (which should eventually become a separate
module) shouldn't depend on those modules at all.
Also both CDCETHER and AX8817X are marked as non-experimental;
I recall Dave Hollis submitted a patch to do that for AX8817X,
and CDCETHER now seems to have gotten enough success reports too.
David Brownell [Mon, 29 Dec 2003 04:29:03 +0000 (20:29 -0800)]
[PATCH] USB: <linux/usb_gadget.h> doc updates
As more people have been using this API, the need for some
clarifications has (no surprise!) came up.
Most significant is the halt processing, needed to make
Alan's "File Storage Gadget" (mass storage class, talks
to usb-storage and Windows) handle fault cases cleanly.
Gadget drivers can't halt IN endpoints until the FIFO is
emptied by the host ... virtually no hardware tries to
sequence the DATA and STALL packets by itself.
Adam Kropelin [Mon, 29 Dec 2003 04:21:02 +0000 (20:21 -0800)]
[PATCH] USB: Stop hiddev generating empty events
hiddev is mistakenly returning empty hiddev_event structures for report
events. According to Documentation/usb/hiddev.txt, report events are
only sent when HIDDEV_FLAG_REPORT and HIDDEV_FLAG_UREF are both set.
Currently, report events from hid cause hiddev to generate empty
hiddev_event events when HIDDEV_FLAG_UREF is not set.
Wim Van Sebroeck [Mon, 29 Dec 2003 04:13:21 +0000 (20:13 -0800)]
[PATCH] Watchdog update
Kconfig:
Reflect new watchdog Documentation directory.
[USB] hid blacklist addition:
Add the Berkshire Products USB PC Watchdog to the hid blacklist.
This to avoid problems with USB-Disconnects when the card feels it
should reboot...
Ingo Molnar [Mon, 29 Dec 2003 02:23:53 +0000 (18:23 -0800)]
[PATCH] Fix context switch accounting
Noted by Nick Piggin, fix based on a patch by Linus.
I've done some additional cleanups: fixed a compilation warning on UP
and cleaned up the goto pick_next_task code. Moved the 'unlikely' to
the test as a whole.
I've tested this patch and the context-switch stats look OK.
vidc_mksound causes the kernel to crash badly when executed. As it does not do anything useful I did not take the time to find out why, but removed it.
The vidc does have an external reference clock that is used to generate 44100/20050/10025kHz sample rates. The code is changed in a way that it uses that reference clock that can better approximate the desired clock.
If we can approximate the desired rate to more than 1/256 accuracy, we return the desired rate instead of the real rate. This is to assist using some programs that for instance believe they need exacly 8kHz which we can not have, but we can have 8.018kHz which is pretty close so that nobody would notice the difference.
Russell King [Sun, 21 Dec 2003 19:51:30 +0000 (19:51 +0000)]
[ARM] Ensure that /proc/uptime returns sensible figures.
When we set xtime at boot from the RTC, we weren't setting the
monotonic time offset. This had the effect of making the uptime
rather large.
We get around this problem by using the do_settimeofday() to set
the current time. do_settimeofday() knows about this issue, and
will apply the appropriate correction to the monotonic time offset
for us.
Bill Marr [Fri, 19 Dec 2003 03:11:27 +0000 (19:11 -0800)]
[PATCH] Status Query On My MCT-U232 Patch
Brief Patch Description:
Fix a problem in the 'mct_u232' driver whereby output data gets held up in the
USB/RS-232 adapter for RS-232 devices which don't assert the 'CTS' signal.
Background:
The Belkin F5U109 is a 9-pin USB/RS-232 adapter that is supported by the
existing 'mct_u232' kernel module. Recently, I've been testing it under the
2.4.22 (Slackware 9.1) kernel and the 2.6.0-test9 kernel.
I've connected a Garmin 'GPS35 TracPak' GPS receiver (RS-232 interface) and an
ordinary RS-232 external modem to my PC's USB port via the Belkin F5U109
adapter.
Problem:
Although _reads_ from either of the RS-232 devices mentioned above work fine
via the Belkin adapter, _writes_ to the GPS receiver are not being seen by
the GPS. Writes to the modem, however, work perfectly.
Aside: The 'Linux USB Users' archives show that at least one other person
(circa May 2002) had the exact same problem I'm having, but it sounds like no
solution was ever determined because the person in question just bought a
different USB/RS-232 adapter.
Investigation:
Using the 'seyon' terminal emulator in Linux and a crude hardware RS-232
"breakout box" that I hacked together, I've determined that the problem is
related to the RTS/CTS RS-232 hardware handshaking.
After further investigation, I've concluded that RS-232 devices which do not
assert the 'Clear To Send' ('CTS') signal prevent the Belkin F5U109 adapter
from transmitting data to the RS-232 device when the current (version 1.1)
'mct_u232' module is used. The data gets "queued up" (up to a point -- 16
bytes, I think) in the adapter but never transmitted.
Since this GPS receiver works perfectly (reads and writes) when connected to a
PC running W98se using the same Belkin adapter and the Belkin-supplied
Windows driver, the Linux driver became suspect.
After some testing with SniffUSB, I found that the Windows driver sends a
couple of unique undocumented USB 'device requests' that the Linux driver
does not. As it turns out, the second of those 2 requests is critical in
making the adapter transmit data to a device which doesn't assert 'CTS'.
For completeness, the Windows driver in use was determined from the 'Device
Manager', 'Driver File Details' page:
U2SPORT.VXD
Provider: Magic Control Technology
File version: 1.21P.0104 for Win98/Me
Solution:
My patch adds the 2 missing USB 'device request' commands right after a
baud-change command. This mimics the operation of the W98 driver.
Unfortunately, after much testing, I found no other operation (besides a
baud-change request) under Windows that triggers either of these 2 'device
request' commands. This makes it impossible to fully document the behavior of
these requests, but I've made entries for them alongside the others in the
'mct_u232.h' file.
Purely for clarity, the patch also modifies various comments in 'mct_u232.h',
mostly to reflect proper sizes of the various 'USB Device Request' fields per
the USB 1.1 specification.
The patch also updates the version number of the driver, corrects a minor
typographical error, and documents a difference in the length of the data in
a 'baud rate change' command for certain adapters which use a coded baud-rate
rather than the conventional RS-232 baud rate divisor.
I've provided (tested) patches for both the 2.4.22 and the 2.6.0-test9
kernels.
Please note that the changes to 'mct_u232.h' apply to both 2.4.22 and
2.6.0-test9 since that file has not changed between those kernel releases.
Nevertheless, I've included that (same) portion of the patch in both
attachments for simplicity.
projects / linux / log