* Message subject
From: Harold Macias @ 2004-01-02 15:19 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 254 bytes --]
ancestry hannah bugeyed canada argonaut yugoslav rockabye campground alphabet denver
deprecate decimate geochemical antagonist haplology biblical amphioxis beauty
modish fosterite navel infelicity inappreciable gsa goldberg tablet exasperate barnhard
[-- Attachment #2: Type: text/html, Size: 2911 bytes --]
^ permalink raw reply
* Re: multiple separate pci bridges ...
From: Rob Baxter @ 2004-01-02 15:18 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev
In-Reply-To: <20040101181145.GA27294@iliana>
Sven,
Synergy Microsystems has designs with the Discovery 2 as well. We worked
around this by setting pci_assign_all_busses to true and with modifications
to the platform specific config cycle routines (only included one as an
example):
int
gemini_pcibios_bus_fixup(struct pci_dev *dev, struct pci_controller *hose)
{
return ((dev->bus->number == hose->first_busno) ? 0 : dev->bus->number);
}
int
gemini_pcibios_read_config_byte(struct pci_dev *dev, int offset, u8 *val)
{
unsigned long reg;
unsigned int addr;
int bus;
struct pci_controller *hose;
hose = dev->sysdata;
bus = gemini_pcibios_bus_fixup(dev, hose);
addr = pci_config_type1_addr(bus, dev->devfn, offset & ~(0x3));
reg = config_read(addr, hose->cfg_addr, hose->cfg_data);
*val = ((reg >> ((offset & 0x3) << 3)) & 0xff);
return PCIBIOS_SUCCESSFUL;
}
It is also necessary to set the first and last bus number fields of the
hose structure correctly in your platform specific code. These will get
over written later by the PCI driver code, and in our case, to the same
values. Our platform specific code does a preliminary scan of the PCI
buses to find the first and last bus numbers.
This will also work when a PtP bridge is located on either of the primary
PCI buses of the Discovery. We're using a derivative of a 2.4.19 kernel.
I'm open to a better approach...
Rob Baxter
On Thu, Jan 01, 2004 at 07:11:45PM +0100, Sven Luther wrote:
>
> I am currently trying to port linux to the Pegasos 2, which uses the
> Marvell Discovery 2 chip, and has two independent pci controllers,
> of which one is faked as an agp bus. This is with a modified 2.4.23
> kernel from the linuxppc_2_4 branch.
>
> Anyway, these two independent controllers both have one bus 0 on them :
>
> PCI bus 0 controlled by pci at 80000000
> PCI bus 0 controlled by pci at c0000000
>
> (This coming from chrp_find_bridges).
>
> For the pci bus, at 80000000, a simple indirect access can be used,
> and i setup a specialized io ops for the faked agp bus since it needs
> special care.
>
> Later, in pcibios_init, there is a problem in the pci_scan_bus. The
> first bus has no problems :
>
> Scanning bus 00
> Found 00:00 [11ab/6460] 000600 00
> Found 00:08 [1106/3044] 000c00 00
> Found 00:28 [1000/0001] 000100 00
> Found 00:60 [1106/8231] 000601 00
> Found 00:61 [1106/0571] 000101 00
> Found 00:62 [1106/3038] 000c03 00
> Found 00:63 [1106/3038] 000c03 00
> Found 00:64 [1106/8235] 000000 00
> Found 00:65 [1106/3058] 000401 00
> Found 00:66 [1106/3068] 000780 00
> Found 00:68 [1106/3065] 000200 00
> Fixups for bus 00
> Bus scan for 00 returning with max=00
>
> But the second fails with :
>
> PCI: Bus 00 already known
>
> Which comes because in drivers/pci/pci.c:pci_bus_exists does handle
> only buses, and thus know nothing of separate pci bridges with the
> same bus number, and thus the kernel dies when accessing bus->xxx
> something in pcibios_init.
>
> Now, i know that the powermacs in particular, and maybe others, also
> have this case of different same numbered pci buses with different
> base addresses, and that this kind of situation has already been
> solved.
>
> So, what is the workaround here, and where does it get set.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* RE: help needed: clogged console
From: bmcdowell @ 2004-01-02 15:15 UTC (permalink / raw)
To: orlowscy, shrike-list, redhat-list; +Cc: netfilter
Search for 'dmesg -n 1' - I think that's what you're after.
Bob
-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Slawomir
Orlowski
Sent: Tuesday, December 23, 2003 12:32 PM
To: shrike-list@redhat.com; redhat-list@redhat.com
Cc: netfilter@lists.netfilter.org
Subject: help needed: clogged console
Hello,
I have Linux RH 9.0 configured as filtering firewall, and getting a lot of
(kernel, iptables) messages on active consoles.
I have thought that putting in /etc/syslog.conf:
# *.kern /dev/console
kern.* /var/log/kernel
kern.* /dev/tty8
would free me from this, but it did not.
How can I force kernel message to appear only in /var/log/kernel log and on
tty8 only?
Best Regards
I hope that somebody will be able to help me.
When I'm getting a lot of dropped packages it is not possible even to log.
Slawomir Orlowski
^ permalink raw reply
* RE: [despammed] -i and -o options for iptables FORWARD chain
From: bmcdowell @ 2004-01-02 15:13 UTC (permalink / raw)
To: netfilter
Actually, couldn't this be just a 2.6.x change? (I never saw the rules go by...) I thought I saw a message go by earlier to that effect. Something about the syntax and needing '--physdev' and '-i' both, or something?
I could search the archives, I guess, but instead I suggest Gonya give that a go.
Bob
-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Antony Stone
Sent: Friday, January 02, 2004 8:03 AM
To: netfilter@lists.netfilter.org
Subject: Re: [despammed] -i and -o options for iptables FORWARD chain
On Friday 02 January 2004 1:30 pm, Andreas Kretschmer wrote:
> am Wed, dem 31.12.2003, um 15:36:34 -0800 mailte Gongya Yu folgendes:
> > Hi, I just updated Linux kernel to 2.6.0 with iptables and ebtables
> > enabled.
>
> I'm using iptables on 2.4.x, possible there are differences with 2.6.x.
>
> > But iptables ignores -i and -o options for FORWARD chain. Wheneneve I use
> > something like -i eth0 or -o eth0, the rule is just ignored.
>
> RTFM!
>
> -i is only for INPUT, FORWARD and PREROUTING
> -o is only for FORWARD, OUTPUT and POSTROUTING
Are you suggesting that -i and -o cannot be used in FORWARD? As far as I can
see the syntax of the rule Gonya posted is perfectly okay.
Antony.
--
Christmas is an opportunity to upgrade to kernel 2.6 while no-one's around to
notice the downtime.
Please reply to the list;
please don't CC me.
^ permalink raw reply
* Re: Syscall table AKA hijacking syscalls
From: Muli Ben-Yehuda @ 2004-01-02 15:12 UTC (permalink / raw)
To: Libor Vanek; +Cc: linux-kernel
In-Reply-To: <3FF56B1C.1040308@conet.cz>
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
On Fri, Jan 02, 2004 at 01:59:08PM +0100, Libor Vanek wrote:
> Hi,
> I'm writing some project which needs to hijack some syscalls in VFS
> layer. AFAIK in 2.6 is this "not-wanted" solution (even that there are
> some very nasty ways of doing it - see
> http://mail.nl.linux.org/kernelnewbies/2002-12/msg00266.html )
Why do you need to hijack system calls from a module? 99% of the
times, it's the wrong technical solution.
> So what is proper (Linus recommanded) way to do such a things? Create
> patches for specific syscalls like "if this_module_installed then
> call_this_function;" or try to force things like syscalltrack to go into
> vanilla kernel some time? Because what I've found out there are more
> projects which suffer from this restriction.
There is no such Linus recommended way. For 2.6, syscalltrack's hijack
module moved into the kernel and will provide such generic
functionality one day. But I don't anticipate it every going into the
vanilla kernel, due to Linus's well known objections to syscall
hijacking in general and making it convenient in particular.
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
"the nucleus of linux oscillates my world" - gccbot@#offtopic
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [U-Boot-Users] [PATCH] pass custom data to Linux
From: Wolfgang Denk @ 2004-01-02 15:04 UTC (permalink / raw)
To: u-boot
In-Reply-To: <fc.004c4e48001f0f90004c4e48001e648f.1f0fa9@rea.de>
In message <fc.004c4e48001f0f90004c4e48001e648f.1f0fa9@rea.de> you wrote:
>
> the attached patch (against CVS of last night) adds two configuration
> options: CONFIG_SERIAL_TAG and CONFIG_REVISION_TAG
> These options enable the functions setup_serial_tag() and
> setup_revision_tag(), which should be defined in the board-specific
> code when needed.
>
> This provides a hook to pass ATAG_SERIAL (board serial number) and
> ATAG_REVISION (board revision) to the (ARM) kernel.
> These values appear in /proc/cpuinfo of the target.
Thanks, added.
Best regards, and a Happy New Year!
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
"It's when they say 2 + 2 = 5 that I begin to argue." - Eric Pepke
^ permalink raw reply
* Re: [Qemu-devel] Segmentation fault with 0.50 and 0.51 and fedora core ls
From: J. Mayer @ 2004-01-02 13:14 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <1073018837.4731.58.camel@intrepid>
On Fri, 2004-01-02 at 05:47, Michael Torrie wrote:
> On Thu, 2004-01-01 at 20:26, J. Mayer wrote:
> > You're right, this is the right explanation.
> > I've already seen this problem, but didn't solve it, with a recent
> > Debian using glibc 2.3...
> > The glibc 2.3 signal context structure isn't the same that the one used
> > in glibc 2.2. This makes qemu think that the emulated program is doing
> > invalid access while it should detect some valid write access to code
> > pages.
> >
> > I'm surprised that you were able to compile qemu with this glibc. When I
> > tried to use glibc 2.3 on PPC, qemu failed to compile, because the
> > structure field names also changed. Are your headers fully synchronised
> > with your libc ?
>
> qemu was compiled on my yellowdog ppc box, which doesn't use the nptl
> glibc-2.3.3. I think it's still glibc-2.3.1, without nptl.
May the changes has been made between glibc 2.3.1 and following versions
? Strange idea... I have to check this...
> > I don't believe it's a thread-scheme problem, because qemu don't use
> > threads. Or it may be some other glibc definitions or structure padding
> > or alignment which aren't the same than in the regular glibc...
>
> I guess I'll have to try downloading a non-nptl x86 glibc and try that.
> But it would be nice to figure out how to get the nptl glibc working
> with qemu (even in non-nptl mode, since nptl would depend on the kernel
> support).
Well, you may rebuild qemu as a static binary on your yellowdog
distribution. If it compiles without a problem, you'll win :-)
It seems really more simple than trying to make two glibc available on
your system...
--
J. Mayer <l_indien@magic.fr>
Never organized
^ permalink raw reply
* TTL patch buggy?
From: John A. Sullivan III @ 2004-01-02 15:02 UTC (permalink / raw)
To: netfilter-devel
I noticed a recent post on the netfilter list about the TTL patch being buggy.
We were planning to make extensive use of it in the ISCS project. I've
not seen anything recent about such a bug in a google search. Is there
currently a known problem with this patch? Thanks - John
--
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net
^ permalink raw reply
* access_ok and CONFIG_MIPS32 for 2.6
From: Dimitri Torfs @ 2004-01-02 14:59 UTC (permalink / raw)
To: linux-mips
Hi,
the mask used in access_ok to check the validity of an address range
evaluates to -TASK_SIZE for user processes. In case of
CONFIG_MIPS32, TASK_SIZE is defined as 0x7fff8000UL, so -TASK_SIZE
evaluates to 0x80008000, making access_ok return false for all
addresses with bit 15 and 31 set. Surely the mask should be 0x80000000.
Does anybody know why TASK_SIZE is set to 0x7fff8000 and not
0x80000000 ?
Dimitri
--
Dimitri Torfs | NSCE
dimitri.torfs@sonycom.com | Sint Stevens Woluwestraat 55
tel: +32 2 2908451 | 1130 Brussel
fax: +32 2 7262686 | Belgium
^ permalink raw reply
* 2.6.1-rc1-mm1: kernel or NFS problem?
From: Mario Vanoni @ 2004-01-02 14:48 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
a) not in lkml, cc if needed
b) 5 machines otherwise 100% working, congrats
c) test on 4 machines, the 5th is production, taboo
d) top used: 2x 2.0.16, 2x 3.1.0
Scenario:
machine 1: top, sees himself, <1% CPU
machine 2: ssh to machine 1 ; top
machine 1: top sees 2 top's, <1% CPU each
machine 2: reboot with ssh _active_ with top
machine 1: the top from machine 2 is not killed
and consumes now >99% CPU,
must be killed explicitly
Same behaviour on 4 machines,
UP's Celeron-1000+512MBmem & P4-3066HT+1GBmem,
dual SMP's P3-550+1GBmem & P3-1266+2GBmem.
Sar(1) -U ALL 1 0 reports the same values as top(1).
It's not a procps problem, same conditions:
machine 1: top and sar -U ALL 1 0
machine 2: ssh to machine 1; sar -U ALL 1 0
machine 1: ps -efw sees sar, top no CPU used
machine 2: reboot with ssh _active_ with sar -U ALL 1 0
machine 1: top no CPU usage, according ps -efw sar -U ALL 1 0
and corresponding sadc 1 are always active,
killall sar kills both
The ethernet is 10Mb, mixed RJ and BNC connectors.
Mario
^ permalink raw reply
* 2.6.1-rc1 not unmounting clearly?
From: Markus Hästbacka @ 2004-01-02 14:38 UTC (permalink / raw)
To: Kernel Mailinglist
[-- Attachment #1: Type: text/plain, Size: 640 bytes --]
Hello all,
I yesterday installed my workstation from scratch, downloaded packages
etc. and updated the kernel. And I noticed this after doing "tune2fs -j
/dev/hda10" and rebooting. While the computer booted up there was an
error message like:
/dev/hda10 was not unmounted clearly!
** Note: Journal was removed, mounting ext2 only! **
then I decided to check the error, and booted back to 2.2.20 and did the
tune2fs there and booted straight to 2.6.1-rc1 after that, and then it
seemed to work. Known bug?
Regards,
Markus
--
"Software is like sex, it's better when it's free."
Markus Hästbacka <midian at ihme dot org>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: GetASF failed on DVD authentication
From: Jens Axboe @ 2004-01-02 14:38 UTC (permalink / raw)
To: Jeff Chua; +Cc: Linux Kernel
In-Reply-To: <Pine.LNX.4.58.0401022219290.10338@silk.corp.fedex.com>
On Fri, Jan 02 2004, Jeff Chua wrote:
>
> On Fri, 2 Jan 2004, Jens Axboe wrote:
>
> > > GetASF failed
> > > N/A, invalidating: Function not implemented
> > > N/A, invalidating: Function not implemented
> > > N/A, invalidating: Function not implemented
> > > Request AGID [1]... Request AGID [2]... Request AGID [3]...
> > > Cannot get AGID
>
>
> > > This error happens only on USB DVD drive using /dev/scd0 ...
>
> USB drive is a Pioneer DVR-SK11B-J. It's reported as ...
>
> scsi0 : SCSI emulation for USB Mass Storage devices
> Vendor: PIONEER Model: DVD-RW DVR-K11 Rev: 1.00
> Type: CD-ROM ANSI SCSI revision: 02
>
> I've tried at least 2 other USB drives (Plextor PX-208U, and Sony CRX85U),
> and both of these drives also exhibit the same problem.
>
>
> > > Linux version is 2.4.24-pre3.
>
>
> > I can't say what goes wrong from the info above. Do you get any kernel
> > messages?
>
> No kernels oops. Just those "GetASF failed" messages above.
I forget which, but there's an option to make usb-storage dump all
commands going through it. If you could enable that and send the
results, that would help a lot.
--
Jens Axboe
^ permalink raw reply
* IO-APIC error.
From: Carlos Perello @ 2004-01-02 14:29 UTC (permalink / raw)
To: linux-smp
2.4.23
Jan 2 14:46:39 carlos kernel: testing the IO APIC.......................
Jan 2 14:46:39 carlos kernel:
Jan 2 14:46:39 carlos kernel: An unexpected IO-APIC was found. If this
kernel release is less than
Jan 2 14:46:39 carlos kernel: three months old please report this to
linux-smp@vger.kernel.org
Jan 2 14:46:39 carlos kernel: .................................... done.
Jan 2 14:46:39 carlos kernel: PCI: Using ACPI for IRQ routing
Jan 2 14:46:39 carlos kernel: PCI: if you experience problems, try
using option 'pci=noacpi' or even 'acpi=off'
^ permalink raw reply
* Re: TTL patch buggy?
From: Antony Stone @ 2004-01-02 14:27 UTC (permalink / raw)
To: netfilter
In-Reply-To: <1073049217.2993.1.camel@jasiiitosh.nexusmgmt.com>
On Friday 02 January 2004 1:13 pm, John A. Sullivan III wrote:
> I noticed a recent post on this list about the TTL patch being buggy.
> We were planning to make extensive use of it in the ISCS project. I've
> not seen anything recent about such a bug in a google search. Is there
> currently a known problem with this patch? Thanks - John
I think you may find the developers' list a better place to get a response to
this sort of question.
Regards,
Antony.
--
You can spend the whole of your life trying to be popular,
but at the end of the day the size of the crowd at your funeral
will be largely dictated by the weather.
- Frank Skinner
Please reply to the list;
please don't CC me.
^ permalink raw reply
* Re: GetASF failed on DVD authentication
From: Jeff Chua @ 2004-01-02 14:25 UTC (permalink / raw)
To: Jens Axboe; +Cc: Linux Kernel
In-Reply-To: <20040102103949.GL5523@suse.de>
On Fri, 2 Jan 2004, Jens Axboe wrote:
> > GetASF failed
> > N/A, invalidating: Function not implemented
> > N/A, invalidating: Function not implemented
> > N/A, invalidating: Function not implemented
> > Request AGID [1]... Request AGID [2]... Request AGID [3]...
> > Cannot get AGID
> > This error happens only on USB DVD drive using /dev/scd0 ...
USB drive is a Pioneer DVR-SK11B-J. It's reported as ...
scsi0 : SCSI emulation for USB Mass Storage devices
Vendor: PIONEER Model: DVD-RW DVR-K11 Rev: 1.00
Type: CD-ROM ANSI SCSI revision: 02
I've tried at least 2 other USB drives (Plextor PX-208U, and Sony CRX85U),
and both of these drives also exhibit the same problem.
> > Linux version is 2.4.24-pre3.
> I can't say what goes wrong from the info above. Do you get any kernel
> messages?
No kernels oops. Just those "GetASF failed" messages above.
Detailed dmesg as follows ...
Yenta ISA IRQ mask 0x0638, PCI irq 11
Socket status: 30000820
Yenta ISA IRQ mask 0x0638, PCI irq 11
Socket status: 30000006
cs: cb_alloc(bus 2): vendor 0x1033, device 0x0035
PCI: Enabling device 02:00.0 (0000 -> 0002)
PCI: Enabling device 02:00.1 (0000 -> 0002)
PCI: Enabling device 02:00.2 (0000 -> 0002)
cs: IO port probe 0x0100-0x03ff: excluding 0x170-0x177 0x370-0x37f
cs: IO port probe 0x0a20-0x0a27: clean.
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.
ehci_hcd 02:00.2: PCI device 1033:00e0
ehci_hcd 02:00.2: irq 11, pci mem f969b000
usb.c: new USB bus registered, assigned bus number 1
ehci_hcd 02:00.2: USB 2.0 enabled, EHCI 1.00, driver 2003-Jun-19/2.4
hub.c: USB hub found
hub.c: 3 ports detected
hub.c: new USB device 02:00.2-1, assigned address 2
scsi0 : SCSI emulation for USB Mass Storage devices
Vendor: PIONEER Model: DVD-RW DVR-K11 Rev: 1.00
Type: CD-ROM ANSI SCSI revision: 02
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.12
WARNING: USB Mass Storage data integrity not assured
USB Mass Storage device found at 2
Thanks,
Jeff
^ permalink raw reply
* Re: [despammed] -i and -o options for iptables FORWARD chain
From: Andreas Kretschmer @ 2004-01-02 14:25 UTC (permalink / raw)
To: netfilter
In-Reply-To: <200401021403.02171.Antony@Soft-Solutions.co.uk>
am Fri, dem 02.01.2004, um 14:03:02 +0000 mailte Antony Stone folgendes:
> > -i is only for INPUT, FORWARD and PREROUTING
> > -o is only for FORWARD, OUTPUT and POSTROUTING
>
> Are you suggesting that -i and -o cannot be used in FORWARD? As far as I can
> see the syntax of the rule Gonya posted is perfectly okay.
Oh, i'm sorry, parse error by me =:-(
Andreas
--
Diese Message wurde erstellt mit freundlicher Unterstützung eines freilau-
fenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert frei
von Micro$oft'schen Viren. (#97922 http://counter.li.org) GPG 7F4584DA
Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889° ;-)
^ permalink raw reply
* Re: [linux-lvm] booting a dm+lvm2 kernel
From: Bill Rugolsky Jr. @ 2004-01-02 14:24 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <20040102201045.GK26275@percy.comedia.it>
On Fri, Jan 02, 2004 at 09:10:46PM +0100, Luca Berra wrote:
> On Fri, Jan 02, 2004 at 07:30:45PM +0000, Kjartan Reynir Hauksson wrote:
> >>work. You have to use the --lvm-version=2 option to mkinitrd.
> >
> >kernel panic, this time VFS: Cannot open root device "3a00" or 3a:00
>
> ouch that should never happen, do you have anything printed above the
> kernel panic?
0x3a == 58 == lvm1 major device number. So it looks like the initrd
is still incorrect.
Regards,
Bill Rugolsky
^ permalink raw reply
* Re: [PATCH]sk98lin ethtool support
From: Mirko Lindner @ 2004-01-02 14:23 UTC (permalink / raw)
To: Feldman, Scott; +Cc: Jeff Garzik, krishnakumar, mlindner, netdev, felix
In-Reply-To: <Pine.LNX.4.44.0401012352180.11808-100000@localhost.localdomain>
Feldman, Scott wrote:
> On Tue, 30 Dec 2003, Mirko Lindner wrote:
>
>
>>>Make sure you don't duplicate any ethtool functions. We don't need a
>>>NIC-specific diag tool either ;-) ethtool is the preferred method
>>>moving forward, as it's already shipping in most Linux distros.
>>
>>Yes, we need it ;) No kidding! This is not a tool for SW checks like
>>media, link or driver version checks, but a tool for HW checks like
>>register, PROM, MAC, PHY and some other chip and card checks. The
>>ethtool is a great tool, but the intention of this tool is not the same.
>
>
> If the tool reports the results of running the h/w checks, then you can
> use ETHTOOL_TEST. The summary results of all the tests is reported as
> PASS/FAIL. Not sure if your tool needs to do more...
>
> -scott
>
>
>
>
> <!DSPAM:3ff51cdf53311090219406>
>
Scott,
thanks for this info, but the tool reports not only the status, but also
the results of a test (Example: "Register 0xxxx=xxx", PROM info...).
"Problem" 2: All tests are included in the DIAG tool and not in the
driver. We have approx. 100 separate tests (over 1000 individual tests)
and the driver is huge enough (Support for Genesis, Yukon, Yukon-Lite,
Yukon-Plus and Yukon2 chipsets).
Mirko
^ permalink raw reply
* [U-Boot-Users] lds question
From: Wolfgang Denk @ 2004-01-02 14:19 UTC (permalink / raw)
To: u-boot
In-Reply-To: <Pine.LNX.4.44.0312071900270.17468-100000@dallas.texasconnect.net>
In message <Pine.LNX.4.44.0312071900270.17468-100000@dallas.texasconnect.net> you wrote:
> The file u-boot.lds for the dbau1x00 boards contains the following line at
> the top:
>
> OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
>
> but to get the board to compile for little endian the line needs to be
> changed to:
>
> OUTPUT_FORMAT("elf32-tradlittlemips", "elf32-tradlittlemips", "elf32-tradlittlemips")
>
> but #ifdef doesn't seem to work in this file. What I came up with was
> acutally a hack in the top level config.mk file to use a different file I
> called u-boot-l.lds. Is there a better way?
You can omit this line in the linker script and use "ld" command line
options (--oformat) instead; you can probably use something like
"PLATFORM_LDFLAGS += ..." in your board directory config.mk file.
Best regards, and a Happy New Year!
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
"There is nothing new under the sun, but there are lots of old things
we don't know yet." - Ambrose Bierce
^ permalink raw reply
* [U-Boot-Users] memsetup.S patch for AU1X00
From: Wolfgang Denk @ 2004-01-02 14:14 UTC (permalink / raw)
To: u-boot
In-Reply-To: <Pine.LNX.4.44.0312071854400.17468-200000@dallas.texasconnect.net>
In message <Pine.LNX.4.44.0312071854400.17468-200000@dallas.texasconnect.net> you wrote:
>
> Attached is a patch for the memsetup.S for the au1x00 family of
> processors. The previous version had only been tested on the AU1000 in
> big endian mode, this has been tested on the AU1000 and AU1500 in both big
> and little endian modes.
Thanks, added.
Best regards, and a Happy New Year!
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
I'm frequently appalled by the low regard you Earthmen have for life.
-- Spock, "The Galileo Seven", stardate 2822.3
^ permalink raw reply
* Re: [linux-lvm] booting a dm+lvm2 kernel
From: Luca Berra @ 2004-01-02 14:12 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <OF1304E5DE.20B1794B-ON00256E0F.006B2F94-00256E0F.006B2FA0@svunta.os.is>
On Fri, Jan 02, 2004 at 07:30:45PM +0000, Kjartan Reynir Hauksson wrote:
>>work. You have to use the --lvm-version=2 option to mkinitrd.
>
>kernel panic, this time VFS: Cannot open root device "3a00" or 3a:00
ouch that should never happen, do you have anything printed above the kernel panic?
>Output from mkinitrd:
>
>[root@kjartan root]# mkinitrd -v -f --lvm-version=2 /boot/initrd-2.4.22.img
this seems ok
--
Luca Berra -- bluca@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
^ permalink raw reply
* Re: Alsa-1.0.0rc2 Hammerfall Light - small bug report
From: Martin Langer @ 2004-01-02 14:10 UTC (permalink / raw)
To: Mark Knecht; +Cc: Alsa-Devel
In-Reply-To: <1070763319.31277.0.camel@Wizard.knechthome.com>
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]
On Sat, Dec 06, 2003 at 06:15:19PM -0800, Mark Knecht wrote:
>
> Note ADAT3 which do not exist on
> this card.
>
>
> [mark@localhost mark]$ cat /proc/asound/card0/rme9652
[...]
> ADAT Sample rate: 44100Hz
> ADAT1: No Lock
> ADAT2: No Lock
> ADAT3: No Lock
>
This patch will remove the ADAT3 entry for light users. Please try it out,
because I don't have any hammerfall hardware.
martin
[-- Attachment #2: rme9652.patch --]
[-- Type: text/plain, Size: 881 bytes --]
Index: alsa-kernel/pci/rme9652/rme9652.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/rme9652/rme9652.c,v
retrieving revision 1.39
diff -u -r1.39 rme9652.c
--- alsa-kernel/pci/rme9652/rme9652.c 19 Dec 2003 09:27:04 -0000 1.39
+++ alsa-kernel/pci/rme9652/rme9652.c 2 Jan 2004 13:21:26 -0000
@@ -1798,11 +1798,13 @@
snd_iprintf(buffer, "ADAT2: No Lock\n");
}
- x = status & RME9652_sync_2;
- if (status & RME9652_lock_2) {
- snd_iprintf(buffer, "ADAT3: %s\n", x ? "Sync" : "Lock");
- } else {
- snd_iprintf(buffer, "ADAT3: No Lock\n");
+ if (rme9652->ss_channels == RME9652_NCHANNELS) {
+ x = status & RME9652_sync_2;
+ if (status & RME9652_lock_2) {
+ snd_iprintf(buffer, "ADAT3: %s\n", x ? "Sync" : "Lock");
+ } else {
+ snd_iprintf(buffer, "ADAT3: No Lock\n");
+ }
}
snd_iprintf(buffer, "\n");
^ permalink raw reply
* [U-Boot-Users] Little endian ethernet for AU1x00
From: Wolfgang Denk @ 2004-01-02 14:08 UTC (permalink / raw)
To: u-boot
In-Reply-To: <Pine.LNX.4.44.0312071851380.17468-200000@dallas.texasconnect.net>
In message <Pine.LNX.4.44.0312071851380.17468-200000@dallas.texasconnect.net> you wrote:
>
> The attached patch fixes ethernet for the AU1X00 family of processors when
> running in little-endian mode.
Added, thanks.
Best regards, and a Happy New Year!
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Status quo. Latin for "the mess we're in."
^ permalink raw reply
* [U-Boot-Users] Endian patch for AU1x00
From: Wolfgang Denk @ 2004-01-02 14:05 UTC (permalink / raw)
To: u-boot
In-Reply-To: <Pine.LNX.4.44.0312071846560.17468-200000@dallas.texasconnect.net>
Dear Ed,
in message <Pine.LNX.4.44.0312071846560.17468-200000@dallas.texasconnect.net> you wrote:
>
> Attached is an patch to cmd_ide.c that fixes endian issues for the AU1x00
> family of processors. Previously these processors could only read Compact
> Flash cards (and perhaps other IDE devices) if the drive was byte swapped
> from what is written by a standard PC. With this patch they can now read
> them without the bytes needing to be swapped.
>
Thanks (and sorry for the delay).
--- ../../u-boot/common/cmd_ide.c 2003-11-07 05:42:26.000000000 -0800
+++ cmd_ide.c 2003-11-30 13:13:53.000000000 -0800
@@ -172,7 +172,7 @@ static void __inline__ ide_outb(int dev,
static unsigned char __inline__ ide_inb(int dev, int port);
static void input_data(int dev, ulong *sect_buf, int words);
static void output_data(int dev, ulong *sect_buf, int words);
-static void ident_cpy (unsigned char *dest, unsigned char *src, unsigned int len);
+static void ident_cpy (unsigned char *dest, unsigned char *src, unsigned int len, int swap);
...
- ident_cpy (dev_desc->revision, iop->fw_rev, sizeof(dev_desc->revision));
- ident_cpy (dev_desc->vendor, iop->model, sizeof(dev_desc->vendor));
- ident_cpy (dev_desc->product, iop->serial_no, sizeof(dev_desc->product));
-
+#if defined(__LITTLE_ENDIAN)
+ ident_cpy (dev_desc->revision, iop->fw_rev, sizeof(dev_desc->revision), 1);
+ ident_cpy (dev_desc->vendor, iop->model, sizeof(dev_desc->vendor), 1);
+#else
+ ident_cpy (dev_desc->revision, iop->fw_rev, sizeof(dev_desc->revision), 0);
+ ident_cpy (dev_desc->vendor, iop->model, sizeof(dev_desc->vendor), 0);
+#endif
+ ident_cpy (dev_desc->product, iop->serial_no, sizeof(dev_desc->product), 0);
It seems to me that all information about endianess of the system is
(and has to be) know at compile time. In this case we should #ifdef
the code instead of passing additional (constant, known at compile
time) parameters.
Please re-work the patch.
Best regards, and a Happy New Year!
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Man is the best computer we can put aboard a spacecraft ... and the
only one that can be mass produced with unskilled labor.
- Wernher von Braun
^ permalink raw reply
* Re: [Bluez-devel] Bluetooth kernel patch for 2.6.0
From: Olivier Bornet @ 2004-01-02 14:04 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: BlueZ Mailing List
In-Reply-To: <1073041104.25261.15.camel@pegasus>
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
Hi Marcel,
> [1] http://www.holtmann.org/linux/kernel/patch-2.6.0-mh2.gz
Maybe you could add a link to it in your main kernel page
(http://www.holtmann.org/linux/kernel/)
So, it will be more easy to find it.
Thanks for it, and good day.
Olivier
--
Olivier Bornet http://www.smartdata.ch/
Olivier.Bornet@smartdata.ch SMARTDATA SA
GPG key ID: C53D9218 CH Martigny/Lausanne
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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.