* Possible problem in asm/bitops.h
From: Georg Klug @ 2002-12-11 15:31 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
today I tried to compile the iproute2-2.4.7-now-ss010824 for my walnut-like
custom board. But unfortunately it fails: (original make output below)
The reason seems to be that linux/inetdevice.h uses the inline function ffz()
to define another inline function inet_mask_len(). The ffz() function is
defined in the include file asm/bitops.h. But now there is some inconsistency
between the asm-i386/ and the asm-ppc/ directory: while the asm-i386/bitops.h
defines the ffz function for all includes, the asm-ppc/bitops.h restricts the
ffz function (and also some others) to kernel files (with #ifdef __KERNEL__).
I then tried to remove the #ifdef __KERNEL__ from the first significant line
of the asm-ppc/bitops.h file, but now the compiler complained about the missing
macro definition of PPC405_ERR77(). This one is defined in the asm-ppc/atomic.h
as well as in asm-ppc/ppc_asm.h, but - unfortunately - differently. (One has
double quotes, the other not.) The definition in atomic.h is only for kernel
files, but I moved it out of the #ifdef __KERNEL__ and could successfully
compile
iproute2.
But here are my questions:
Q: Is the ffz() function desgined to work in a user space application, too? If
yes, the file asm-ppc/bitops.h would need a change.
Q: Does it make any sense to define one single macro (PPC405_ERR77()) in
different
ways in different include files?
What is your opinion?
Kind regards,
Georg Klug
------------- output of the make ---------------------------------
make KERNEL_INCLUDE=/var/samba/Users/gklug/Work/tmp/linux-2.4.17_mvl21/include
CC=ppc_405-gcc
make[1]: Entering directory
`/var/samba/Users/gklug/Work/linux/tools/net/iproute2/lib'
ppc_405-gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -Werror -g -I../include-
glibc -include
../include-glibc/glibc-bugs.h -I/var/samba/Users/gklug/Work/tmp/linux-2.4.17_mvl
21/include -I../include -DRESOLVE_HOSTNAMES -c -o ll_map.o ll_map.c
ppc_405-gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -Werror -g -I../include-
glibc -include
../include-glibc/glibc-bugs.h -I/var/samba/Users/gklug/Work/tmp/linux-2.4.17_mvl
21/include -I../include -DRESOLVE_HOSTNAMES -c -o libnetlink.o libnetlink.c
ar rcs libnetlink.a ll_map.o libnetlink.o
ppc_405-gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -Werror -g -I../include-
glibc -include
../include-glibc/glibc-bugs.h -I/var/samba/Users/gklug/Work/tmp/linux-2.4.17_mvl
21/include -I../include -DRESOLVE_HOSTNAMES -c -o utils.o utils.c
cc1: warnings being treated as errors
In file included from ../include/utils.h:6,
from utils.c:30:
/var/samba/Users/gklug/Work/tmp/linux-2.4.17_mvl21/include/linux/inetdevice.h:
In function `inet_mask_len':
/var/samba/Users/gklug/Work/tmp/linux-2.4.17_mvl21/include/linux/inetdevice.h:16
3: warning: implicit declaration of function `ffz'
make[1]: *** [utils.o] Error 1
make[1]: Leaving directory
`/var/samba/Users/gklug/Work/linux/tools/net/iproute2/lib'
make: *** [all] Error 2
------------------------------------------------------------------
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* RE: NAND and concat
From: Christian Gan @ 2002-12-11 15:58 UTC (permalink / raw)
To: linux-mtd, yaffs list
In-Reply-To: <20021211000255.6A0C2149A7@dragon.actrix.co.nz>
Sorry Charles, I think the title should have been "NAND and mtdconcat". :)
> -----Original Message-----
> From: linux-mtd-admin@lists.infradead.org
> [mailto:linux-mtd-admin@lists.infradead.org]On Behalf Of Charles Manning
> Sent: Tuesday, December 10, 2002 5:58 PM
> To: Christian Gan; linux-mtd@lists.infradead.org; yaffs list
> Subject: Re: NAND and concat
>
>
> I'm not sure I understand what you mean by concat for NAND. Do
> you mean being
> able to read/write directly to the char device?
>
> Certainly handling OOB and pages makes things a bit different.
> Someone wrote
> a nand dumper which maybe does what you want (or can be persuaded
> :-). The
> yaffs format tool uses the char interface. It needs to expand to
> load up a
> mkyaffsimage image into flash.
>
> -- CHarles
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
^ permalink raw reply
* RE: NAND and concat
From: Christian Gan @ 2002-12-11 15:57 UTC (permalink / raw)
To: rkaiser, linux-mtd, yaffs list
In-Reply-To: <200212111138.gBBBcYs16381@dagobert.svc.sysgo.de>
I haven't really given it much thought either, but off the top of my head:
1. read_ecc and write_ecc
2. read_oob and write_oob
But really, I think this may be OK to do. Since I need something like this
for my project anyways I can give it a shot and test. Everything else
should be useable as is.
If anyone can think of anything I should watch out for, advice would be
great.
> -----Original Message-----
> From: linux-mtd-admin@lists.infradead.org
> [mailto:linux-mtd-admin@lists.infradead.org]On Behalf Of Robert Kaiser
> Sent: Wednesday, December 11, 2002 6:47 AM
> To: Christian Gan; linux-mtd@lists.infradead.org; yaffs list
> Subject: Re: NAND and concat
>
>
> Am Mittwoch, 11. Dezember 2002 00:29 schrieb Christian Gan:
> > Is anyone working on concat for NAND flashes?
>
> Probably not.
>
> > I looked though and realised
> > that there is no functionality at the moment for NAND (i.e. no
> support for
> > read/write oob etc).
>
> I must admit that I knew nothing about NAND flashes when I wrote
> the concat
> stuff (and this hasn't improved much in the meantime) :-(.
>
> OTOH, all the concat stuff does is to redirect calls to the
> hardware drivers,
> so, except for the maintaining of OOB data, what NAND specific
> functionality
> would be needed ?
>
> Rob
>
> ----------------------------------------------------------------
> Robert Kaiser email: rkaiser@sysgo.de
> SYSGO AG
> Am Pfaffenstein 14 phone: (49) 6136 9948-762
> D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
^ permalink raw reply
* AW: Completely discharging LION batteries
From: Herbert Nachtnebel @ 2002-12-11 15:26 UTC (permalink / raw)
To: acpi-devel-pyega4qmqnRoyOMFzWx49A
Hi!
> I'm using Linux 2.4.20 together with the acpi patches
> 20021205-2.4.20 on a
> Thinkpad T20. If I use two batteries (the builtin and a
> second in the Ultra-
> Bay), the second battery first gets discharged _completely_
> and after that the internal battery is used.
That's normal, but yes it is not the smartest idea to do.
> After completely discharging the battery, the
> maximum capacity to which the battery can be charged is only
> 28120 mWh,
> so I lost about 2000 mWh or about 8 percent of the battery capacity!!!
Yes that's correct, but a 8 percent drop is way to much.
It's a physical property that if Lion batteries are discharged
completely the capacity gets smaller. Hence in areas were reliability is
important (i.e. in satellites) lion batteries are never allowed to discharge
deeply. But on the other hand, from the manufacturer point of view this is
more than welcome. The customer has the replace his batteries sooner.
>
> So since I found that out I don't allow the Laptop to fully
> discharge the
> battery anymore. So may questions are: Can I set the capacity
> at which the
> Laptop switches to the builtin battery? Can you acknowledge
> my experiences?
The strategy is set by the BIOS or by the embedded controller, there is no
way to change it.
Herbert.
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Linux 2.4.21-pre1
From: Ralf Hildebrandt @ 2002-12-11 15:34 UTC (permalink / raw)
To: Alan Cox; +Cc: Ralf Hildebrandt, lkml
In-Reply-To: <1039622867.17709.31.camel@irongate.swansea.linux.org.uk>
* Alan Cox <alan@lxorguk.ukuu.org.uk>:
> On Wed, 2002-12-11 at 09:08, Ralf Hildebrandt wrote:
> > 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04)
> > 00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04)
> > 00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02)
> > 00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02)
> > 00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 02)
>
> Drive and controllers are what ?
According to the 2.4.20 kernel (see
http://www.stahl.bau.tu-bs.de/~hildeb/kernel/2.4.20.jpg for a snapshot
of the boot process!) the drives are:
hda: TOSHIBA MK4019GAX, ATA DISK drive
hdc: TOSHIBA DVD-ROM SD-R2102, ATAPI CD/DVD-ROM drive
And the controller:
ICH3M: chipset revision 2
--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt@charite.de
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
^ permalink raw reply
* Re: Framebuffer problems, 2.4.20-rc2, 2.5.51
From: Ivan Gyurdiev @ 2002-12-11 15:34 UTC (permalink / raw)
To: James Simmons; +Cc: LKML
In-Reply-To: <Pine.LNX.4.33.0212110818490.28554-100000@maxwell.earthlink.net>
> Did you enable framebuffer console in the console sub menu?
Yes.
^ permalink raw reply
* Re: Linux 2.4.21-pre1
From: Alan Cox @ 2002-12-11 16:07 UTC (permalink / raw)
To: Ralf Hildebrandt; +Cc: lkml
In-Reply-To: <20021211090829.GD8741@charite.de>
On Wed, 2002-12-11 at 09:08, Ralf Hildebrandt wrote:
> 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04)
> 00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04)
> 00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02)
> 00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02)
> 00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 02)
Drive and controllers are what ?
^ permalink raw reply
* Re: [ACPI] Re: [2.5.50, ACPI] link error
From: Alan Cox @ 2002-12-11 16:00 UTC (permalink / raw)
To: Ducrot Bruno
Cc: Andrew McGregor, Linux Kernel Mailing List, ACPI mailing list
In-Reply-To: <20021211101438.GC29390@poup.poupinou.org>
On Wed, 2002-12-11 at 10:14, Ducrot Bruno wrote:
> No. You are wrong. I need to suspend allmost all the drivers, and the
> video chipset is not an execption (or go to a console before suspending,
> in fact).
> You still need to bug NVIDIA in order to have proper pm support
> in their driver.
To an extent. However you can also switch back to text mode on suspend
to disk, then resume back into text mode and effectively switch back
into X11
^ permalink raw reply
* Re: Framebuffer problems, 2.4.20-rc2, 2.5.51
From: James Simmons @ 2002-12-11 16:19 UTC (permalink / raw)
To: Ivan Gyurdiev; +Cc: LKML
In-Reply-To: <200212110955.39586.ivg2@cornell.edu>
> 2.5.51:
> Kernel freezes upon loading the ATYFB driver.
> No error messages. Sysrq has no effect.
>
> Riva (tested without atyfb) shows a black screen, apparently
> followed by a kernel freeze since Sysrq has no effect.
>
> Kernel without boots without framebuffer, so the framebuffer causes the
> freeze.
Did you enable framebuffer console in the console sub menu?
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Justin T. Gibbs @ 2002-12-11 15:18 UTC (permalink / raw)
To: Christoph Hellwig, James Bottomley; +Cc: linux-scsi
In-Reply-To: <20021211135855.A19325@infradead.org>
> Okay, here's a lightly tested patch to get it in shape and
> compile/useable..
Why is this based on Alpha1 and not Alpha2. Several of the things
you fixed are already fixed in Alpha2. I just redownloaded what
I put up on my site and, as an example, verified that both the
pdev->driver_data and slave_alloc/configure/destroy stuff is already
in there (I wouldn't have been able to build on 2.5.X if it weren't).
Also, changes that remove compatibility ifdefs will be ignored. This
driver has to build all the way back to 2.4.7 (RedHat 7.2 support).
Removing ifdefs just makes it harder for me to merge in changes from
external trees. Yes, the ifdefs are ugly, but so is the Linux SCSI layer
and the unmanaged way that interfaces have been changed without any
consideration to backwards compatibility (eg. the HIGHIO stuff could have
been done with 0 impact to drivers, but wasn't for some strange reason).
> - fix kbuild integration
Can you explain what failed before? I don't mind using aic7xxx-y
or aic79xx-y instead of *-obj, but I would like to understand what
bug this fixes.
Thanks,
Justin
^ permalink raw reply
* Re: atyfb in 2.5.51
From: James Simmons @ 2002-12-11 15:16 UTC (permalink / raw)
To: David S. Miller
Cc: Benjamin Herrenschmidt, Paul Mackerras, Linux Kernel Mailing List,
Linux Fbdev development list
In-Reply-To: <1039596149.24691.2.camel@rth.ninka.net>
> I've always stated that the whole fbdev model was flawed, it makes
> basic assumptions about how a video card's memory and registers are
> accessed (ie. the programming model) and many popular cards absolutely
> do not fit into that model.
I agree that the design of the /dev/fbX interface is not the best.
Unfortunely we are stuck with it. Changing it would break userland apps.
> > I will have to go threw the X code to fix that :-(
>
> There is nothing to fix. You simply must restore the video state when
> the last mmap() client goes away. The __sparc__ code does exactly that.
I should of worded that better. Meaning I have to see what X is doing so
the fbdev driver sets the state itself better. Hm. I'm thinking about the
mmap approach versus the fb_open approach being used now.
> I think relying on an application that mmap's a card to perfectly
> restore the state would work in a perfect world, one we do not live
> in. Furthermore, fixing up the state like I am suggesting makes life
> much simpler for people actually working on things like X servers and
> other programs directly programming the ATI chip.
:-( True. We should always assume X or any userland app could be broken.
^ permalink raw reply
* [2.4]ALi M5451 sound hangs on init; workaround
From: Fedor Karpelevitch @ 2002-12-11 15:15 UTC (permalink / raw)
To: lkml; +Cc: Vicente Aguilar, alsa-devel, Debian-Laptops
[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]
I have ALi M5451 souncard in my laptop (Compaq Presario 900z for those
searching) and it hangs the machine with any kernel I tried
(currently 2.4.20-ac1 + hirofumi patch). I traced it down to the line
where it hangs - that is drivers/sound/trident.c:3379 which says:
pci_write_config_byte(pci_dev, 0xB8, ~temp);
removing this line fixes the problem for me.
I am not sure what would be the proper fix.
The hanging looks slightly different at different times: sometimes it
would just freeze, but sometimes it would would start giving ide
errors on any operation and sometimes it was giving this message:
"i8253 count too high! resetting." once or twice, but anyway the
system was not functional after that.
I got similar results with alsa drivers for this card, but I did not
debug that.
I am also getting several IRQ conflict messages on boot, I wonder if
that could be related to this problem and I wonder whether they are
something I should worry about or not.
Fedor
PS. some additional info about the system in case it is relevant: it's
Compaq Presario 900z with Athlon XP 1500+, lspci output is attached,
distribution is debian unstable.
[-- Attachment #2: lspci-vv.txt --]
[-- Type: text/plain, Size: 7691 bytes --]
00:00.0 Host bridge: ATI Technologies Inc: Unknown device cab0 (rev 13)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 64
Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
Region 1: Memory at f4400000 (32-bit, prefetchable) [size=4K]
Region 2: I/O ports at 8090 [disabled] [size=4]
Capabilities: [a0] AGP version 2.0
Status: RQ=15 SBA+ 64bit- FW+ Rate=x1,x2,x4
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 700f (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 99
Bus: primary=00, secondary=01, subordinate=01, sec-latency=68
I/O behind bridge: 00009000-00009fff
Memory behind bridge: f4100000-f41fffff
Prefetchable memory behind bridge: f6000000-f7ffffff
Secondary status: SERR
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
00:02.0 USB Controller: Acer Laboratories Inc. [ALi] USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
Subsystem: Acer Laboratories Inc. [ALi] USB 1.1 Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (20000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at f4010000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV]
Subsystem: Acer Laboratories Inc. [ALi] ALI M1533 Aladdin IV ISA Bridge
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [a0] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:08.0 Multimedia audio controller: Acer Laboratories Inc. [ALi] M5451 PCI AC-Link Controller Audio Device (rev 02)
Subsystem: Compaq Computer Corporation: Unknown device 00b0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR+ <PERR+
Latency: 64 (500ns min, 6000ns max)
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at 8400 [size=256]
Region 1: Memory at f4011000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0a.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02)
Subsystem: Compaq Computer Corporation: Unknown device 00b0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Interrupt: pin A routed to IRQ 0
Region 0: Memory at ffbfe000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=02, subordinate=05, sec-latency=0
Memory window 1: fbbfd000-ffbfc000 (prefetchable)
I/O window 0: 00000000-00000003
I/O window 1: 00000000-00000003
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite-
16-bit legacy interface ports at 0001
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 20)
Subsystem: Compaq Computer Corporation: Unknown device 00b0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (8000ns min, 16000ns max), cache line size 10
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 8800 [size=256]
Region 1: Memory at f4013000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0c.0 Communication controller: Conexant HSF 56k HSFi Modem (rev 01)
Subsystem: Compaq Computer Corporation: Unknown device 8d88
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 10
Region 0: Memory at f4000000 (32-bit, non-prefetchable) [size=64K]
Region 1: I/O ports at 8098 [size=8]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0f.0 USB Controller: Acer Laboratories Inc. [ALi] USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
Subsystem: Acer Laboratories Inc. [ALi] USB 1.1 Controller
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 11
Region 0: Memory at f4012000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:10.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c4) (prog-if fa)
Subsystem: Acer Laboratories Inc. [ALi] M5229 IDE
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (500ns min, 1000ns max)
Interrupt: pin A routed to IRQ 0
Region 4: I/O ports at 8080 [size=16]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:11.0 Bridge: Acer Laboratories Inc. [ALi] M7101 PMU
Subsystem: Acer Laboratories Inc. [ALi] ALI M7101 Power Management Controller
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
01:05.0 VGA compatible controller: ATI Technologies Inc: Unknown device 4336 (prog-if 00 [VGA])
Subsystem: Compaq Computer Corporation: Unknown device 00b0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B+
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 66 (2000ns min), cache line size 10
Interrupt: pin A routed to IRQ 10
Region 0: Memory at f6000000 (32-bit, prefetchable) [size=32M]
Region 1: I/O ports at 9000 [size=256]
Region 2: Memory at f4100000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Status: RQ=47 SBA+ 64bit- FW- Rate=x1,x2,x4
Command: RQ=0 SBA+ AGP- 64bit- FW- Rate=<none>
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
[-- Attachment #3: dmesg.txt --]
[-- Type: text/plain, Size: 6658 bytes --]
Linux version 2.4.20-tridentfix (root@bologoe.karpelevitch.net) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 Tue Dec 10 15:08:22 PST 2002
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009e800 (usable)
BIOS-e820: 000000000009e800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000d0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000eef0000 (usable)
BIOS-e820: 000000000eef0000 - 000000000eeff000 (ACPI data)
BIOS-e820: 000000000eeff000 - 000000000ef00000 (ACPI NVS)
BIOS-e820: 000000000ef00000 - 000000000f000000 (usable)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
240MB LOWMEM available.
On node 0 totalpages: 61440
zone(0): 4096 pages.
zone(1): 57344 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=Linux ro root=302 ide0=ata66 ide1=ata66
ide_setup: ide0=ata66
ide_setup: ide1=ata66
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Initializing CPU#0
Detected 1325.116 MHz processor.
Console: colour VGA+ 80x50
Calibrating delay loop... 2641.10 BogoMIPS
Memory: 240568k/245760k available (1192k kernel code, 4736k reserved, 360k data, 264k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbff c1cbfbff 00000000 00000000
CPU: Common caps: 0383fbff c1cbfbff 00000000 00000000
CPU: AMD Mobile AMD Athlon(tm) XP 1500+ stepping 00
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1325.1467 MHz.
..... host bus clock speed is 265.0292 MHz.
cpu: 0, clocks: 2650292, slice: 1325146
CPU0<T0:2650288,T1:1325136,D:6,S:1325146,C:2650292>
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfd87e, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router ALI [10b9/1533] at 00:07.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
ACPI: Core Subsystem version [20011018]
ACPI: Subsystem enabled
ACPI: System firmware supports S0 S3 S4 S5
Processor[0]: C0 C1, 8 throttling states
ACPI: AC Adapter found
ACPI: Power Button (FF) found
ACPI: Multiple power buttons detected, ignoring fixed-feature
ACPI: Power Button (CM) found
ACPI: Sleep Button (FF) found
ACPI: Multiple sleep buttons detected, ignoring fixed-feature
ACPI: Sleep Button (CM) found
ACPI: Lid Switch (CM) found
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ALI15X3: IDE controller on PCI bus 00 dev 80
PCI: No IRQ known for interrupt pin A of device 00:10.0. Please try using pci=biosirq.
ALI15X3: chipset revision 196
ALI15X3: not 100% native mode: will probe irqs later
ALI15X3: ATA-66/100 forced bit set (WARNING)!!
ide0: BM-DMA at 0x8080-0x8087, BIOS settings: hda:DMA, hdb:pio
ALI15X3: ATA-66/100 forced bit set (WARNING)!!
ide1: BM-DMA at 0x8088-0x808f, BIOS settings: hdc:pio, hdd:pio
hda: FUJITSU MHR2030AT, ATA DISK drive
hdc: Compaq DVD-ROM SD-C2612, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 58605120 sectors (30006 MB) w/2048KiB Cache, CHS=3648/255/63
hdc: ATAPI 24X DVD-ROM drive, 192kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
Partition check:
/dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 p8 > p4
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 190M
agpgart: unsupported bridge
agpgart: no supported devices found.
[drm] Initialized radeon 1.1.1 20010405 on minor 0
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 264k freed
Adding Swap: 289128k swap-space (priority -1)
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal
8139cp: 10/100 PCI Ethernet driver v0.3.0 (Sep 29, 2002)
PCI: Assigned IRQ 11 for device 00:0b.0
IRQ routing conflict for 00:0c.0, have irq 10, want irq 11
IRQ routing conflict for 01:05.0, have irq 10, want irq 11
eth0: RTL-8139C+ at 0xcf848000, 00:08:02:f3:99:58, IRQ 11
Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, version 0.14.10h, 15:13:01 Dec 10 2002
PCI: Found IRQ 4 for device 00:08.0
IRQ routing conflict for 00:08.0, have irq 5, want irq 4
trident: ALi Audio Accelerator found at IO 0x8400, IRQ 5
ac97_codec: AC97 Audio codec, id: ADS97(Analog Devices AD1886)
spurious 8259A interrupt: IRQ7.
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,5), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,6), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,7), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,8), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
eth0: link down
eth0: link down
mtrr: no more MTRRs available
mtrr: no more MTRRs available
mtrr: no more MTRRs available
mtrr: no more MTRRs available
^ permalink raw reply
* Re: Regarding consistent_alloc
From: Pantelis Antoniou @ 2002-12-11 15:07 UTC (permalink / raw)
To: Tom Rini
Cc: joakim.tjernlund, acurtis, Dan Malek, Paul Mackerras, Matt Porter,
linuxppc-embedded
In-Reply-To: <20021211145658.GA19456@opus.bloom.county>
Tom Rini wrote:
>On Wed, Dec 11, 2002 at 11:58:45AM +0200, Pantelis Antoniou wrote:
>
>[snip]
>
>>I think it's safe to assume that there is large amount of confussion at
>>this subject.
>>
>
>Definatly.
>
;)
>
>>FWIW I dislike the use of iopa(), and I would be forced to duplicate the
>>code of
>>consistent_alloc() class of functions in my tree.
>>
>
>Why would you have to duplicate the consistent_alloc code? It is not
>tied to PCI, really.
>
Let's just say it's aesthetically unpleasent.
Since it is not tied to PCI anyway, what is the point
muddling it with it?
Perhaps the best way to proceed is just to fix the xxx_cpm_hostalloc() and
xxx_cpm_dpalloc() routines to work more intelligently, and to
forget about consistent_alloc entirely...
Regards
--
Pantelis Antoniou
INTRACOM S.A. Greece
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: hostname forwarding
From: Patrick Maartense @ 2002-12-11 15:06 UTC (permalink / raw)
To: bernard; +Cc: netfilter
In-Reply-To: <p04330105ba1cf39a28eb@[80.9.157.3]>
this is not possible using ipotables
Apache however can very well handle this ..
On Wed, 11 Dec 2002, bernard wrote:
> I'm using iptables to redirect external requests depending on their
> port/protocol like this :
>
> hostname A:80 -> public ip -> iptables -> 192.168.1.1:80
> hostname B:80 -> public ip -> iptables -> 192.168.1.1:80
>
> It works pretty well, thanks to iptables :-)
>
> Now I want to redirect on a hostname basis on different private ip's
> like this :
>
> hostname A:80 -> public ip -> iptables -> 192.168.1.1:80
> hostname B:80 -> public ip -> iptables -> 192.168.1.2:80
>
> Does anyone know a solution ?
>
> Thanks for your help.
>
> Bernard
>
--
---
Kind Regards
Patrick Maartense (using Pine on a Text Console)
^ permalink raw reply
* Re: [lvm-devel] Re: [PATCH] dm.c - device-mapper I/O path fixes
From: Joe Thornber @ 2002-12-11 15:12 UTC (permalink / raw)
To: lvm-devel; +Cc: Denis Vlasenko, Joe Thornber, Kernel Mailing List
In-Reply-To: <02121108022404.29515@boiler>
On Wed, Dec 11, 2002 at 08:02:24AM -0600, Kevin Corry wrote:
> Perhaps we could make "error" and atomic_t, and store the absolute-value of
> the error code, and always return -error in the bio_endio() call. Or is that
> just too ugly?
Too ugly :)
^ permalink raw reply
* Re: Modifying Source Ip on input/prerouting
From: Andrea Rossato @ 2002-12-11 15:02 UTC (permalink / raw)
To: netfilter
In-Reply-To: <20021211135812.GA8394@nath.rubis.org>
Stephane Jourdois wrote:
> I would need to be able to modify the source ip on input GRE paquets.
> This is because I'm trying to setup a pptp tunnel, via a router that
> doesn't NAT correctly the GRE.
> The client receives GRE, but replies with it's own local ip, then my
> server cannot receive the answers... If I could just change the source
> ip on those paquets, that would be perfect...
i don't know if I've got your problem correctly, also because I don't
know pptp too much (so, shut up, you'll say...;)
if you want to match gre packets and change their source address (not
the source addr. of encapsulated packets) you should be able with
iptables -A POSTROUTING -t nat -p gre -j SNAT --to-source
new-grepacket-source-addr
this will match all outgoing (from the client) traffic using gre protocol.
but is this what you need?
where are the tunnel end points? the router has two tunnels connecting
the server and the client? the tunnel is between the router and the server?
Instead, if you want to change source address of encasplulated packets,
that would be interesting...
^ permalink raw reply
* Re: Oops 2.4.20-ac1 & 2.4.21-pre1 ide-scsi
From: Alan Cox @ 2002-12-11 15:46 UTC (permalink / raw)
To: Alexander Grishin; +Cc: Linux Kernel Mailing List
In-Reply-To: <200212110907.58987.gri@ses.bryansk.elektra.ru>
On Wed, 2002-12-11 at 06:07, Alexander Grishin wrote:
> The next commands:
>
> modprobe ide-scsi
> rmmod ide-scsi
> mount -t iso9660 /dev/hdc /mnt
I'll look into that
^ permalink raw reply
* Re: Regarding consistent_alloc
From: Pantelis Antoniou @ 2002-12-11 15:01 UTC (permalink / raw)
To: acurtis
Cc: joakim.tjernlund, Tom Rini, Dan Malek, Paul Mackerras,
Matt Porter, linuxppc-embedded
In-Reply-To: <NCBBIINEHIPFGJPLBEIFCEPEDPAA.acurtis@directvinternet.com>
acurtis@directvinternet.com wrote:
>>>>m8xx_cpm_hostalloc(), if it is anything like the 8260 version,
>>>>
>>enables you
>>
>>>>to allocation memory from dual-port RAM. (which could be handy and/or
>>>>required for certain CPM related operations) _va() and _pa()
>>>>
>>only work for
>>
>>>>main memory addresses. For all other address ranges the iopa()
>>>>
>>function must
>>
>>>>be used. (I hope this is helpful)
>>>>
>>>>
>
>snip
>
>
>>Each platform which is based on 8xx defines the amount of uncached
>>memory that is expected
>>to be used by it's drivers. It's not hard to make a rough estimation
>>since most people
>>that use the 8xx have very tight control of the hardware.
>>We organize then the memory in a heap, which is able to do allocations and
>>deallocations properly. That allows drivers that are loaded as modules
>>to operate
>>correctly and does not fragment (much) the memory.
>>
>
>I almost missed the context change here... Changing xxx_cpm_hostalloc() to
>be consistent with other main memory allocation routines would probably be a
>good thing. However there is still a need to manage the dual-port RAM, i.e.
>xxx_cpm_dpalloc(), where this requirement is probably not practical. The
>only way to make this happen is to force all memory regions to be contiguous
>both virtually and physically to enable the "simpler" address translation
>routines to function properly.
>
>As for a iova() routine, ioremap() will return a previously configured
>virtual address when asked to map the same physical memory space.
>
>
>
>
I'm sorry but I don't follow you there. The sole reason for the existance
of xxx_cpm_hostalloc() and xxx_cpm_dpalloc() is to provide support to
the drivers that deal with the CPM. I don't see why is there any need
to be consistent with any other allocation routines in the kernel.
Lets assume that we force the memory returned by the xxx_cpm_hostalloc()
and xxx_cpm_dpalloc() routines to return contiguous memory both
virtually and physically. Is there any negative impact?
Every driver out there expects precisely that.
Regarding the dual-ported memory, keep in mind that there are members
of the 8xx family that are very constrained.
Better allocation routines will allow us to utilise even the gaps
left between configured parameter areas. Yes it is horrible
but that's the way that the hardware is designed.
As I already mentioned, I have some patches that fix IMHO these
problems. Allow me some time to clean up and I will post them.
Regards
--
Pantelis Antoniou
INTRACOM S.A. Greece
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Regarding consistent_alloc
From: Tom Rini @ 2002-12-11 14:56 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: joakim.tjernlund, acurtis, Dan Malek, Paul Mackerras, Matt Porter,
linuxppc-embedded
In-Reply-To: <3DF70C55.3010709@intracom.gr>
On Wed, Dec 11, 2002 at 11:58:45AM +0200, Pantelis Antoniou wrote:
[snip]
> I think it's safe to assume that there is large amount of confussion at
> this subject.
Definatly.
> FWIW I dislike the use of iopa(), and I would be forced to duplicate the
> code of
> consistent_alloc() class of functions in my tree.
Why would you have to duplicate the consistent_alloc code? It is not
tied to PCI, really.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: PWM on the MPC850
From: Wolfgang Denk @ 2002-12-11 14:54 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <IGEFJKJNHJDCBKALBJLLAELKFIAA.joakim.tjernlund@lumentis.se>
In message <IGEFJKJNHJDCBKALBJLLAELKFIAA.joakim.tjernlund@lumentis.se> you wrote:
>
> > But be warned: do NOT use any of the port B pins for I/O in such a
> > setup. There is a race condition within all MPC8xx CPUs.
>
> hmm, we access a few port B I/O pins from user space. What/where is the
> race in kernel?
I should add that it is non-trivial to work around this issue. We had
a case where even the short spikes on the output caused by this race
condition were not acceptable. The only way to make this work was to
disable the PWM timers (and wait for them to shut down - which is
another issue) before moifying the port B data, and then start them
up again. Of course this is unacceptable when you need high precision
PWM signals (but the you would not use a MPC8xx RISC timer anyway).
My recommendation is: never, ever use the RISC timers if you need to
know hwat's going on on port B.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
"Free markets select for winning solutions." - Eric S. Raymond
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: PWM on the MPC850
From: Wolfgang Denk @ 2002-12-11 14:50 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-embedded
In-Reply-To: <IGEFJKJNHJDCBKALBJLLAELKFIAA.joakim.tjernlund@lumentis.se>
In message <IGEFJKJNHJDCBKALBJLLAELKFIAA.joakim.tjernlund@lumentis.se> you wrote:
>
> > But be warned: do NOT use any of the port B pins for I/O in such a
> > setup. There is a race condition within all MPC8xx CPUs.
>
> hmm, we access a few port B I/O pins from user space. What/where is the
> race in kernel?
It's not in the kernel, it's in the MPC8xxL.
The RISC timers are implemented in softtware (microcode) running on
the CPM. To toggle a PWM output pin, the CPM will read the port B
data register, modify the bit, and rewrite the port B data register,
This access is NOT synchronized against any accesses by the CPU. You
can test this by toggeling a port B pin with software running on the
CPU: after each write to the port B data register read the register
back for a couple of times. You will find that, as soon as a PWM
timer is running, the value you write will not "stick".
It's a classical race condition: the CPM reads PBDAT to modify a PWM
pin, then the CPU writes a new value (modifying a different bit), the
the CPM writes his copy back - and the value written by the CPU gets
lost. You can see this on an oscilloscope: the data written by the
CPU will be actually there onthe outputs for some 15...25 ns (nano!),
and then drop back to the old state.
Moto never officially confirmed the problem, but the MPC823E UM (I
didn't find this anywhere else) contains the traitorous words:
[16.2.6.4.4 PWM Mode] ... Because the CPM has to read the
data register, modify it and then write it back, you cannot
use open drain output with the PWMs if the output can be
forced to 0 by external devices.
This is IMHO related to the same problem.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
Writing a book is like washing an elephant: there's no good place to
begin or end, and it's hard to keep track of what you've already
covered.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [lvm-devel] Re: [PATCH] dm.c - device-mapper I/O path fixes
From: Joe Thornber @ 2002-12-11 14:58 UTC (permalink / raw)
To: lvm-devel; +Cc: Kevin Corry, Joe Thornber, Kernel Mailing List
In-Reply-To: <200212111430.gBBETua06759@Port.imtp.ilyichevsk.odessa.ua>
On Wed, Dec 11, 2002 at 05:19:33PM -0200, Denis Vlasenko wrote:
> > Are you saying the "if (error)" part is pointless? If so, I have to
>
> No. Locking is pointless. What exactly you try to protect here?
io->error from being updated concurrently.
^ permalink raw reply
* [PATCH 2.4.21-pre1 RESEND] CREDITS update
From: Stelian Pop @ 2002-12-11 14:53 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Marcelo Tosatti
Hi,
This patch updates my current CREDITS and MAINTAINERS entry.
Marcelo, please apply.
Stelian.
===== CREDITS 1.59 vs edited =====
--- 1.59/CREDITS Mon Dec 9 09:13:59 2002
+++ edited/CREDITS Tue Dec 10 11:54:20 2002
@@ -2397,13 +2397,10 @@
D: CDROM driver "sonycd535" (Sony CDU-535/531)
N: Stelian Pop
-E: stelian.pop@fr.alcove.com
+E: stelian@popies.net
P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0 D3F7 7185 9E7A EDBB 6147
D: sonypi, meye drivers, mct_u232 usb serial hacks
-S: Alcôve
-S: 153, bd. Anatole France
-S: 93200 Saint Denis
-S: France
+S: Paris, France
N: Frederic Potter
E: fpotter@cirpack.com
===== MAINTAINERS 1.88 vs edited =====
--- 1.88/MAINTAINERS Fri Dec 6 20:12:01 2002
+++ edited/MAINTAINERS Wed Dec 11 10:18:09 2002
@@ -1041,6 +1041,12 @@
L: linux-kernel@vger.kernel.org
S: Maintained
+MOTION EYE VAIO PICTUREBOOK CAMERA DRIVER
+P: Stelian Pop
+M: stelian@popies.net
+W: http://popies.net/meye/
+S: Maintained
+
MOUSE AND MISC DEVICES [GENERAL]
P: Alessandro Rubini
M: rubini@ipvvis.unipv.it
@@ -1485,6 +1491,12 @@
P: Thomas Bogendoerfer
M: tsbogend@alpha.franken.de
L: linux-net@vger.kernel.org
+S: Maintained
+
+SONY VAIO CONTROL DEVICE DRIVER
+P: Stelian Pop
+M: stelian@popies.net
+W: http://popies.net/sonypi/
S: Maintained
SOUND
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply
* Framebuffer problems, 2.4.20-rc2, 2.5.51
From: Ivan Gyurdiev @ 2002-12-11 14:55 UTC (permalink / raw)
To: LKML
Hardware:
00:0a.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev
5c)
01:00.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3 Ti200]
(rev a3)
Using ATYFB with CONFIG_FB_ATY, CONFIG_FB_ATY_CT and RIVAFB
2.4.20-rc2:
Kernel freezes upon loading the ATYFB driver.
No error messages.Sysrq has no effect.
Riva framebuffer alone works.
2.5.51:
Kernel freezes upon loading the ATYFB driver.
No error messages. Sysrq has no effect.
Riva (tested without atyfb) shows a black screen, apparently
followed by a kernel freeze since Sysrq has no effect.
Kernel without boots without framebuffer, so the framebuffer causes the
freeze.
==================================
^ permalink raw reply
* Re: [PATCH] dm.c - device-mapper I/O path fixes
From: Kevin Corry @ 2002-12-11 14:06 UTC (permalink / raw)
To: Denis Vlasenko, Joe Thornber; +Cc: Kernel Mailing List, lvm-devel
In-Reply-To: <200212111435.gBBEYWa06788@Port.imtp.ilyichevsk.odessa.ua>
On Wednesday 11 December 2002 13:24, Denis Vlasenko wrote:
> On 11 December 2002 12:18, Joe Thornber wrote:
> > On Wed, Dec 11, 2002 at 07:16:53AM -0600, Kevin Corry wrote:
> > > However, it might be a good idea to consider how bio's keep track
> > > of errors. When a bio is created, it is marked UPTODATE. Then, if
> > > any part of a bio takes an error, the UPTODATE flag is turned off.
> > > When the whole bio completes, if the UPTODATE flag is still on,
> > > there were no errors during the i/o. Perhaps the "error" field in
> > > "struct dm_io" could be modified to use this method of error
> > > tracking? Then we could change dec_pending() to be something like:
> > >
> > > if (error)
> > > clear_bit(DM_IO_UPTODATE, &io->error);
> > >
> > > with a "set_bit(DM_IO_UPTODATE, &ci.io->error);" in __bio_split().
> >
> > The problem with this is you don't keep track of the specific error
> > to later pass to bio_endio(io->bio...). I guess it all comes down to
> > just how expensive that spin lock is; and since locking only occurs
> > when there's an error I'm happy with things as they are.
>
> lock();
> a = b;
> unlock();
>
> Store of ints is atomic anyway. You need locking if a is a larger entity,
> say, a struct.
Storing an int is *not* atomic unless it is declared as atomic_t and you use
the appropriate macros (see include/asm-*/atomic.h). Remember, we are talking
about a field in a data structure that can be accessed from multiple threads
on multiple CPUs.
--
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/
^ 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.