* Re: PCI code: why need outb (0x01, 0xCFB); ?
From: H. Peter Anvin @ 2003-01-08 20:40 UTC (permalink / raw)
To: Nakajima, Jun; +Cc: linux-kernel
In-Reply-To: <3014AAAC8E0930438FD38EBF6DCEB5647D0D1C@fmsmsx407.fm.intel.com>
Nakajima, Jun wrote:
>
> Normally all accesses should be long (0xcf8/0xcfc) but x86 is byte addresseable and some chipsets do support byte accesses.
> We do not encourage use of byte accesses as it will not be supported in future platforms.
>
The PCI standard is quite explicit: byte accesses are permitted to the
data window (0xCFC) and not permitted to the address window (0xCF8).
Accepting byte accesses to the address window, or not supporting byte
accesses to the data window, *will* result in breakage (I can attest to
this fact quite well.)
-hpa
^ permalink raw reply
* Re: [OT] Re: ipv6 stack seems to forget to send ACKs
From: Andrew McGregor @ 2003-01-08 20:39 UTC (permalink / raw)
To: Fabio Massimo Di Nitto, Maciej Soltysiak
Cc: Wichert Akkerman, netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.51.0301082129180.12716@diapolon.int.fabbione.net>
Probably not slow and/or overloaded. I'd think it's more likely that it
has a routing update problem or an unreliable link. But whatever, this
seemed to me to be a classic 'dodgy box in the middle' rather than an end
host problem.
Andrew
--On Wednesday, January 08, 2003 21:31:04 +0100 Fabio Massimo Di Nitto
<fabbione@fabbione.net> wrote:
>
> Definitly it is somehow unstable. Difficult to find the reason.
> Anyway Im sure that there is asimmetric routing between me and
> ipv6.lkml.org and I could see pkts coming back. It might not have been the
> case for Wichert
>
> Fabio
>
> On Wed, 8 Jan 2003, Maciej Soltysiak wrote:
>
>> > Probably on the server's side it got an ICMP Host Unreachable or two as
>> > some router updated its tables, and decided to close the connection.
>> Sounds reasonable to me. Could it mean that this router that we are
>> talking about is simply slow or overloaded ?
>>
>> Maciej
>>
>>
>>
>
>
^ permalink raw reply
* Re: [BUG - HRT patch] nanosleep returns 0 on failure
From: george anzinger @ 2003-01-08 19:38 UTC (permalink / raw)
To: Fleischer, Julie N; +Cc: high-res-timers-discourse, linux-kernel
In-Reply-To: <D9223EB959A5D511A98F00508B68C20C17F1C71E@orsmsx108.jf.intel.com>
"Fleischer, Julie N" wrote:
>
> George -
> In the latest 2.5.54-bk1 high-res-timers patches, it appears that
> nanosleep() is returning 0 (success) and not setting errno when an rqtp
> argument is sent that specifies a nsec value < 0 or >= 1000 million. In
> this instance, the POSIX System Interfaces doc states that errno is supposed
> to be set to EINVAL, and nanosleep should return -1.
Looks like I missed a line in the compatibility layer. I
found it and it will be fixed in the next release.
If you don't mind, I will add your test code to my
clock_nanosleep test code so this does not creep back in.
Thanks for the report.
-g
>
> In the 2.5.50 high-res-timers patches, behavior was as expected (i.e.,
> returned -1 and set errno=EINVAL). Unfortunately, I haven't looked at any
> patches since then to know exactly which patch stopped behaving as expected.
> A plain 2.5.54-bk1 kernel also behaves as expected (returns -1, sets
> errno=EINVAL).
>
> The tests I am using to reproduce this issue are part of the POSIX Test
> Suite at http://posixtest.sf.net under
> posixtestsuite/conformance/interfaces/nanosleep. 5-1.c (sending -1 nsec),
> 6-1.c (sending multiple nsec values < 0 and >= 1,000 million), and 10000-1.c
> (sending other nsec values < 0 and >= 1,000 million) are failing. I've
> included 5-1.c below.
>
> Additional information is below:
> kernel used = 2.5.54-bk1
> HRT patches applied =
> hrtimers-core-2.5.54-bk1-1.0.patch
> hrtimers-hrposix-2.5.54-bk1-1.0.patch
> hrtimers-i386-2.5.54-bk1-1.0.patch
> hrtimers-posix-2.5.54-bk1-1.0.patch
> hrtimers-support-2.5.52-1.0.patch
>
> Thanks.
> - Julie Fleischer
>
> ----
> test 5-1.c below
> (Output was: nanosleep() did not return -1 on failure)
>
> /*
> * Copyright (c) 2002, Intel Corporation. All rights reserved.
> * Created by: julie.n.fleischer REMOVE-THIS AT intel DOT com
> * This file is licensed under the GPL license. For the full content
> * of this license, see the COPYING file at the top level of this
> * source tree.
>
> * Test that nanosleep() returns -1 on failure.
> * Simulate failure condition by sending -1 as the nsec to sleep for.
> */
> #include <stdio.h>
> #include <time.h>
>
> #define PTS_PASS 0
> #define PTS_FAIL 1
> #define PTS_UNRESOLVED 2
>
> int main(int argc, char *argv[])
> {
> struct timespec tssleepfor, tsstorage;
> int sleepnsec = -1;
>
> tssleepfor.tv_sec=0;
> tssleepfor.tv_nsec=sleepnsec;
> if (nanosleep(&tssleepfor, &tsstorage) == -1) {
> printf("Test PASSED\n");
> return PTS_PASS;
> } else {
> printf("nanosleep() did not return -1 on failure\n");
> return PTS_FAIL;
> }
>
> printf("This code should not be executed.\n");
> return PTS_UNRESOLVED;
> }
>
> **These views are not necessarily those of my employer.**
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* Re: Linux iSCSI Initiator, OpenSource (fwd) (Re: Gauntlet Set NOW!)
From: Richard B. Johnson @ 2003-01-08 20:40 UTC (permalink / raw)
To: Andrew McGregor; +Cc: H. Peter Anvin, linux-kernel
In-Reply-To: <81050000.1042056570@localhost.localdomain>
On Thu, 9 Jan 2003, Andrew McGregor wrote:
> Actually, talking to some people off-list, I realised that what happened
> with the instances I saw was probably that the packets were corrupted
> inside the host, somewhere after the ethernet checksum had done its job.
> DMA problems or a slow address line on some RAM somewhere could easily beat
> the TCP checksum, but as many folks have pointed out, ethernet CRC is much
> stronger.
>
> Having seen something odd like that in practice, I overestimated the
> probability of these problems.
>
> It was also pointed out that iSCSI also makes it's CRC optional only if
> there is some other mechanism (ESP, AH or some other high-integrity
> transport) providing the data integrity. Partly this is because that
> checksum is the same as used by Fiber Channel, and is therefore available
> 'for free' in some, but not all, hardware, so there needs to be another way
> to integrity protect the data.
>
> Andrew
>
> --On Wednesday, January 08, 2003 11:10:44 -0800 "H. Peter Anvin"
> <hpa@zytor.com> wrote:
>
> > Followup to: <20030107053146.A16578@kerberos.ncsl.nist.gov>
> > By author: Olivier Galibert <galibert@pobox.com>
> > In newsgroup: linux.dev.kernel
> >>
> >> On Tue, Jan 07, 2003 at 01:39:38PM +1300, Andrew McGregor wrote:
> >> > Ethernet and TCP were both designed to be cheap to evaluate, not the
> >> > absolute last word in integrity. There is a move underway to provide
> >> > an optional stronger TCP digest for IPv6, and if used with that then
> >> > there is no need for the iSCSI digest. Otherwise, well, play dice
> >> > with the data. Loaded in your favour, but still dice.
> >>
> >> Ethernet's checksum is a standard crc32, with all the usual good
> >> properties and, at least on FE and lower, 1500bytes max of payload.
> >> So it's quite reasonable. TCP's checksum, though, is crap.
> >>
> >> I'm not entirely sure how crc32 would behave on jumbo frames.
> >>
> >
> > AUTODIN-II CRC32 (the one used by Ethernet) is stable up to 11454
> > bytes. The jumbo frame size was chosen as the largest multiple of the
> > standard IP payload size to fit within this number.
> >
> > -hpa
>
> -
The TCP/IP checksum is 'strange' in that if all 0x00 are changed to 0xff,
it will not detect the error. But... in the 'real world', the TCP/IP
checksum does quite well detecting the kinds of errors likely in
serial links. Many years ago, in one of our products, some 'junior'
designer once decided that the way to control some equipment would be to
use RS-232C. Nobody at the design reviews caught this. RS-232C is about
99.999 percent reliable. That means that one byte in 10,000 may be
damaged. Normally humans correct RS-232C errors by looking at echo and
fixing the 'typo'. The product ran off a VAXen serial link at 19,200 baud,
the highest speed to which the VAX could be set.
The machine would not work. I ended up having to 'fix' the problem
in software. I used a TCP/IP checksum. The communications then never
failed (after the necessary retries). Since this was a 'success' I
decided to keep a record of the number of bad blocks retransmitted.
The customer got interested and emphatically stated; "The TCP/IP
checksum is wortless because.....". The result being pages of the
known anomolies of the checksum. The customer then required a
32-bit CRC they they specified. It was a standard polynominal,
but it was initialized with 0xaa55aa55 rather than 0xffffffff
(that's what then wanted). So, I used both and I logged the
operation of both.
There were never any errors, detected by the CRC, that were not
also detected by the checksum. This interface was for a spectrometer
that ran continuous serial commands (and data) for months at a time.
I recall that there were typically 40 to 50 recovered errors per
hour of operation. We delivered thousands of these.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* how to configure iptables / syslog to log to separate file
From: Randall J. Parr @ 2003-01-08 20:28 UTC (permalink / raw)
To: netfilter
Can I, and if so how can I, configure iptables (esp using GuardDog which
I use to configure iptables) and/or syslog (ie /etc/syslog.conf, ...) so
that my firewall messages are logged into a file other than
/var/log/messages?
I have searched, looked at tutorial, etc. and found this question asked
many times but without ever finding a decent answer.
If it just can not be done, could someone who knows this please state so?
Thanks
R.Parr
Temporal Arts
^ permalink raw reply
* /dev/random, /dev/urandom
From: Jamie Risk @ 2003-01-08 20:27 UTC (permalink / raw)
To: linux-newbie
I'm compiling OpenSSH, and to access /dev/random, and /dev/urandom, the
configure script needs to be run as root.
What sort of trauma am I in for if I make those device permissions read
accessible by everyone?
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* RE: Newbie - Where is my kernel? Can't run POM
From: Rowan Reid @ 2003-01-08 20:27 UTC (permalink / raw)
To: 'Arnt Karlsen', netfilter
In-Reply-To: <20030108195329.01d77b2f.arnt@c2i.net>
>
> ..try 'rpm -ivh kernel-source-2.4.18-19.8.0.i386.rpm'. ;-)
>
> --
> ..med vennlig hilsen = with Kind Regards from Arnt... ;-)
> ...with a number of polar bear hunters in his ancestry...
> Scenarios always come in sets of three:
> best case, worst case, and just in case.
If this is a new kernel don’t forget to do a dry run and compile the
kernel prior to running pom
^ permalink raw reply
* Re: Killing off the boot sector (was: [STATUS 2.5] January 8, 2002)
From: DervishD @ 2003-01-08 20:35 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linux-kernel
In-Reply-To: <avi06f$89g$1@cesium.transmeta.com>
Hi HPA :))
> Can we *please* kill off the stupid in-kernel boot sector?
Yespleaseyespleaseyesplease... I posted a message here a long
time ago because I couldn't boot a raw kernel image with 2.4.x. Well,
it didn't work even with a emulated floppy image (El Torito, you
know)...
I think that, with those good boot loaders out there, this piece
of code, that is architecture dependend, should be off-the kernel.
IMHO, those saved bytes should be used to store another cool Tux
image or something like that XDDDDD
> People keep asking what's the harm in keeping it, and the answer is,
> quite simply: "because people continue to try to use it."
Exact...
You've got a very good and sensible idea ;)
Raúl
^ permalink raw reply
* Re: [PATCH] /proc/sys/kernel/pointer_size
From: Linus Torvalds @ 2003-01-08 20:28 UTC (permalink / raw)
To: John Levon; +Cc: linux-kernel, davem
In-Reply-To: <20030108195934.GA35912@compsoc.man.ac.uk>
On Wed, 8 Jan 2003, John Levon wrote:
>
> OProfile needs to know the pointer size being used for the kernel,
> on platforms with 32-bit userspace and 64-bit kernel. This patch adds
> a simple ro sysctl that exports this information as suggested by davem
No.
This is the kind of stupid bloat I do not want. The kernel pointer size
doesn't change suddenly on the machine, there's no point at all in doing
something like this and exporting it through proc, when the information is
perfectly available in other ways or could even be a user program config
file option.
There is _no_ excuse for a program asking for what the kernel pointer size
is. Adding a random /proc file just because it's easy is not a good idea.
Bloat is bloat, and 99% of all bloat comes one little feature at a time.
Quite frankly, just compile oprofile for the architecture and be done with
it. Or add a command line option. Don't add stupid bloat to the kernel
because somebody is silly enough to care about a 32-bit oprofile working
with a 64-bit kernel.
Linus
^ permalink raw reply
* Re: [BENCHMARK] 2.5.53 with contest
From: Con Kolivas @ 2003-01-08 20:32 UTC (permalink / raw)
To: landley, linux kernel mailing list
In-Reply-To: <200301071944.18098.landley@trommello.org>
On Wednesday 08 Jan 2003 6:44 am, Rob Landley wrote:
> On Wednesday 25 December 2002 23:37, Con Kolivas wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Here are some contest results using osdl hardware:
> >
> > Uniprocessor:
> > process_load:
> > Kernel [runs] Time CPU% Loads LCPU% Ratio
> > 2.5.49 [5] 85.2 79 17 20 1.28
> > 2.5.50 [5] 84.8 79 17 19 1.27
> > 2.5.51 [2] 85.2 79 17 20 1.28
> > 2.5.52 [3] 84.4 79 17 19 1.26
> > 2.5.53 [7] 86.9 77 18 21 1.30
>
> Could you add a time per load metric? (I.E. 86.9/21=4.14 seconds. Yeah, I
> could do the math myself, but that and total time are usually what I'm
> trying to compare when I look at these. Maybe it's just me...)
If you look at the information carefully the meaningful number is
(Loads ) / ( process_load_time - no_load_time)
but keep an eye out for a new version soon.
Con
^ permalink raw reply
* [OT] Re: ipv6 stack seems to forget to send ACKs
From: Fabio Massimo Di Nitto @ 2003-01-08 20:31 UTC (permalink / raw)
To: Maciej Soltysiak; +Cc: Andrew McGregor, Wichert Akkerman, netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301082122190.32244-100000@dns.toxicfilms.tv>
Definitly it is somehow unstable. Difficult to find the reason.
Anyway Im sure that there is asimmetric routing between me and
ipv6.lkml.org and I could see pkts coming back. It might not have been the
case for Wichert
Fabio
On Wed, 8 Jan 2003, Maciej Soltysiak wrote:
> > Probably on the server's side it got an ICMP Host Unreachable or two as
> > some router updated its tables, and decided to close the connection.
> Sounds reasonable to me. Could it mean that this router that we are
> talking about is simply slow or overloaded ?
>
> Maciej
>
>
>
^ permalink raw reply
* Re: CRAMFS on MTD/NAND Issue
From: Henrik Nordstrom @ 2003-01-08 20:51 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Russ Dill, Srinivasu.Vaduguri, linux-mtd
In-Reply-To: <200301082127.24636.tglx@linutronix.de>
On Wed, 8 Jan 2003, Thomas Gleixner wrote:
> > roll your own: Please, make a static compressed filesystem (like cramfs)
> > that incorporates extra blocks, so that when the checksum is bad while
> > initially writing the filesystem, or reading the file system (in the
> > case where ecc can save the data), it rewrites this block to a free
> > sector). It would seem like a simple modification to cramfs to me.
> Don't reinvent the wheel! :)
Having a image based filesystem which cannot be written to has it's
beauty..
Regards
Henrik
^ permalink raw reply
* Re: Linux 2.4.21-pre3-ac1
From: Daniel Gryniewicz @ 2003-01-08 20:28 UTC (permalink / raw)
To: Maciej Soltysiak; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301082110460.484-100000@dns.toxicfilms.tv>
Nvidia produces an entire chipset (the nforce and nforce2 chipsets)
which have IDE on them as well as a number of other things.
Daniel
On Wed, 2003-01-08 at 15:12, Maciej Soltysiak wrote:
> > + NVIDIA nForce2 IDE PCI identifiers (Johannes Deisenhofer,
> This has been confusing me lately, does nvidia produce a card with IDE ?
> (similarily to some of creative labs' soundblasters ?)
>
> Maciej
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Daniel Gryniewicz <dang@fprintf.net>
^ permalink raw reply
* Last file access time ...
From: Jamie Risk @ 2003-01-08 20:18 UTC (permalink / raw)
To: linux-newbie
This is a bit circular, but here goes ...
Is there a way to determine when a file was last accessed, without actually
refreshing the access time when reading the access time?
Using the different time tests with 'find' doesn't seem to do what I'm
looking for.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* storage automount & devlabel
From: Gary_Lerhaupt @ 2003-01-08 20:18 UTC (permalink / raw)
To: linux-hotplug
I've added automount functionality to devlabel. Turns out it was an
additional 5 lines of code. In any case, when you hotplug your device, if
devlabel finds your symlink in an entry in /etc/fstab, it will run a mount
on the mountpoint listed for that symlink.
The latest version (0.26.02) is available at
http://domsch.com/linux/devlabel
So, here's what you do:
1. Install devlabel
2. Hotplug storage
3. `devlabel add -s /dev/mysymlink -d /dev/sdX1`
4. Edit /etc/fstab and add an entry pointing /dev/mysymlink to some mount
point
5. Un-Hotplug storage
From then on, when you hotplug your storage, it will automatically get
mounted as specified in /etc/fstab.
**Note that I've removed the agent hotplug scripts from the tarball install
script. If you have never installed devlabel before, you'll have to
manually patch your agent hotplug scripts so that devlabel will run after a
hotplug event occurs**
Gary Lerhaupt
Linux Development
Dell Computer Corporation
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: ipv6 stack seems to forget to send ACKs
From: Maciej Soltysiak @ 2003-01-08 20:27 UTC (permalink / raw)
To: Andrew McGregor
Cc: Fabio Massimo Di Nitto, Wichert Akkerman, netdev, linux-kernel
In-Reply-To: <78180000.1042055993@localhost.localdomain>
> Probably on the server's side it got an ICMP Host Unreachable or two as
> some router updated its tables, and decided to close the connection.
Sounds reasonable to me. Could it mean that this router that we are
talking about is simply slow or overloaded ?
Maciej
^ permalink raw reply
* Re: 2.5.54: ide-scsi still buggy?
From: Lukas Hejtmanek @ 2003-01-08 20:25 UTC (permalink / raw)
To: Zwane Mwaikambo; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.50.0301072116450.4046-100000@montezuma.mastecende.com>
On Tue, Jan 07, 2003 at 09:17:46PM -0500, Zwane Mwaikambo wrote:
> > It freezes kernel (sysrq do nothing) after lines:
> > scsi0 : SCSI host adapter emulation for IDE ATAPI devices
> > Vendor: TEAC Model: CD-W512EB Rev: 2
> > Type: CD-ROM ANSI SCSI revision: 02
> > scsi scan: host 0 channel 0 id 0 lun 0 identifier too long, length 60, max 50. Device might be improperly identified.
> >
> > while attaching it to /dev/hde works ok. Why?
>
> This has been observed to cause an oops on some boxes and nothing on mine,
> try this patch from Andries
Acctualy this patch caused only I do not see "scsi scan: host 0 channel 0 id
0 lun 0 identifier too long, length 60, max 50. Device might be improperly
identified."
how ever after above message kernel causes hard hw lockup. IDE activity
LED is turned on but nothing else works. (nor sysrq)
I believe that code that report this message causes hw lockup.
sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
--
Lukáš Hejtmánek
^ permalink raw reply
* Re: CRAMFS on MTD/NAND Issue
From: Russ Dill @ 2003-01-08 20:46 UTC (permalink / raw)
To: Henrik Nordstrom; +Cc: Srinivasu.Vaduguri, linux-mtd
In-Reply-To: <Pine.LNX.4.44.0301082125001.9261-100000@filer.marasystems.com>
On Wed, 2003-01-08 at 13:33, Henrik Nordstrom wrote:
> On 8 Jan 2003, Russ Dill wrote:
>
> > roll your own: Please, make a static compressed filesystem (like cramfs)
> > that incorporates extra blocks, so that when the checksum is bad while
> > initially writing the filesystem, or reading the file system (in the
> > case where ecc can save the data), it rewrites this block to a free
> > sector). It would seem like a simple modification to cramfs to me.
>
> It would indeed be quite simple to adopt cramfs to bad blocks as long as
> the superblock can be read. You only need to make a list of bad blocks,
> and then teach mkcramfs about this, avoiding allocating the bad areas when
> making the filesystem layout.
afaik***, NAND blocks can go bad after time, so it may not be a one time
thing (especially if you have say, 10k units in the field). If you did
it right, it'd be ok if the sb went bad, just use the oob data to mark
blocks as bad, and to number them (your sb might be block 0x00 (or
0x01), and if it was bad, you'd just rewrite the block later on, with
the same block number. When you boot, just check for the last occurance
of each block. (btw, this isn't reinvented the wheel imho, jffs2 adds a
lot of code in the kernel, and often the bootloader of the board, as
well as not being as efficient space wise as cramfs). Course, most of
the space constraints are moot on NAND
^ permalink raw reply
* Re: [Asterisk] DTMF noise
From: Thomas Tonino @ 2003-01-08 20:22 UTC (permalink / raw)
To: David D. Hagood; +Cc: Roy Sigurd Karlsbakk, linux-kernel
In-Reply-To: <3E1C1CDE.8090600@sktc.net>
David D. Hagood wrote:
> The basic idea is that you have 8 filters (for the 4 row and 4 column
> frequencies), as well as 8 filters looking at the first harmonic of the
> 8 frequencies. You then compare the energies in each frequency - if you
> see significant energy in the harmonic filter bank, discard the signal.
> That prevents you from detecting speech as DTMF, since speech will
> usually have harmonics that a good DTMF signal won't.
The original idea does one better by splitting high and low bands first. If that
is combined with Goertzel it might be even better: by looking at how much low
band energy there is total versus the low detected tone, and the same for the
high band total versus the high band detected tone. Only if the detected tone is
sufficiently strong compared to the total band it is in should the tone be
triggered.
But it may be more expensive computationally than doing twice the number of
Goertzel filters.
Harmonics seem like a bad idea. In between frequencies are better, but using the
total band energy must be the most sure way to detect interference.
Thomas
^ permalink raw reply
* [BK PATCH] USB changes for 2.5.54
From: Greg KH @ 2003-01-08 20:22 UTC (permalink / raw)
To: torvalds; +Cc: linux-usb-devel, linux-kernel
Hi,
Here's some more USB changes, including a change to the dev_printk()
macro to take a pointer instead of a reference to struct device. This
was requested by a lot of different people, with Randy Dunlap being the
most persistent :)
Please pull from: bk://linuxusb.bkbits.net/linus-2.5
thanks,
greg k-h
Documentation/usb/scanner-hp-sane.txt | 79 --------
Documentation/usb/scanner.txt | 329 +++++++++++++---------------------
drivers/usb/class/usblp.c | 3
drivers/usb/core/hcd-pci.c | 16 -
drivers/usb/core/hcd.c | 34 +--
drivers/usb/core/hub.c | 70 +++----
drivers/usb/core/usb-debug.c | 2
drivers/usb/core/usb.c | 38 +--
drivers/usb/host/ehci-dbg.c | 8
drivers/usb/host/ehci-hcd.c | 11 -
drivers/usb/host/ehci-q.c | 19 +
drivers/usb/host/ehci.h | 2
drivers/usb/host/ohci-dbg.c | 35 ++-
drivers/usb/host/ohci-hcd.c | 10 -
drivers/usb/host/ohci-hub.c | 2
drivers/usb/host/ohci-mem.c | 2
drivers/usb/host/ohci-q.c | 4
drivers/usb/image/Kconfig | 4
drivers/usb/image/mdc800.c | 4
drivers/usb/image/scanner.c | 203 +++++++-------------
drivers/usb/image/scanner.h | 24 --
drivers/usb/input/pid.c | 45 +---
drivers/usb/misc/Makefile | 6
drivers/usb/misc/atmsar.c | 177 +++++++-----------
drivers/usb/misc/atmsar.h | 27 +-
drivers/usb/misc/auerswald.c | 7
drivers/usb/misc/brlvger.c | 21 --
drivers/usb/misc/rio500.c | 5
drivers/usb/misc/speedtouch.c | 80 ++++----
drivers/usb/misc/usbtest.c | 306 +++++++++++++++++++++++++++++++
drivers/usb/net/kaweth.c | 8
drivers/usb/net/pegasus.c | 5
drivers/usb/net/pegasus.h | 4
drivers/usb/net/rtl8150.c | 5
drivers/usb/net/usbnet.c | 22 ++
drivers/usb/serial/bus.c | 9
drivers/usb/serial/empeg.c | 12 -
drivers/usb/serial/ezusb.c | 4
drivers/usb/serial/generic.c | 6
drivers/usb/serial/io_edgeport.c | 38 +--
drivers/usb/serial/io_ti.c | 58 ++---
drivers/usb/serial/ir-usb.c | 16 -
drivers/usb/serial/keyspan.c | 6
drivers/usb/serial/pl2303.c | 18 -
drivers/usb/serial/usb-serial.c | 38 +--
drivers/usb/serial/usb-serial.h | 2
drivers/usb/serial/visor.c | 48 ++--
drivers/usb/serial/whiteheat.c | 4
drivers/usb/storage/freecom.c | 4
drivers/usb/storage/transport.c | 307 -------------------------------
drivers/usb/storage/transport.h | 1
include/linux/device.h | 36 ++-
52 files changed, 1021 insertions(+), 1203 deletions(-)
-----
ChangeSet@1.897.1.8, 2003-01-08 10:21:15-08:00, neilt@slimy.greenend.org.uk
[PATCH] USB Serial patch for old pl2303 devices.
I got a PL2303 USB serial converter a few days ago, and got your driver
up and running fairly quickly. The problem is that I got an oops when I
rmmod-ed the drivers. The pl2303 uses two interfaces but registers only
the second (technically wrong, I guess, but should work). When pl2303.o
is removed, it attempts to deregister the first interface (which has no
effect), so the second interface remains registered with usbserial. The
old struct serial still points at the removed pl2303 driver so things go
pop when anything touches it.
I think the PL2303 hack in usb_serial_probe should not change the
"interface" variable, which gets stored in serial->interface, since
usbcore will register whatever "ifnum" says. I think that's enough
waffle. The patch is below. Keep up the good work!
drivers/usb/serial/usb-serial.c | 4 +---
1 files changed, 1 insertion(+), 3 deletions(-)
------
ChangeSet@1.897.1.7, 2003-01-08 10:09:32-08:00, henning@meier-geinitz.de
[PATCH] scanner.c, scanner.h: Use symbolic name for interface class
Hi,
On Wed, Jan 08, 2003 at 08:29:36AM -0800, Greg KH wrote:
> On Tue, Dec 24, 2002 at 05:44:55PM +0100, Henning Meier-Geinitz wrote:
> > Hi,
> >
> > On Tue, Dec 24, 2002 at 12:40:06AM +0100, Oliver Neukum wrote:
> > >
> > > > Well, the reason I didn't use one was that I didn't found one in
> > > > usb.h/usb_ch9.h for 16. It's also not listed on www.usb.org.
> > > >
> > > > lsusb calls it "Data". However, I'm not sure if this is a hex/dec
> > > > error and they really mean "Data" = dec 10, not 0x10 (=dec 16).
> > > >
> > > > Shall I define a local symbolic name (e.g.
> > > > STRANGE_HP_SCANJET_INTERFACE_CLASS)? But I really don't know what this
> > > > class is. I only know that it's used by a Hewlett-Packard ScanJet
> > > > 3300c and Genius HR6 USB - Vivid III.
> > >
> > > Better that than a bare number.
> >
> > Patch attached.
>
> Applied to my 2.4 tree, sorry for the delay.
Here is the same for 2.5.44:
drivers/usb/image/scanner.c | 2 +-
drivers/usb/image/scanner.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
------
ChangeSet@1.897.1.6, 2003-01-08 09:32:25-08:00, baldrick@wanadoo.fr
[PATCH] USB: speedtouch: add GPL notices
speedtouch and friends: add GPL notices (yes, the module was released by Alcatel
under the GPL) and fix some typos.
drivers/usb/misc/atmsar.c | 146 +++++++++++++++++++++---------------------
drivers/usb/misc/atmsar.h | 27 +++++--
drivers/usb/misc/speedtouch.c | 72 ++++++++++++--------
3 files changed, 138 insertions(+), 107 deletions(-)
------
ChangeSet@1.897.1.5, 2003-01-08 09:32:04-08:00, duncan.sands@math.u-psud.fr
[PATCH] USB: speedtouch: remove version string duplication
speedtouch: remove udsl_version in favour of DRIVER_VERSION (which it duplicated).
drivers/usb/misc/speedtouch.c | 4 +---
1 files changed, 1 insertion(+), 3 deletions(-)
------
ChangeSet@1.897.1.4, 2003-01-08 09:31:41-08:00, baldrick@wanadoo.fr
[PATCH] USB: speedtouch missing __init and __exit
speedtouch: add __init and __exit to the module init/exit routines.
drivers/usb/misc/speedtouch.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
------
ChangeSet@1.897.1.3, 2003-01-08 09:31:20-08:00, baldrick@wanadoo.fr
[PATCH] USB: atmsar is not a module
atmsar is not a module in its own right, it is an auxiliary library for speedtouch.
So remove module code from atmsar and build module speedtch from speedtouch and
atmsar. Note the module name change speedtouch -> speedtch (speedtch is the name
used for the original 2.4 module, and is the name used in the online documentation).
drivers/usb/misc/Makefile | 6 +++---
drivers/usb/misc/atmsar.c | 31 -------------------------------
2 files changed, 3 insertions(+), 34 deletions(-)
------
ChangeSet@1.897.1.2, 2003-01-08 08:23:03-08:00, henning@meier-geinitz.de
[PATCH] [PATCH 2.5.54] scanner.c: endpoint detection cleanup
This patch makes endpoint detection more generic. Basically, only one bulk-in
endpoint is required, everything else is optional.
The patch is on top of the PV8630 removal patch.
drivers/usb/image/scanner.c | 55 ++++++++++++++++----------------------------
1 files changed, 21 insertions(+), 34 deletions(-)
------
ChangeSet@1.897.1.1, 2003-01-07 21:29:37-08:00, greg@kroah.com
Merge kroah.com:/home/linux/linux/BK/bleeding-2.5
into kroah.com:/home/linux/linux/BK/gregkh-2.5
include/linux/device.h | 24 ++++++++++++++----------
1 files changed, 14 insertions(+), 10 deletions(-)
------
ChangeSet@1.879.9.26, 2003-01-07 15:45:51-08:00, greg@kroah.com
[PATCH] USB serial: fixup for probe function paramaters changing.
drivers/usb/serial/visor.c | 4 ++--
drivers/usb/serial/whiteheat.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
------
ChangeSet@1.879.9.25, 2003-01-07 15:45:31-08:00, greg@kroah.com
[PATCH] USB serial: pass the usb_device_id to the probe() function
This is needed for drivers that want to use the driver_info field.
drivers/usb/serial/usb-serial.c | 2 +-
drivers/usb/serial/usb-serial.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
------
ChangeSet@1.879.9.24, 2003-01-07 15:34:35-08:00, henning@meier-geinitz.de
[PATCH] scanner.c, scanner.h: Remove PV8630 ioctls
This patch removes the inofficial ioctls that were used to support the
PV8630 USB-over-Parport chipset. They were alreaded ifdefed out.
Instead of them, the more generic (and official) SCANNER_IOCTL_CTRLMSG
should be used. The last software that used the old ioctl
(sane-hp4200) switched to the new ioctls a long time ago.
This patch is ontop of the "user-supplied" patch.
drivers/usb/image/scanner.c | 60 +-------------------------------------------
drivers/usb/image/scanner.h | 17 +-----------
2 files changed, 4 insertions(+), 73 deletions(-)
------
ChangeSet@1.879.9.23, 2003-01-07 15:22:11-08:00, pablo@menichini.com.ar
[PATCH] 2.5.54 dev_*(&<dev>,...): drivers/usb/input/pid.c
drivers/usb/input/pid.c | 45 +++++++++++++++------------------------------
1 files changed, 15 insertions(+), 30 deletions(-)
------
ChangeSet@1.879.9.22, 2003-01-07 15:10:35-08:00, henning@meier-geinitz.de
[PATCH] scanner.c: print user-supplied ids only on start-up
With this patch, information about user-supplied ids is printed only
once at startup instead of everytime any USB device is plugged in.
The patch is on top of the new ids patch.
drivers/usb/image/scanner.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
------
ChangeSet@1.879.9.21, 2003-01-07 15:10:17-08:00, henning@meier-geinitz.de
[PATCH] scanner.c, scanner.h: Added vendor/product ids
This patch adds vendor/product ids for two Visioneer scanners.
The patch is on top of the ioctl patch.
drivers/usb/image/scanner.c | 5 ++++-
drivers/usb/image/scanner.h | 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
------
ChangeSet@1.879.9.20, 2003-01-07 15:09:59-08:00, henning@meier-geinitz.de
[PATCH] USB scanner driver: updated Kconfig
This patch removes the link in Kconfig to
Documentation/usb/scanner-hp-sane.txt which was removed by the
documentation update.
drivers/usb/image/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
------
ChangeSet@1.879.9.19, 2003-01-07 15:09:40-08:00, henning@meier-geinitz.de
[PATCH] USB scanner driver: updated documentation
This patch updates the documentation for the USB scanner driver. The
details:
Documentation/usb/scanner.txt:
- Amended for linux-2.5.54
- Added information about read_timeout
- Added more details about /proc/bus/usb/devices
- Added/updated links
- Added pointers two "special" scanner drivers
- Reordering, spell-checking, formatting
- Used /dev/usb/scanner[0-15] instead of /dev/usbscanner[0-15]
- Removed some basic USB configuration stuff
- Added EHCI
- Removed some more references to HP
Documentation/usb/scanner-hp-sane.txt:
Removed completely. This was a very outdated text for some HP
scanners. All of this is explained in the documentation of the
user-space SANE tools. Links and a short explanation about SANE was
added to scanner.txt instead.
This is the (slightly adapted) patch you already apllied for 2.4.
Documentation/usb/scanner-hp-sane.txt | 79 --------
Documentation/usb/scanner.txt | 329 +++++++++++++---------------------
2 files changed, 134 insertions(+), 274 deletions(-)
------
ChangeSet@1.879.9.18, 2003-01-07 15:09:22-08:00, henning@meier-geinitz.de
[PATCH] scanner.c: fix race in ioctl_scanner()
This patch adds locking to ioctl_scanner() which was completely
lacking until now. The patch is originally from Oliver Neukum
<oliver@neukum.name>.
The patch was forward-ported from 2.4.
drivers/usb/image/scanner.c | 73 ++++++++++++++++++++++++++------------------
1 files changed, 44 insertions(+), 29 deletions(-)
------
ChangeSet@1.879.9.17, 2003-01-07 14:52:33-08:00, greg@kroah.com
[PATCH] USB: drivers/usb/serial/ fixups due to dev_printk change
drivers/usb/serial/bus.c | 9 +++---
drivers/usb/serial/empeg.c | 12 ++++----
drivers/usb/serial/ezusb.c | 4 +-
drivers/usb/serial/generic.c | 6 ++--
drivers/usb/serial/io_edgeport.c | 38 ++++++++++++-------------
drivers/usb/serial/io_ti.c | 58 +++++++++++++++++++--------------------
drivers/usb/serial/ir-usb.c | 16 +++++-----
drivers/usb/serial/keyspan.c | 6 ++--
drivers/usb/serial/pl2303.c | 18 ++++++------
drivers/usb/serial/usb-serial.c | 32 ++++++++++-----------
drivers/usb/serial/visor.c | 44 ++++++++++++++---------------
11 files changed, 122 insertions(+), 121 deletions(-)
------
ChangeSet@1.879.9.16, 2003-01-07 14:52:13-08:00, greg@kroah.com
[PATCH] USB: drivers/usb/host/ fixups due to dev_printk change
drivers/usb/host/ehci-dbg.c | 8 ++++----
drivers/usb/host/ohci-dbg.c | 22 +++++++++++-----------
drivers/usb/host/ohci-hcd.c | 10 +++++-----
drivers/usb/host/ohci-hub.c | 2 +-
drivers/usb/host/ohci-mem.c | 2 +-
drivers/usb/host/ohci-q.c | 4 ++--
6 files changed, 24 insertions(+), 24 deletions(-)
------
ChangeSet@1.879.9.15, 2003-01-07 14:51:54-08:00, greg@kroah.com
[PATCH] USB: drivers/usb/core/ fixups due to dev_printk change
drivers/usb/core/hcd-pci.c | 16 ++++-----
drivers/usb/core/hcd.c | 34 ++++++++++----------
drivers/usb/core/hub.c | 70 +++++++++++++++++++++----------------------
drivers/usb/core/usb-debug.c | 2 -
drivers/usb/core/usb.c | 38 +++++++++++------------
5 files changed, 80 insertions(+), 80 deletions(-)
------
ChangeSet@1.879.9.14, 2003-01-07 14:51:34-08:00, greg@kroah.com
[PATCH] DEV: change dev_printk() to take a pointer to dev instead of the structure itself.
This was suggested by many people, Randy Dunlap being the most vocal :)
include/linux/device.h | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
------
ChangeSet@1.879.9.13, 2003-01-07 12:59:07-08:00, greg@kroah.com
[PATCH] USB mdc800: forward port 2.4 fix for misuse of types.
Thanks to Dave Jones for pointing this out.
drivers/usb/image/mdc800.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
------
ChangeSet@1.879.9.12, 2003-01-07 12:57:25-08:00, greg@kroah.com
[PATCH] USB printer driver: forward port 2.4 fix for misuse of types.
Thanks to Dave Jones for pointing this out.
drivers/usb/class/usblp.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
------
ChangeSet@1.879.9.11, 2003-01-07 12:55:14-08:00, greg@kroah.com
[PATCH] USB: removed MOD_INC_USE_COUNT and MOD_DEC_USE_COUNT from driver that do not need it.
drivers/usb/misc/auerswald.c | 7 -------
drivers/usb/misc/brlvger.c | 18 +++++-------------
drivers/usb/misc/rio500.c | 5 +----
3 files changed, 6 insertions(+), 24 deletions(-)
------
ChangeSet@1.879.9.10, 2003-01-06 17:26:56-08:00, greg@kroah.com
USB brlvger: Forward port 2.4 fix for misuse of types.
Thanks to Dave Jones for pointing this out.
drivers/usb/misc/brlvger.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
------
ChangeSet@1.879.9.9, 2003-01-06 16:35:55-08:00, mdharm-usb@one-eyed-alien.net
[PATCH] USB storage: remove usb_stor_tranfer_length()
This patch removes the (often troublesome) usb_stor_transfer_length()
function.
We've finally gotten all the command initiators to send the correct values
in the srb->request_bufflen field, so this is no longer needed.
There are probably some sanity checks that can also be removed now, but
that's for a later patch.
drivers/usb/storage/freecom.c | 4
drivers/usb/storage/transport.c | 307 ----------------------------------------
drivers/usb/storage/transport.h | 1
3 files changed, 5 insertions(+), 307 deletions(-)
------
ChangeSet@1.879.9.8, 2003-01-06 16:31:07-08:00, greg@kroah.com
USB: revert davem's compile time fix, now that it's fixed properly.
drivers/usb/host/ohci-dbg.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
------
ChangeSet@1.879.9.7, 2003-01-06 16:21:39-08:00, david-b@pacbell.net
[PATCH] usbtest, covers control queueing and fault cleanup
I wrote this a while back, finally debugged it. This covers
some functionality that 2.5 newly demands of all HCDs: control
requests can be queued. (Example: a user mode driver can talk
on one interface, and a kernel mode one can talk on another,
no need to handshake about who can make control requests.)
The good news is that all the HCDs seem (light testing) to do
the right things ... until some of the requests (intentionally)
trigger routine faults (like protocol stalls) which the HCDs
need to recover from. At that point, uhci-hcd started acting
confused (it's got newish queueing code); details will come
separately. The other two HCDs acted fine. I had expected more
trouble there, maybe it'll show up later on.
drivers/usb/misc/usbtest.c | 306 ++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 304 insertions(+), 2 deletions(-)
------
ChangeSet@1.879.9.6, 2003-01-06 16:21:21-08:00, david-b@pacbell.net
[PATCH] 2.5.54 -- ohci-dbg.c: 358: In function `show_list': `data1'
OK here's the version that without the kernel version #ifdef
that helped the backport ... it fixes the build by restoring
the "debug support only if CONFIG_USB_DEBUG" semantics.
drivers/usb/host/ohci-dbg.c | 11 +++++++++++
1 files changed, 11 insertions(+)
------
ChangeSet@1.879.9.5, 2003-01-06 16:01:14-08:00, oliver@neukum.name
[PATCH] USB: kaweth freeing skbs
this is the 2.5 version of the 2.4 fix
- proper freeing of skbs
drivers/usb/net/kaweth.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
------
ChangeSet@1.879.9.4, 2003-01-06 15:58:15-08:00, petkan@users.sourceforge.net
[PATCH] again rtl8150
this diff is agains the latest linux-2.5;
set mac address at dev->open()
(as per Jeff Garzik :-)
drivers/usb/net/rtl8150.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletion(-)
------
ChangeSet@1.879.9.3, 2003-01-06 15:55:16-08:00, petkan@users.sourceforge.net
[PATCH] USB pegasus: small patch for 2.5
Same as the previous email, just against latest linux-2.5 tree. Sorry
about the diffs - i can't sync with usb-2.5.
drivers/usb/net/pegasus.c | 5 ++++-
drivers/usb/net/pegasus.h | 4 ++--
2 files changed, 6 insertions(+), 3 deletions(-)
------
ChangeSet@1.879.9.2, 2003-01-06 15:48:03-08:00, david-b@pacbell.net
[PATCH] zaurus B500 (sl-5600?) & usbnet
More Zaurii. That model will be interesting from the
perspective of "usb gadget drivers", lots of flexible
endpoints are available.
drivers/usb/net/usbnet.c | 22 ++++++++++++++++++++--
1 files changed, 20 insertions(+), 2 deletions(-)
------
ChangeSet@1.879.9.1, 2003-01-06 15:47:26-08:00, david-b@pacbell.net
[PATCH] ehci, remove potential hangs
These don't affect the hang I'm hunting for, but paranoia
argues the patch is better integrated than not:
- prevent resubmit-from-completion looping in_irq if the
transfers complete really fast. (likely never seen, but...)
- grab ehci lock before reading irq status; should be harmless
except in one host error cleanup-after-death
drivers/usb/host/ehci-hcd.c | 11 +++++++----
drivers/usb/host/ehci-q.c | 19 +++++++++++++------
drivers/usb/host/ehci.h | 2 ++
3 files changed, 22 insertions(+), 10 deletions(-)
------
^ permalink raw reply
* Re: Linux 2.4.21-pre3-ac1
From: Dave Jones @ 2003-01-08 20:20 UTC (permalink / raw)
To: Maciej Soltysiak; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301082110460.484-100000@dns.toxicfilms.tv>
On Wed, Jan 08, 2003 at 09:12:40PM +0100, Maciej Soltysiak wrote:
> > + NVIDIA nForce2 IDE PCI identifiers (Johannes Deisenhofer,
> This has been confusing me lately, does nvidia produce a card with IDE ?
nForce/nForce2 are complete motherboard chipsets.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: BDI-2000
From: Muaddi, Cecilia @ 2003-01-08 20:12 UTC (permalink / raw)
To: 'linuxppc-embedded@lists.linuxppc.org'
Hello,
Looks like I made a typo and changed my kernel virtual address
in the makefile to 0x0c000000 instead of the default at 0xc0000000
So, after changed the kernel address to 0xc0000000 the kernel did
bootup with the following dump:
Module Name: ../images/zImage.srec
Entry Location: 0x400000
Starting at 0x400000...
loaded at: 00400000 0040C30C
board data at: 004001C0 004001E4
relocated to: 0040C0E8 0040C10C
zimage at: 0040C30C 004BC471
avail ram: 004BD000 00800000
Linux/PPC load: console=ttyS0,9600 nfsroot=192.168.0.59:/exports/onu860
ip=192.1
68.0.238::255.255.255.0
Uncompressing Linux... done.
Now booting the kernel
Linux version 2.4.7-timesys-3.1.254 (cmuaddi@localhost.localdomain) (gcc
version
2.95.2 19991024 (release)) #42 Wed Jan 8 10:51:27 PST 2003
On node 0 totalpages: 2048
zone(0): 2048 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,9600 nfsroot=192.168.0.59:/exports/onu860
ip=
192.168.0.238::255.255.255.0
Decrementer Frequency = 187500000/60
Memory: 5380k available (1624k kernel code, 676k data, 56k init, 0k highmem)
Calibrating delay loop... 49.76 BogoMIPS
Dentry-cache hash table entries: 1024 (order: 1, 8192 bytes)
Inode-cache hash table entries: 512 (order: 0, 4096 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 2048 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd v1.8
devfs: v0.107 (20010709) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x2
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
pty: 256 Unix98 ptys configured
block: queued sectors max/low 3373kB/1124kB, 64 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
eth0: CPM ENET Version 0.2 on SCC1, 00:00:00:00:00:00
eth1: FEC ENET Version 0.2, FEC irq 3, addr 00:00:00:80:00:00
loop: loaded (max 8 devices)
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 16 buckets, 2Kbytes
TCP: Hash tables configured (established 16 bind 26)
IP-Config: Incomplete network configuration information.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.0.59
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 192.168.0.59
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get mountd port number from server, using default
RPC: sendmsg returned error 101
mount: RPC call returned error 101
Root-NFS: Server returned error -101 while mounting /exports/onu860
VFS: Unable to mount root fs via NFS, trying floppy.
request_module[block-major-2]: Root fs not mounted
VFS: Cannot open root device "" or 02:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00
Rebooting in 180 seconds..
Looks like my IP has some problem. I will like to use the BDI with the ddd
for debugging
on my linux server. When i start the ddd with the following command as
suggested
by the appnote
ddd -debugger gdb -gdb vmlinux
(gdb)target remote bdi:2001
Remote packet too long:
c00021a00040b..............
It seems there is a problem between the BDI and the DDD on my linux PC. I
am running
redHat 8.0, GNU DDD 3.3.1 (i686-pc-linux-gnu)
Any help will be greatly appreciated.
Thanks
Cecilia
-----Original Message-----
From: Kerl, John [mailto:John.Kerl@Avnet.com]
Sent: Wednesday, January 08, 2003 9:44 AM
To: 'Marius Groeger'; 'cecilia.muaddi@alloptic.com'
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Subject: Re: BDI-2000
I think Marius' problem and mine were generalizations
of the same issue -- there can't be *any* mappings in
the kernel with virtual address below 0xc0000000.
(This includes regions mapped 1-1 as a special case.)
I couldn't put the IMMR at 0x38000000; I moved it to
0xf0000000. Marius found that on-chip RAM was mapped
at 0x70000000; that was bad too. Also the CPLD on
my board which does LED control is mapped in at
0xf8000000 -- also above the 0xc0000000. So I am
skeptical when Cecilia says she has "some other IO
mapped to miscellaneous addresses". What are those
miscellaneous virtual addresses?
The difference, though, is that Marius & I both had
problems entering user mode. Cecilia's is just a few
lines from the top of head_8xx.S, without yet having
made any subroutine calls to anything more complicated.
There's not much room for anything to have gone wrong
yet, in the Linux kernel code. So I agree that getting
the vxWorks boot ROM out of the picture (e.g. using
PPCBoot instead) would be an interesting test.
-----Original Message-----
From: Marius Groeger [mailto:mag@sysgo.de]
Sent: Wednesday, January 08, 2003 10:21 AM
To: Wells, Charles
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Subject: Re: BDI-2000
On Wed, 8 Jan 2003, Wells, Charles wrote:
> When I read Cecilia's post, I assumed what the statement "proven hardware
> platform" meant was that the vxworks O/S and user tasks exercised all the
> peripheral hardware; i.e., the SDRAM works, the ROM works, the FLASH works,
> the console works, etc. So, that statement made sense to me. While Linux
vxWorks doesn't use the MMU as much as Linux does. On Linux, the kernel and
all processes run in their own address space. The memory accesses involved
for cache or tlb refills are quite different to what's happening in a
vxWorks setup. Again, I'm probably overly pessimistic here, but we _have_
seen HW problems that just didn't show up when running vxWorks (AFAIR it was
a burst access on some early G4 based system.)
On a related matter, the following might also be interesting, especially
regarding the question of what firmware to use. The vxWorks boot-loader
tends to initialise _a lot_ of things you don't necessarily need. For
instance, on IBM405 based systems it sets up the on-chip RAM at address
0x70000000. Not a good idea when switching to user-mode the first time. Took
me quite some time to find this one... ;-)
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [LARTC] Problems with the HTB cue
From: bert hubert @ 2003-01-08 20:12 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104201473330506@msgid-missing>
On Wed, Jan 08, 2003 at 09:30:27AM +0100, Jesper Kold-Hansen wrote:
> I have a problem. As soon I patch my kernel with HTB, or recompile with a
> kernel with the HTB cue included, I start getting problems. When ever I
> try to make a connection to another computer, I get connection refused.
> That goes for all services. I have tryed FTP HTTP TELNET. All atempts to
> make a connection gives a connection refused.
You messed up something else. I bet HTB has nothing to do with this - try to
isolate what is really happening.
> Oh yah one last thing, I did this on a 2.4.18 kernel that I patched with
> the HTB cue. And the only thing I changed in the make config, was to
> include the HTB cue in the kernel, and there were no problems before the
> patch.
No rejections in the patch? Why not try a recent 2.4 kernel with HTB built
in?
Regards,
bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl Consulting
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: XFree86 vs. 2.5.54 - reboot
From: Andrew Morton @ 2003-01-08 20:20 UTC (permalink / raw)
To: Bob_Tracy(0000); +Cc: linux-kernel
In-Reply-To: <20030108140525.DF0434EE7@gherkin.frus.com>
"Bob_Tracy(0000)" wrote:
>
> This probably applies to immediately prior kernels in the 2.5 series
> as well. 2.5.54 seemed like a good time to jump in and test the waters,
> so to speak...
>
> AMD K6-III 450 running a 2.4.19 kernel with vesafb, XFree86 4.1.0, and
> a USB mouse works fine. Same setup with a 2.5.54 kernel does a cold
> reboot when I type "startx".
I saw exactly the same. In my case it appears to be due to miscompilation
of a particular sysenter patch which went into 2.5.53. If you're using
gcc-2.91.66 (aka `kgcc') then try 2.95.x instead.
^ permalink raw reply
* Re: [patch] Use XKPHYS for 64-bit TLB flushes
From: Maciej W. Rozycki @ 2003-01-08 20:12 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Mike Uhler, Dominic Sweetman, linux-mips
In-Reply-To: <20030108204408.A27888@linux-mips.org>
On Wed, 8 Jan 2003, Ralf Baechle wrote:
> We used to use just KSEG0 instead of KSEG0+entry*0x2000. That was running
> fine over years but had to be changed for the sake of two CPUs afair. There
> was some discussion on this list about this and I accepted the change by that
> time because Kevin imho correctly argued that the spec left it unspecified
> if an implementation is feeding addresses in an unmapped address space
> though the TLB.
Well, like it or not, CAMs do not like multiple matches -- up to a
physical damage even. So they should be avoided if possible. While KSEG0
won't match for any real address translation, there is a non-zero
probability of executing a tlbp for it as a result of buggy code or
execution gone wild (root running crashme?).
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.