* Re: [PATCH 17/21] orinoco_pci: use pci_iomap() for resources
From: Francois Romieu @ 2006-04-07 21:36 UTC (permalink / raw)
To: Pavel Roskin
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
orinoco-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20060407081053.16107.19347.stgit-fdEtzkpK75rby3iVrkZq2A@public.gmane.org>
Pavel Roskin <proski-mXXj517/zsQ@public.gmane.org> :
[...]
> diff --git a/drivers/net/wireless/orinoco_pci.c b/drivers/net/wireless/orinoco_pci.c
> index e57e92b..75df90f 100644
> --- a/drivers/net/wireless/orinoco_pci.c
> +++ b/drivers/net/wireless/orinoco_pci.c
> @@ -170,9 +170,7 @@ static int orinoco_pci_init_one(struct p
> const struct pci_device_id *ent)
> {
> int err = 0;
> - unsigned long pci_iorange;
> - u16 __iomem *pci_ioaddr = NULL;
> - unsigned long pci_iolen;
> + void __iomem *pci_ioaddr = NULL;
> struct orinoco_private *priv = NULL;
> struct orinoco_pci_card *card;
> struct net_device *dev = NULL;
(ok, the useless initializers disappear later in the serie)
[...]
> @@ -208,8 +205,8 @@ static int orinoco_pci_init_one(struct p
> priv = netdev_priv(dev);
> card = priv->card;
> card->pci_ioaddr = pci_ioaddr;
> - dev->mem_start = pci_iorange;
> - dev->mem_end = pci_iorange + pci_iolen - 1;
> + dev->mem_start = pci_resource_start(pdev, 0);
> + dev->mem_end = dev->mem_start + pci_resource_len(pdev, 0) - 1;
Is there a reason why dev->mem_{start/end} should not be removed ?
--
Ueimor
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [RFC/POC] multiple CONFIG y/m/n
From: Randy.Dunlap @ 2006-04-07 21:36 UTC (permalink / raw)
To: Roman Zippel; +Cc: sam, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0604072315530.32445@scrub.home>
On Fri, 7 Apr 2006 23:24:44 +0200 (CEST) Roman Zippel wrote:
> Hi,
>
> On Fri, 7 Apr 2006, Sam Ravnborg wrote:
>
> > > In doing lots of kernel build testing, I often want to enable all options
> > > in a sub-menu and their sub-sub-menus. Sound is one of the worst^W longest
> > > of these, so I chose a shorter (easier) one to practice on: parport.
> > If there is a general need for this we shal enhance kconfig with this.
> > We shall not clutter the Kconfig files with this.
>
> I agree.
> >From a general perspective I still like to add some basic command line
> tool, which can be used for queries or simple manipulations. Here it also
> would be less a problem to add experimental or distribution specific
> functionality instead of overloading conf.c.
> At some point I even had script bindings (via swig), so one could do even
> weirder stuff.
Yep, no problem with Sam's or your reply. Thanks for looking.
---
~Randy
^ permalink raw reply
* Re: [Qemu-devel] SPARC iommu mapping
From: Joerg Platte @ 2006-04-07 21:33 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <BAY104-F117C8B7ECF3ED07C6591A9FFC90@phx.gbl>
Am Freitag, 7. April 2006 17:44 schrieb Blue Swirl:
Hi!
> Thank you for the excellent analysis of the problem! Looks like Qemu
> doesn't handle the case where DMA length and SCSI length are not equal.
Exact.
> So Linux splits the transfer into two parts to use two separate pieces of
> buffers. Funny, I thought this situation was exactly the one which
> virtually addressed DMA would prevent from happening.
I read somewhere, that Solaris and Linux unfortunately do not try to allocate
subsequent virtual addresses.
> Yes, there will be an interrupt. I didn't find this situation in the
> NCR53C9X.txt file documenting the ESP, though.
Me too. I tried to understand what's going wrong, but it is not that easy to
understand the Linux source, if you don't know much about the hardware and
the esp/iommu/dma/sbus architecture.
> There are two cases:
> 1 - DMA length shorter than SCSI (your case)
> 2 - SCSI length shorter (could happen in command replies etc.)
>
> Maybe this patch helps?
Unfortunately not. I tried a similar approach, but it didn't work. Here is the
dump:
First the mapping, similar to the one described in the last mail:
IOMMU: page flush f0039000
IOMMU: page flush f003a000
IOMMU: page flush f003b000
IOMMU: page flush f003c000
IOMMU: page flush f003d000
IOMMU: page flush f003e000
IOMMU: page flush f003f000
IOMMU: page flush f0040000
IOMMU: page flush f0041000
IOMMU: page flush f0042000
IOMMU: page flush f0043000
IOMMU: page flush f0044000
IOMMU: page flush f0045000
IOMMU: page flush f000e000
Then the transfer, which stops after three pages, since the Transfer
information len is 12288:
ESP: Transfer Information len 12288
ESP: DMA Direction: r, addr 0x0bdea000 0000e000
ESP: DMA address p 0bdea000 v f0039000
ESP: DMA address p 0bdeb000 v f003a000
ESP: DMA address p 0bdec000 v f003b000
ESP: Write callback (offset 224 len 112 size 57344 trans_size 12288)
Now I would expect, that "somebody" (maybe the esp inerrupt handler) updates
the dma registers to map the remaining pages. But this does not happen. Linux
simply unmaps the old mapping:
IOMMU: page flush f0039000
IOMMU: page flush f003a000
IOMMU: page flush f003b000
IOMMU: page flush f003c000
IOMMU: page flush f003d000
IOMMU: page flush f003e000
IOMMU: page flush f003f000
IOMMU: page flush f0040000
IOMMU: page flush f0041000
IOMMU: page flush f0042000
IOMMU: page flush f0043000
IOMMU: page flush f0044000
IOMMU: page flush f0045000
IOMMU: page flush f000e000
and configures a new one:
IOMMU: page flush f000f000
IOMMU: page flush f0010000
IOMMU: page flush f0011000
IOMMU: page flush f0012000
IOMMU: page flush f0013000
IOMMU: page flush f0014000
IOMMU: page flush f0015000
IOMMU: page flush f0016000
IOMMU: page flush f0017000
IOMMU: page flush f0018000
IOMMU: page flush f0019000
IOMMU: page flush f001a000
IOMMU: page flush f001b000
IOMMU: page flush f001c000
Then, a few pages of the new mapping are written to disk:
ESP: Transfer Information len 36864
ESP: DMA Direction: r, addr 0x0bdfa000 0000e000
ESP: DMA address p 0bdfa000 v f000f000
ESP: DMA address p 0bdfb000 v f0010000
ESP: DMA address p 0bdfc000 v f0011000
ESP: DMA address p 0bdfd000 v f0012000
ESP: DMA address p 0bdfe000 v f0013000
ESP: DMA address p 0bdff000 v f0014000
ESP: DMA address p 0be00000 v f0015000
ESP: DMA address p 0be01000 v f0016000
ESP: DMA address p 0be02000 v f0017000
ESP: Write callback (offset 336 len 112 size 57344 trans_size 36864)
Then this ara is unmapped, and Linux continues with the next area.
Hence, your patch avoids the zero mapping, but it does not provide the
required information which should result in a new dma addressing to write the
remaining mapped data. Tomorrow, I'll try to enable more debbugging in the
Linux driver to try to find out what's going wrong. But with a real hardware
it's more difficult to get an idea of the internal functions :(
regards,
Jörg
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-07 21:32 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2008>
======================================================================
Reported By: mborsick
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2008
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Redhat/Fedora
Kernel Version: 2.6.16-1.2080 and with Xen
======================================================================
Date Submitted: 04-07-2006 00:43 CEST
Last Modified: 04-07-2006 23:32 CEST
======================================================================
Summary: No Sound with snd-hda-intel driver Asus P5VDC-MX
Description:
Kernel is up-to-date Xen kernel.
Initial install did not recognize the sound on an ASUS P5VDC-MX
motherboard.
Motherboard has southbridge VIA VT8251. CODEC is Realtek ACL653 AC'97 6
channel
Audio. Tried the updated drivers in 002404, but was unsuccessful. Also
tried
drivers on VIA site and Realltek site. The last couple of tries show no
errors
in compiling, make, etc. However, as I am just above novice in
understanding
everything about Linux, this has thrown me for a loop.
======================================================================
----------------------------------------------------------------------
buboleck - 04-07-06 23:26
----------------------------------------------------------------------
Despite this PCI/whatever issue, the fact is that the sound is not working.
Maybe this is all related to the vt8251 chipset.
----------------------------------------------------------------------
rlrevell - 04-07-06 23:32
----------------------------------------------------------------------
"This 05:08:0 and 05:09:0 was not seen with the default "PCI access
mode"=ANY and PCIx ON.I use Gentoo kernel gentoo-sources-2.15-r8 (x86), I
hope this can help."
So if you boot with the default settings lspci shows no sound cards at
all?
This is a kernel or BIOS issue - there's nothing ALSA can do if the sound
card doesn't appear on the bus.
What sound card is this thing supposed to have? I can't believe you both
have the same board but lspci is showing three different soundcards?
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 00:43 mborsick New Issue
04-07-06 00:43 mborsick Distribution => Redhat/Fedora
04-07-06 00:43 mborsick Kernel Version => 2.6.16-1.2080 and
with Xen
04-07-06 01:07 rlrevell Note Added: 0009129
04-07-06 02:13 mborsick Note Added: 0009130
04-07-06 02:35 rlrevell Note Added: 0009131
04-07-06 06:38 mborsick Note Added: 0009135
04-07-06 22:45 buboleck Note Added: 0009156
04-07-06 22:47 buboleck Note Edited: 0009156
04-07-06 22:49 buboleck Note Edited: 0009156
04-07-06 23:06 rlrevell Note Added: 0009157
04-07-06 23:16 buboleck Issue Monitored: buboleck
04-07-06 23:26 buboleck Note Added: 0009158
04-07-06 23:32 rlrevell Note Added: 0009159
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: make *config problem (breaks miniconfig.sh)
From: Roman Zippel @ 2006-04-07 21:28 UTC (permalink / raw)
To: Piotr Muszynski; +Cc: linux-kernel
In-Reply-To: <c03109120604060438n58657c97iea4bfa5342747f18@mail.gmail.com>
Hi,
On Thu, 6 Apr 2006, Piotr Muszynski wrote:
> Spotted on 2.6.15.[1,2] and 2.6.16
>
> How to trigger:
> make menuconfig, change CONFIG_EXPERIMENTAL y --> n, save
> $ cp .config .config_old
> make menuconfig, change nothing, save
> $ diff .config .config_old
> 4c4
> < # Thu Apr 6 20:23:19 2006
> ---
> > # Thu Apr 6 20:22:40 2006
> 157a158,160
> > # CONFIG_FLATMEM_MANUAL is not set
> > # CONFIG_DISCONTIGMEM_MANUAL is not set
> > # CONFIG_SPARSEMEM_MANUAL is not set
>
> I thought the .config shouldn't change... Is this a feature?
No, it's a bug, although not a critical one. I have to look into this.
bye, Roman
^ permalink raw reply
* Re: Huge impact of the conntrack mechanism on routing performance (30% with a single conntrack entry)
From: David S. Miller @ 2006-04-07 21:28 UTC (permalink / raw)
To: eddy_kvetny; +Cc: robert.olsson, netfilter-devel, netfilter
In-Reply-To: <20060405140305.9637.qmail@web33801.mail.mud.yahoo.com>
From: Eddy Kvetny <eddy_kvetny@yahoo.com>
Date: Wed, 5 Apr 2006 07:03:05 -0700 (PDT)
> Right after "insmod ip_conntrack.ko" the throughput
> drastically falls to 28 kpps (-12 kpps or -30% !!!).
Yes, this is pretty much what the cost of netfilter is for a router.
This has been known and well understood for a long time, and solutions
to this problem are not easy which is why there hasn't been any
progress in this area to date.
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-07 21:26 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2008>
======================================================================
Reported By: mborsick
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2008
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Redhat/Fedora
Kernel Version: 2.6.16-1.2080 and with Xen
======================================================================
Date Submitted: 04-07-2006 00:43 CEST
Last Modified: 04-07-2006 23:26 CEST
======================================================================
Summary: No Sound with snd-hda-intel driver Asus P5VDC-MX
Description:
Kernel is up-to-date Xen kernel.
Initial install did not recognize the sound on an ASUS P5VDC-MX
motherboard.
Motherboard has southbridge VIA VT8251. CODEC is Realtek ACL653 AC'97 6
channel
Audio. Tried the updated drivers in 002404, but was unsuccessful. Also
tried
drivers on VIA site and Realltek site. The last couple of tries show no
errors
in compiling, make, etc. However, as I am just above novice in
understanding
everything about Linux, this has thrown me for a loop.
======================================================================
----------------------------------------------------------------------
rlrevell - 04-07-06 23:06
----------------------------------------------------------------------
Weird. So it's not an ALSA bug but a kernel PCI/ACPI issue.
Can you please post your report to linux-kernel and/or the kernel
bugzilla?
----------------------------------------------------------------------
buboleck - 04-07-06 23:26
----------------------------------------------------------------------
Despite this PCI/whatever issue, the fact is that the sound is not working.
Maybe this is all related to the vt8251 chipset.
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 00:43 mborsick New Issue
04-07-06 00:43 mborsick Distribution => Redhat/Fedora
04-07-06 00:43 mborsick Kernel Version => 2.6.16-1.2080 and
with Xen
04-07-06 01:07 rlrevell Note Added: 0009129
04-07-06 02:13 mborsick Note Added: 0009130
04-07-06 02:35 rlrevell Note Added: 0009131
04-07-06 06:38 mborsick Note Added: 0009135
04-07-06 22:45 buboleck Note Added: 0009156
04-07-06 22:47 buboleck Note Edited: 0009156
04-07-06 22:49 buboleck Note Edited: 0009156
04-07-06 23:06 rlrevell Note Added: 0009157
04-07-06 23:16 buboleck Issue Monitored: buboleck
04-07-06 23:26 buboleck Note Added: 0009158
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* RE: [Bluez-users] sniff & pand
From: Pering, Trevor @ 2006-04-07 21:25 UTC (permalink / raw)
To: bluez-users
pand and sniff have nothing to do with each other -- they are handled at
different levels and are so (in my understanding) relatively
independent.=20
Can you do a role switch with the device? That might have some effect.
Numbers are LSB/MSB, so I think you have the order of your connection
handle bytes reversed.
The exact sequence that works for me is:
hcitool cmd 0x02 0x0003 0x06 0x00 0x80 0x00 0x40 0x00 0x02 0x00 0x08
0x00
Trevor
-----Original Message-----
From: bluez-users-admin@lists.sourceforge.net
[mailto:bluez-users-admin@lists.sourceforge.net] On Behalf Of Alexandre
Coser Monteiro
Sent: Friday, April 07, 2006 2:13 PM
To: bluez-users@lists.sourceforge.net
Subject: RE: [Bluez-users] sniff & pand
Thank you Trevor,
You rigth, but still doesn`t work. I`ve ben tried many changes of
values and position
but my dongle do not enter in sniff mode. There is any objection against
sniff mode and
a pand connection work together ?
#hcitool cmd 0x02 0x0003 0x00 0x06 0x8E 0x00 0x25 0x8D 0x04 0x62 0x04
0x62
< HCI Command: ogf 0x02, ocf 0x0003, plen 10
00 06 8E 00 25 8D 04 62 04 62
> HCI Event: 0x0f plen 4
02 01 03 08
#hcitool con
Connections:
> ACL 00:03:C9:23:DE:B2 handle 6 state 1 lm SLAVE
# hcidump
HCIDump - HCI packet analyzer ver 1.11
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Sniff Mode (0x02|0x0003) plen 10
> HCI Event: Command Status (0x0f) plen 4
# hciconfig -a
hci0: Type: USB
BD Address: 00:03:C9:23:DE:9F ACL MTU: 377:10 SCO MTU: 16:0
UP RUNNING PSCAN ISCAN
RX bytes:124087 acl:483 sco:0 events:449 errors:0
TX bytes:134145 acl:507 sco:0 commands:101 errors:0
Features: 0xff 0xfd 0x05 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: SNIFF
Link mode: SLAVE ACCEPT
Name: 'Broadcom BCM2033'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Ver: 1.1 (0x1) HCI Rev: 0x2 LMP Ver: 1.1 (0x1) LMP Subver:
0x1007
Manufacturer: Broadcom Corporation (15)
Sds,
Alexandre
On Fri, 7 Apr 2006 13:46:06 -0700, Pering, Trevor wrote
> how are you parsing your command line? I don' tunderstand how you get
> the sniff attempts (0x0062) and sniff timeout (0x0062) from your
> command. Do you mean 0x0462? I parse your max interval as 0x8E00.
> Double-check the *number* of arguments you have... you have 11, when
you
> should have 10.
>=20
> Trevor
>=20
> -----Original Message-----
> From: bluez-users-admin@lists.sourceforge.net
> [mailto:bluez-users-admin@lists.sourceforge.net] On Behalf Of
Alexandre
> Coser Monteiro
> Sent: Friday, April 07, 2006 12:26 PM
> To: bluez-users@lists.sourceforge.net
> Subject: Re: [Bluez-users] sniff & pand
>=20
> Thank you for your attention Steven.
>=20
> With a detailed eye in my sniff command line, I agree whith you that
I
> introduce wrong
> parameters, but I still doesn`t understand why a pand connection
doesn`t
> accept my sniff
> command line after my correction.
> I`ve been introduced the sniff commando through the linux shell
using
> hcitool
>=20
> [root@helio script]# hcitool cmd 0x02 0x0003 0x00 0x06 0x00 0x8E 0x25
> 0x8D 0x25 0x62
> 0x04 0x62 0X04
> < HCI Command: ogf 0x02, ocf 0x0003, plen 11
> 00 06 00 8E 25 8E 24 62 04 62 04
> > HCI Event: 0x0f plen 4
> 02 01 03 08
>=20
> Sniff Interval =3D 6 seg.
> Sniff Attempt =3D 0.7 seg.
> Connection handle: 0x0006
> Sniff Max Interval: 0x258E
> Sniff Min Interval: 0x258D
> Sniff Attempts: 0x0062
> Sniff Timeout: 0x0062
>=20
> The notation for sniff command line is LSB-MSB ? How can I do sniff
work
> in a pand
> connection ?
> I work with FedoraCore-3, Linux kernel 2.6.9-1.667smp and a usb
> bluetooth dongle BT3030
> from BroadCom
>=20
> Sds,=20
> Alexandre
>=20
> On Fri, 07 Apr 2006 16:02:06 +0100, Steven Singer wrote
> > Alexandre Coser Monteiro wrote:
> > > < HCI Command: ogf 0x02, ocf 0x0003, plen 9
> > > 06 10 00 00 10 FF F7 00 07
> > > > HCI Event: 0x0f plen 4
> > > 12 01 03 08
> >=20
> > The Command Status event shows error code 0x12 =3D Invalid HCI =
Command
> > Parameters.
> >=20
> > This means that the controller didn't like one of the parameters to
> the
> > sniff mode command.
> >=20
> > The sniff mode command you gave had the parameters:
> >=20
> > Connection handle: 0x1006
> > Sniff Max Interval: 0x0000
> > Sniff Min Interval: 0xff10
> > Sniff Attempts: 0x00f7
> > Sniff Timeout: 0x??07
> >=20
> > Notes:
> >=20
> > The connection handle is invalid. The valid range is
0x0000..0x0eff
> >=20
> > The maximum interval is invalid. The valid range is 0x0002..0xfffe
> >=20
> > The minimum interval is invalid. The valid range is 0x0002..max
> > interval.
> >=20
> > The sniff attempts is highly unusual (but not actually invalid).
> >=20
> > The sniff timeout field is truncated, it should be two bytes.
> >=20
> > So, it's not surprising that the controller is rejecting it.
> >=20
> > Where is the sniff mode command being generated? How is it getting
> > through the BlueZ APIs to generate such an invalid event? Are the
> > normal APIs being bypassed and is a raw command being sent.
> >=20
> > - Steven
> > --
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D=
121642
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply
* Re: [RFC/POC] multiple CONFIG y/m/n
From: Roman Zippel @ 2006-04-07 21:24 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Randy.Dunlap, lkml
In-Reply-To: <20060407184400.GA9097@mars.ravnborg.org>
Hi,
On Fri, 7 Apr 2006, Sam Ravnborg wrote:
> > In doing lots of kernel build testing, I often want to enable all options
> > in a sub-menu and their sub-sub-menus. Sound is one of the worst^W longest
> > of these, so I chose a shorter (easier) one to practice on: parport.
> If there is a general need for this we shal enhance kconfig with this.
> We shall not clutter the Kconfig files with this.
I agree.
>From a general perspective I still like to add some basic command line
tool, which can be used for queries or simple manipulations. Here it also
would be less a problem to add experimental or distribution specific
functionality instead of overloading conf.c.
At some point I even had script bindings (via swig), so one could do even
weirder stuff.
bye, Roman
^ permalink raw reply
* Re: [PATCH 16/21] orinoco_pci: disable device and free IRQ when suspending
From: Francois Romieu @ 2006-04-07 21:24 UTC (permalink / raw)
To: Pavel Roskin
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
orinoco-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20060407081051.16107.87289.stgit-fdEtzkpK75rby3iVrkZq2A@public.gmane.org>
Pavel Roskin <proski-mXXj517/zsQ@public.gmane.org> :
[...]
> diff --git a/drivers/net/wireless/orinoco_pci.c b/drivers/net/wireless/orinoco_pci.c
> index 5362c21..e57e92b 100644
> --- a/drivers/net/wireless/orinoco_pci.c
> +++ b/drivers/net/wireless/orinoco_pci.c
> @@ -304,7 +304,9 @@ static int orinoco_pci_suspend(struct pc
>
> orinoco_unlock(priv, &flags);
>
> + free_irq(pdev->irq, dev);
> pci_save_state(pdev);
> + pci_disable_device(pdev);
> pci_set_power_state(pdev, PCI_D3hot);
>
> return 0;
/me stares at the thread behind http://lkml.org/lkml/2005/7/30/143
Imho {free/request}_irq during suspend/resume deserves some
explanation.
--
Ueimor
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [RFC: 2.6 patch] mm/: possible cleanups
From: Adrian Bunk @ 2006-04-07 21:21 UTC (permalink / raw)
To: linux-kernel
This patch contains the following possible cleanups:
- make the following needlessly global functions static:
- filemap.c: do_generic_mapping_read
- slab.c: kmem_find_general_cachep
- swap.c: __page_cache_release
- vmalloc.c: __vmalloc_node
- remove the following unused EXPORT_SYMBOL's:
- rmap.c: remove_from_swap
- bootmem.c: max_pfn
- memory.c: vmtruncate_range
- mmzone.c: first_online_pgdat
- mmzone.c: next_online_pgdat
- mmzone.c: next_zone
- util.c: strndup_user
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
include/linux/fs.h | 15 ---------------
include/linux/mm.h | 2 --
include/linux/slab.h | 2 --
include/linux/vmalloc.h | 2 --
mm/bootmem.c | 4 ----
mm/filemap.c | 32 ++++++++++++++++++++++++--------
mm/memory.c | 1 -
mm/mmzone.c | 4 ----
mm/rmap.c | 1 -
mm/slab.c | 3 +--
mm/swap.c | 39 +++++++++++++++++++--------------------
mm/util.c | 1 -
mm/vmalloc.c | 8 +++++---
13 files changed, 49 insertions(+), 65 deletions(-)
--- linux-2.6.17-rc1-mm1-full/mm/rmap.c.old 2006-04-07 10:51:42.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/mm/rmap.c 2006-04-07 10:52:55.000000000 +0200
@@ -240,7 +240,6 @@
spin_unlock(&anon_vma->lock);
delete_from_swap_cache(page);
}
-EXPORT_SYMBOL(remove_from_swap);
#endif
/*
--- linux-2.6.17-rc1-mm1-full/mm/bootmem.c.old 2006-04-07 10:55:20.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/mm/bootmem.c 2006-04-07 10:56:37.000000000 +0200
@@ -29,10 +29,6 @@
unsigned long min_low_pfn;
unsigned long max_pfn;
-EXPORT_SYMBOL(max_pfn); /* This is exported so
- * dma_get_required_mask(), which uses
- * it, can be an inline function */
-
static LIST_HEAD(bdata_list);
#ifdef CONFIG_CRASH_DUMP
/*
--- linux-2.6.17-rc1-mm1-full/include/linux/fs.h.old 2006-04-07 10:59:31.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/include/linux/fs.h 2006-04-07 13:55:48.000000000 +0200
@@ -1609,9 +1609,6 @@
ssize_t generic_file_write_nolock(struct file *file, const struct iovec *iov,
unsigned long nr_segs, loff_t *ppos);
extern ssize_t generic_file_sendfile(struct file *, loff_t *, size_t, read_actor_t, void *);
-extern void do_generic_mapping_read(struct address_space *mapping,
- struct file_ra_state *, struct file *,
- loff_t *, read_descriptor_t *, read_actor_t);
extern ssize_t generic_file_splice_read(struct file *, struct inode *, size_t, unsigned int);
extern ssize_t generic_file_splice_write(struct inode *, struct file *, size_t, unsigned int);
extern void
@@ -1643,18 +1640,6 @@
}
#endif
-static inline void do_generic_file_read(struct file * filp, loff_t *ppos,
- read_descriptor_t * desc,
- read_actor_t actor)
-{
- do_generic_mapping_read(filp->f_mapping,
- &filp->f_ra,
- filp,
- ppos,
- desc,
- actor);
-}
-
ssize_t __blockdev_direct_IO(int rw, struct kiocb *iocb, struct inode *inode,
struct block_device *bdev, const struct iovec *iov, loff_t offset,
unsigned long nr_segs, get_block_t get_block, dio_iodone_t end_io,
--- linux-2.6.17-rc1-mm1-full/mm/filemap.c.old 2006-04-07 10:59:48.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/mm/filemap.c 2006-04-07 16:48:16.000000000 +0200
@@ -44,6 +44,24 @@
static ssize_t
generic_file_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,
loff_t offset, unsigned long nr_segs);
+static void do_generic_mapping_read(struct address_space *mapping,
+ struct file_ra_state *_ra,
+ struct file *filp,
+ loff_t *ppos,
+ read_descriptor_t *desc,
+ read_actor_t actor);
+
+static inline void do_generic_file_read(struct file * filp, loff_t *ppos,
+ read_descriptor_t * desc,
+ read_actor_t actor)
+{
+ do_generic_mapping_read(filp->f_mapping,
+ &filp->f_ra,
+ filp,
+ ppos,
+ desc,
+ actor);
+}
/*
* Shared mappings implemented 30.11.1994. It's not fully working yet,
@@ -766,12 +784,12 @@
* Note the struct file* is only passed for the use of readpage. It may be
* NULL.
*/
-void do_generic_mapping_read(struct address_space *mapping,
- struct file_ra_state *_ra,
- struct file *filp,
- loff_t *ppos,
- read_descriptor_t *desc,
- read_actor_t actor)
+static void do_generic_mapping_read(struct address_space *mapping,
+ struct file_ra_state *_ra,
+ struct file *filp,
+ loff_t *ppos,
+ read_descriptor_t *desc,
+ read_actor_t actor)
{
struct inode *inode = mapping->host;
unsigned long index;
@@ -978,8 +996,6 @@
file_accessed(filp);
}
-EXPORT_SYMBOL(do_generic_mapping_read);
-
int file_read_actor(read_descriptor_t *desc, struct page *page,
unsigned long offset, unsigned long size)
{
--- linux-2.6.17-rc1-mm1-full/mm/memory.c.old 2006-04-07 13:57:09.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/mm/memory.c 2006-04-07 13:58:19.000000000 +0200
@@ -1802,7 +1802,6 @@
return 0;
}
-EXPORT_SYMBOL(vmtruncate_range);
/*
* Primitive swap readahead code. We simply read an aligned block of
--- linux-2.6.17-rc1-mm1-full/mm/mmzone.c.old 2006-04-07 14:06:37.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/mm/mmzone.c 2006-04-07 14:09:48.000000000 +0200
@@ -15,8 +15,6 @@
return NODE_DATA(first_online_node);
}
-EXPORT_SYMBOL(first_online_pgdat);
-
struct pglist_data *next_online_pgdat(struct pglist_data *pgdat)
{
int nid = next_online_node(pgdat->node_id);
@@ -25,7 +23,6 @@
return NULL;
return NODE_DATA(nid);
}
-EXPORT_SYMBOL(next_online_pgdat);
/*
@@ -46,5 +43,4 @@
}
return zone;
}
-EXPORT_SYMBOL(next_zone);
--- linux-2.6.17-rc1-mm1-full/include/linux/slab.h.old 2006-04-07 14:11:18.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/include/linux/slab.h 2006-04-07 14:11:35.000000000 +0200
@@ -68,7 +68,6 @@
extern void kmem_cache_free(kmem_cache_t *, void *);
extern unsigned int kmem_cache_size(kmem_cache_t *);
extern const char *kmem_cache_name(kmem_cache_t *);
-extern kmem_cache_t *kmem_find_general_cachep(size_t size, gfp_t gfpflags);
/* Size description struct for general caches. */
struct cache_sizes {
@@ -176,7 +175,6 @@
/* SLOB allocator routines */
void kmem_cache_init(void);
-struct kmem_cache *kmem_find_general_cachep(size_t, gfp_t gfpflags);
struct kmem_cache *kmem_cache_create(const char *c, size_t, size_t,
unsigned long,
void (*)(void *, struct kmem_cache *, unsigned long),
--- linux-2.6.17-rc1-mm1-full/mm/slab.c.old 2006-04-07 14:11:43.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/mm/slab.c 2006-04-07 14:11:52.000000000 +0200
@@ -742,11 +742,10 @@
return csizep->cs_cachep;
}
-struct kmem_cache *kmem_find_general_cachep(size_t size, gfp_t gfpflags)
+static struct kmem_cache *kmem_find_general_cachep(size_t size, gfp_t gfpflags)
{
return __find_general_cachep(size, gfpflags);
}
-EXPORT_SYMBOL(kmem_find_general_cachep);
static size_t slab_mgmt_size(size_t nr_objs, size_t align)
{
--- linux-2.6.17-rc1-mm1-full/include/linux/mm.h.old 2006-04-07 14:14:12.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/include/linux/mm.h 2006-04-07 14:14:17.000000000 +0200
@@ -320,8 +320,6 @@
return atomic_inc_not_zero(&page->_count);
}
-extern void FASTCALL(__page_cache_release(struct page *));
-
static inline int page_count(struct page *page)
{
if (unlikely(PageCompound(page)))
--- linux-2.6.17-rc1-mm1-full/mm/swap.c.old 2006-04-07 14:14:27.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/mm/swap.c 2006-04-07 14:15:29.000000000 +0200
@@ -35,6 +35,25 @@
/* How many pages do we try to swap or page in/out together? */
int page_cluster;
+/*
+ * This path almost never happens for VM activity - pages are normally
+ * freed via pagevecs. But it gets used by networking.
+ */
+static void fastcall __page_cache_release(struct page *page)
+{
+ if (PageLRU(page)) {
+ unsigned long flags;
+ struct zone *zone = page_zone(page);
+
+ spin_lock_irqsave(&zone->lru_lock, flags);
+ VM_BUG_ON(!PageLRU(page));
+ __ClearPageLRU(page);
+ del_page_from_lru(zone, page);
+ spin_unlock_irqrestore(&zone->lru_lock, flags);
+ }
+ free_hot_page(page);
+}
+
static void put_compound_page(struct page *page)
{
page = (struct page *)page_private(page);
@@ -204,26 +223,6 @@
#endif
/*
- * This path almost never happens for VM activity - pages are normally
- * freed via pagevecs. But it gets used by networking.
- */
-void fastcall __page_cache_release(struct page *page)
-{
- if (PageLRU(page)) {
- unsigned long flags;
- struct zone *zone = page_zone(page);
-
- spin_lock_irqsave(&zone->lru_lock, flags);
- VM_BUG_ON(!PageLRU(page));
- __ClearPageLRU(page);
- del_page_from_lru(zone, page);
- spin_unlock_irqrestore(&zone->lru_lock, flags);
- }
- free_hot_page(page);
-}
-EXPORT_SYMBOL(__page_cache_release);
-
-/*
* Batched page_cache_release(). Decrement the reference count on all the
* passed pages. If it fell to zero then remove the page from the LRU and
* free it.
--- linux-2.6.17-rc1-mm1-full/mm/util.c.old 2006-04-07 14:16:14.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/mm/util.c 2006-04-07 14:16:22.000000000 +0200
@@ -73,4 +73,3 @@
return p;
}
-EXPORT_SYMBOL(strndup_user);
--- linux-2.6.17-rc1-mm1-full/include/linux/vmalloc.h.old 2006-04-07 14:16:49.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/include/linux/vmalloc.h 2006-04-07 14:17:29.000000000 +0200
@@ -38,8 +38,6 @@
extern void *__vmalloc(unsigned long size, gfp_t gfp_mask, pgprot_t prot);
extern void *__vmalloc_area(struct vm_struct *area, gfp_t gfp_mask,
pgprot_t prot);
-extern void *__vmalloc_node(unsigned long size, gfp_t gfp_mask,
- pgprot_t prot, int node);
extern void vfree(void *addr);
extern void *vmap(struct page **pages, unsigned int count,
--- linux-2.6.17-rc1-mm1-full/mm/vmalloc.c.old 2006-04-07 14:17:43.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/mm/vmalloc.c 2006-04-07 14:18:26.000000000 +0200
@@ -24,6 +24,9 @@
DEFINE_RWLOCK(vmlist_lock);
struct vm_struct *vmlist;
+static void *__vmalloc_node(unsigned long size, gfp_t gfp_mask, pgprot_t prot,
+ int node);
+
static void vunmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end)
{
pte_t *pte;
@@ -462,8 +465,8 @@
* allocator with @gfp_mask flags. Map them into contiguous
* kernel virtual space, using a pagetable protection of @prot.
*/
-void *__vmalloc_node(unsigned long size, gfp_t gfp_mask, pgprot_t prot,
- int node)
+static void *__vmalloc_node(unsigned long size, gfp_t gfp_mask, pgprot_t prot,
+ int node)
{
struct vm_struct *area;
@@ -477,7 +480,6 @@
return __vmalloc_area_node(area, gfp_mask, prot, node);
}
-EXPORT_SYMBOL(__vmalloc_node);
void *__vmalloc(unsigned long size, gfp_t gfp_mask, pgprot_t prot)
{
^ permalink raw reply
* [PATCH] powerpc/pseries: clear PCI failure counter if no new failures.
From: Linas Vepstas @ 2006-04-07 21:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-pci, linux-kernel
[PATCH] powerpc/pseries: clear PCI failure counter if no new failures.
The current PCI error recovery system keeps track of the number of
PCI card resets, and refuses to bring a card back up if this number
is too large. The goal of doing this was to avoid an infinite loop
of resets if a card is obviously dead. However, if the failures are
rare, but the machine has a high uptime, this mechanism might still
be triggered; this is too harsh.
This patch will avoids this problem by decrementing the fail count
after an hour. Thus, as long as a pci card BSOD's less than 6 times
an hour, it will continue to be reset indefinitely. If it's failure
rate is greater than that, it will be taken off-line permanently.
This patch is larger than it might otherwise be because it
changes indentation by removing a pointless while-loop. The while
loop is not needed, as the handler is invoked once fo each event
(by schedule_work()); the loop is leftover cruft from an earlier
implementation.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh_driver.c | 13 +++---
arch/powerpc/platforms/pseries/eeh_event.c | 60 +++++++++++++++-------------
include/asm-powerpc/eeh_event.h | 10 ++--
3 files changed, 45 insertions(+), 38 deletions(-)
Index: linux-2.6.17-rc1/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- linux-2.6.17-rc1.orig/arch/powerpc/platforms/pseries/eeh_driver.c 2006-04-04 15:28:59.000000000 -0500
+++ linux-2.6.17-rc1/arch/powerpc/platforms/pseries/eeh_driver.c 2006-04-07 16:08:27.000000000 -0500
@@ -23,9 +23,8 @@
*
*/
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/interrupt.h>
-#include <linux/notifier.h>
+#include <linux/irq.h>
#include <linux/pci.h>
#include <asm/eeh.h>
#include <asm/eeh_event.h>
@@ -250,7 +249,7 @@ static int eeh_reset_device (struct pci_
*/
#define MAX_WAIT_FOR_RECOVERY 15
-void handle_eeh_events (struct eeh_event *event)
+struct pci_dn * handle_eeh_events (struct eeh_event *event)
{
struct device_node *frozen_dn;
struct pci_dn *frozen_pdn;
@@ -265,7 +264,7 @@ void handle_eeh_events (struct eeh_event
if (!frozen_dn) {
printk(KERN_ERR "EEH: Error: Cannot find partition endpoint for %s\n",
pci_name(event->dev));
- return;
+ return NULL;
}
/* There are two different styles for coming up with the PE.
@@ -280,7 +279,7 @@ void handle_eeh_events (struct eeh_event
if (!frozen_bus) {
printk(KERN_ERR "EEH: Cannot find PCI bus for %s\n",
frozen_dn->full_name);
- return;
+ return NULL;
}
#if 0
@@ -355,7 +354,7 @@ void handle_eeh_events (struct eeh_event
/* Tell all device drivers that they can resume operations */
pci_walk_bus(frozen_bus, eeh_report_resume, NULL);
- return;
+ return frozen_pdn;
excess_failures:
/*
@@ -384,6 +383,8 @@ perm_error:
/* Shut down the device drivers for good. */
pcibios_remove_pci_devices(frozen_bus);
+
+ return NULL;
}
/* ---------- end of file ---------- */
Index: linux-2.6.17-rc1/arch/powerpc/platforms/pseries/eeh_event.c
===================================================================
--- linux-2.6.17-rc1.orig/arch/powerpc/platforms/pseries/eeh_event.c 2006-04-04 15:28:59.000000000 -0500
+++ linux-2.6.17-rc1/arch/powerpc/platforms/pseries/eeh_event.c 2006-04-05 09:56:38.000000000 -0500
@@ -18,6 +18,7 @@
* Copyright (c) 2005 Linas Vepstas <linas@linas.org>
*/
+#include <linux/delay.h>
#include <linux/list.h>
#include <linux/mutex.h>
#include <linux/pci.h>
@@ -56,38 +57,43 @@ static int eeh_event_handler(void * dumm
{
unsigned long flags;
struct eeh_event *event;
+ struct pci_dn *pdn;
daemonize ("eehd");
+ set_current_state(TASK_INTERRUPTIBLE);
- while (1) {
- set_current_state(TASK_INTERRUPTIBLE);
+ spin_lock_irqsave(&eeh_eventlist_lock, flags);
+ event = NULL;
+
+ /* Unqueue the event, get ready to process. */
+ if (!list_empty(&eeh_eventlist)) {
+ event = list_entry(eeh_eventlist.next, struct eeh_event, list);
+ list_del(&event->list);
+ }
+ spin_unlock_irqrestore(&eeh_eventlist_lock, flags);
- spin_lock_irqsave(&eeh_eventlist_lock, flags);
- event = NULL;
+ if (event == NULL)
+ return 0;
- /* Unqueue the event, get ready to process. */
- if (!list_empty(&eeh_eventlist)) {
- event = list_entry(eeh_eventlist.next, struct eeh_event, list);
- list_del(&event->list);
- }
- spin_unlock_irqrestore(&eeh_eventlist_lock, flags);
-
- if (event == NULL)
- break;
-
- /* Serialize processing of EEH events */
- mutex_lock(&eeh_event_mutex);
- eeh_mark_slot(event->dn, EEH_MODE_RECOVERING);
-
- printk(KERN_INFO "EEH: Detected PCI bus error on device %s\n",
- pci_name(event->dev));
-
- handle_eeh_events(event);
-
- eeh_clear_slot(event->dn, EEH_MODE_RECOVERING);
- pci_dev_put(event->dev);
- kfree(event);
- mutex_unlock(&eeh_event_mutex);
+ /* Serialize processing of EEH events */
+ mutex_lock(&eeh_event_mutex);
+ eeh_mark_slot(event->dn, EEH_MODE_RECOVERING);
+
+ printk(KERN_INFO "EEH: Detected PCI bus error on device %s\n",
+ pci_name(event->dev));
+
+ pdn = handle_eeh_events(event);
+
+ eeh_clear_slot(event->dn, EEH_MODE_RECOVERING);
+ pci_dev_put(event->dev);
+ kfree(event);
+ mutex_unlock(&eeh_event_mutex);
+
+ /* If there are no new errors after an hour, clear the counter. */
+ if (pdn && pdn->eeh_freeze_count>0) {
+ msleep_interruptible (3600*1000);
+ if (pdn->eeh_freeze_count>0)
+ pdn->eeh_freeze_count--;
}
return 0;
Index: linux-2.6.17-rc1/include/asm-powerpc/eeh_event.h
===================================================================
--- linux-2.6.17-rc1.orig/include/asm-powerpc/eeh_event.h 2006-03-19 23:53:29.000000000 -0600
+++ linux-2.6.17-rc1/include/asm-powerpc/eeh_event.h 2006-04-04 15:37:22.000000000 -0500
@@ -18,8 +18,8 @@
* Copyright (c) 2005 Linas Vepstas <linas@linas.org>
*/
-#ifndef ASM_PPC64_EEH_EVENT_H
-#define ASM_PPC64_EEH_EVENT_H
+#ifndef ASM_POWERPC_EEH_EVENT_H
+#define ASM_POWERPC_EEH_EVENT_H
#ifdef __KERNEL__
/** EEH event -- structure holding pci controller data that describes
@@ -39,7 +39,7 @@ struct eeh_event {
* @dev pci device
*
* This routine builds a PCI error event which will be delivered
- * to all listeners on the peh_notifier_chain.
+ * to all listeners on the eeh_notifier_chain.
*
* This routine can be called within an interrupt context;
* the actual event will be delivered in a normal context
@@ -51,7 +51,7 @@ int eeh_send_failure_event (struct devic
int time_unavail);
/* Main recovery function */
-void handle_eeh_events (struct eeh_event *);
+struct pci_dn * handle_eeh_events (struct eeh_event *);
#endif /* __KERNEL__ */
-#endif /* ASM_PPC64_EEH_EVENT_H */
+#endif /* ASM_POWERPC_EEH_EVENT_H */
^ permalink raw reply
* [PATCH] powerpc/pseries: clear PCI failure counter if no new failures.
From: Linas Vepstas @ 2006-04-07 21:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-kernel, linux-pci, linuxppc-dev
[PATCH] powerpc/pseries: clear PCI failure counter if no new failures.
The current PCI error recovery system keeps track of the number of
PCI card resets, and refuses to bring a card back up if this number
is too large. The goal of doing this was to avoid an infinite loop
of resets if a card is obviously dead. However, if the failures are
rare, but the machine has a high uptime, this mechanism might still
be triggered; this is too harsh.
This patch will avoids this problem by decrementing the fail count
after an hour. Thus, as long as a pci card BSOD's less than 6 times
an hour, it will continue to be reset indefinitely. If it's failure
rate is greater than that, it will be taken off-line permanently.
This patch is larger than it might otherwise be because it
changes indentation by removing a pointless while-loop. The while
loop is not needed, as the handler is invoked once fo each event
(by schedule_work()); the loop is leftover cruft from an earlier
implementation.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh_driver.c | 13 +++---
arch/powerpc/platforms/pseries/eeh_event.c | 60 +++++++++++++++-------------
include/asm-powerpc/eeh_event.h | 10 ++--
3 files changed, 45 insertions(+), 38 deletions(-)
Index: linux-2.6.17-rc1/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- linux-2.6.17-rc1.orig/arch/powerpc/platforms/pseries/eeh_driver.c 2006-04-04 15:28:59.000000000 -0500
+++ linux-2.6.17-rc1/arch/powerpc/platforms/pseries/eeh_driver.c 2006-04-07 16:08:27.000000000 -0500
@@ -23,9 +23,8 @@
*
*/
#include <linux/delay.h>
-#include <linux/irq.h>
#include <linux/interrupt.h>
-#include <linux/notifier.h>
+#include <linux/irq.h>
#include <linux/pci.h>
#include <asm/eeh.h>
#include <asm/eeh_event.h>
@@ -250,7 +249,7 @@ static int eeh_reset_device (struct pci_
*/
#define MAX_WAIT_FOR_RECOVERY 15
-void handle_eeh_events (struct eeh_event *event)
+struct pci_dn * handle_eeh_events (struct eeh_event *event)
{
struct device_node *frozen_dn;
struct pci_dn *frozen_pdn;
@@ -265,7 +264,7 @@ void handle_eeh_events (struct eeh_event
if (!frozen_dn) {
printk(KERN_ERR "EEH: Error: Cannot find partition endpoint for %s\n",
pci_name(event->dev));
- return;
+ return NULL;
}
/* There are two different styles for coming up with the PE.
@@ -280,7 +279,7 @@ void handle_eeh_events (struct eeh_event
if (!frozen_bus) {
printk(KERN_ERR "EEH: Cannot find PCI bus for %s\n",
frozen_dn->full_name);
- return;
+ return NULL;
}
#if 0
@@ -355,7 +354,7 @@ void handle_eeh_events (struct eeh_event
/* Tell all device drivers that they can resume operations */
pci_walk_bus(frozen_bus, eeh_report_resume, NULL);
- return;
+ return frozen_pdn;
excess_failures:
/*
@@ -384,6 +383,8 @@ perm_error:
/* Shut down the device drivers for good. */
pcibios_remove_pci_devices(frozen_bus);
+
+ return NULL;
}
/* ---------- end of file ---------- */
Index: linux-2.6.17-rc1/arch/powerpc/platforms/pseries/eeh_event.c
===================================================================
--- linux-2.6.17-rc1.orig/arch/powerpc/platforms/pseries/eeh_event.c 2006-04-04 15:28:59.000000000 -0500
+++ linux-2.6.17-rc1/arch/powerpc/platforms/pseries/eeh_event.c 2006-04-05 09:56:38.000000000 -0500
@@ -18,6 +18,7 @@
* Copyright (c) 2005 Linas Vepstas <linas@linas.org>
*/
+#include <linux/delay.h>
#include <linux/list.h>
#include <linux/mutex.h>
#include <linux/pci.h>
@@ -56,38 +57,43 @@ static int eeh_event_handler(void * dumm
{
unsigned long flags;
struct eeh_event *event;
+ struct pci_dn *pdn;
daemonize ("eehd");
+ set_current_state(TASK_INTERRUPTIBLE);
- while (1) {
- set_current_state(TASK_INTERRUPTIBLE);
+ spin_lock_irqsave(&eeh_eventlist_lock, flags);
+ event = NULL;
+
+ /* Unqueue the event, get ready to process. */
+ if (!list_empty(&eeh_eventlist)) {
+ event = list_entry(eeh_eventlist.next, struct eeh_event, list);
+ list_del(&event->list);
+ }
+ spin_unlock_irqrestore(&eeh_eventlist_lock, flags);
- spin_lock_irqsave(&eeh_eventlist_lock, flags);
- event = NULL;
+ if (event == NULL)
+ return 0;
- /* Unqueue the event, get ready to process. */
- if (!list_empty(&eeh_eventlist)) {
- event = list_entry(eeh_eventlist.next, struct eeh_event, list);
- list_del(&event->list);
- }
- spin_unlock_irqrestore(&eeh_eventlist_lock, flags);
-
- if (event == NULL)
- break;
-
- /* Serialize processing of EEH events */
- mutex_lock(&eeh_event_mutex);
- eeh_mark_slot(event->dn, EEH_MODE_RECOVERING);
-
- printk(KERN_INFO "EEH: Detected PCI bus error on device %s\n",
- pci_name(event->dev));
-
- handle_eeh_events(event);
-
- eeh_clear_slot(event->dn, EEH_MODE_RECOVERING);
- pci_dev_put(event->dev);
- kfree(event);
- mutex_unlock(&eeh_event_mutex);
+ /* Serialize processing of EEH events */
+ mutex_lock(&eeh_event_mutex);
+ eeh_mark_slot(event->dn, EEH_MODE_RECOVERING);
+
+ printk(KERN_INFO "EEH: Detected PCI bus error on device %s\n",
+ pci_name(event->dev));
+
+ pdn = handle_eeh_events(event);
+
+ eeh_clear_slot(event->dn, EEH_MODE_RECOVERING);
+ pci_dev_put(event->dev);
+ kfree(event);
+ mutex_unlock(&eeh_event_mutex);
+
+ /* If there are no new errors after an hour, clear the counter. */
+ if (pdn && pdn->eeh_freeze_count>0) {
+ msleep_interruptible (3600*1000);
+ if (pdn->eeh_freeze_count>0)
+ pdn->eeh_freeze_count--;
}
return 0;
Index: linux-2.6.17-rc1/include/asm-powerpc/eeh_event.h
===================================================================
--- linux-2.6.17-rc1.orig/include/asm-powerpc/eeh_event.h 2006-03-19 23:53:29.000000000 -0600
+++ linux-2.6.17-rc1/include/asm-powerpc/eeh_event.h 2006-04-04 15:37:22.000000000 -0500
@@ -18,8 +18,8 @@
* Copyright (c) 2005 Linas Vepstas <linas@linas.org>
*/
-#ifndef ASM_PPC64_EEH_EVENT_H
-#define ASM_PPC64_EEH_EVENT_H
+#ifndef ASM_POWERPC_EEH_EVENT_H
+#define ASM_POWERPC_EEH_EVENT_H
#ifdef __KERNEL__
/** EEH event -- structure holding pci controller data that describes
@@ -39,7 +39,7 @@ struct eeh_event {
* @dev pci device
*
* This routine builds a PCI error event which will be delivered
- * to all listeners on the peh_notifier_chain.
+ * to all listeners on the eeh_notifier_chain.
*
* This routine can be called within an interrupt context;
* the actual event will be delivered in a normal context
@@ -51,7 +51,7 @@ int eeh_send_failure_event (struct devic
int time_unavail);
/* Main recovery function */
-void handle_eeh_events (struct eeh_event *);
+struct pci_dn * handle_eeh_events (struct eeh_event *);
#endif /* __KERNEL__ */
-#endif /* ASM_PPC64_EEH_EVENT_H */
+#endif /* ASM_POWERPC_EEH_EVENT_H */
^ permalink raw reply
* [2.6 patch] drivers/isdn/capi/capiutil.c: unexport capi_message2str
From: Adrian Bunk @ 2006-04-07 21:17 UTC (permalink / raw)
To: kkeil; +Cc: isdn4linux, linux-kernel
This patch removes an unused EXPORT_SYMBOL.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-rc1-mm1-full/drivers/isdn/capi/capiutil.c.old 2006-04-07 10:47:30.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/isdn/capi/capiutil.c 2006-04-07 10:47:37.000000000 +0200
@@ -855,5 +855,4 @@
EXPORT_SYMBOL(capi_cmsg_header);
EXPORT_SYMBOL(capi_cmd2str);
EXPORT_SYMBOL(capi_cmsg2str);
-EXPORT_SYMBOL(capi_message2str);
EXPORT_SYMBOL(capi_info2str);
^ permalink raw reply
* audit 1.2 released
From: Steve Grubb @ 2006-04-07 21:17 UTC (permalink / raw)
To: Linux Audit
Hi,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit It will also be in rawhide
tomorrow. The Changelog is:
- Add support for new file system auditing kernel subsystem
This release adds initial support for the new file system auditing capability
found in the lspp kernel. The -w/W switches still work for auditctl to
maintain some backward compatibility. The -k and -p switches are deprecated
since there isn't quite the same capability in the new system. The lspp.16
kernel can be found at http://people.redhat.com/sgrubb/files/lspp.
Please let me know if there are any problems with this release.
-Steve
^ permalink raw reply
* [2.6 patch] mm/migrate.c: don't export a static function
From: Adrian Bunk @ 2006-04-07 21:16 UTC (permalink / raw)
To: linux-kernel
EXPORT_SYMBOL'ing of a static function is not a good idea.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-rc1-mm1-full/mm/migrate.c.old 2006-04-07 14:03:21.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/mm/migrate.c 2006-04-07 14:03:31.000000000 +0200
@@ -176,7 +176,6 @@
retry:
return -EAGAIN;
}
-EXPORT_SYMBOL(swap_page);
/*
* Remove references for a page and establish the new page with the correct
^ permalink raw reply
* RE: [Bluez-users] sniff & pand
From: Alexandre Coser Monteiro @ 2006-04-07 21:12 UTC (permalink / raw)
To: bluez-users
In-Reply-To: <8350AFF45303EE44BE0AF1AB40CA43584A9097@scsmsx404.amr.corp.intel.com>
Thank you Trevor,
You rigth, but still doesn`t work. I`ve ben tried many changes of values and position
but my dongle do not enter in sniff mode. There is any objection against sniff mode and
a pand connection work together ?
#hcitool cmd 0x02 0x0003 0x00 0x06 0x8E 0x00 0x25 0x8D 0x04 0x62 0x04 0x62
< HCI Command: ogf 0x02, ocf 0x0003, plen 10
00 06 8E 00 25 8D 04 62 04 62
> HCI Event: 0x0f plen 4
02 01 03 08
#hcitool con
Connections:
> ACL 00:03:C9:23:DE:B2 handle 6 state 1 lm SLAVE
# hcidump
HCIDump - HCI packet analyzer ver 1.11
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Sniff Mode (0x02|0x0003) plen 10
> HCI Event: Command Status (0x0f) plen 4
# hciconfig -a
hci0: Type: USB
BD Address: 00:03:C9:23:DE:9F ACL MTU: 377:10 SCO MTU: 16:0
UP RUNNING PSCAN ISCAN
RX bytes:124087 acl:483 sco:0 events:449 errors:0
TX bytes:134145 acl:507 sco:0 commands:101 errors:0
Features: 0xff 0xfd 0x05 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: SNIFF
Link mode: SLAVE ACCEPT
Name: 'Broadcom BCM2033'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Ver: 1.1 (0x1) HCI Rev: 0x2 LMP Ver: 1.1 (0x1) LMP Subver: 0x1007
Manufacturer: Broadcom Corporation (15)
Sds,
Alexandre
On Fri, 7 Apr 2006 13:46:06 -0700, Pering, Trevor wrote
> how are you parsing your command line? I don' tunderstand how you get
> the sniff attempts (0x0062) and sniff timeout (0x0062) from your
> command. Do you mean 0x0462? I parse your max interval as 0x8E00.
> Double-check the *number* of arguments you have... you have 11, when you
> should have 10.
>
> Trevor
>
> -----Original Message-----
> From: bluez-users-admin@lists.sourceforge.net
> [mailto:bluez-users-admin@lists.sourceforge.net] On Behalf Of Alexandre
> Coser Monteiro
> Sent: Friday, April 07, 2006 12:26 PM
> To: bluez-users@lists.sourceforge.net
> Subject: Re: [Bluez-users] sniff & pand
>
> Thank you for your attention Steven.
>
> With a detailed eye in my sniff command line, I agree whith you that I
> introduce wrong
> parameters, but I still doesn`t understand why a pand connection doesn`t
> accept my sniff
> command line after my correction.
> I`ve been introduced the sniff commando through the linux shell using
> hcitool
>
> [root@helio script]# hcitool cmd 0x02 0x0003 0x00 0x06 0x00 0x8E 0x25
> 0x8D 0x25 0x62
> 0x04 0x62 0X04
> < HCI Command: ogf 0x02, ocf 0x0003, plen 11
> 00 06 00 8E 25 8E 24 62 04 62 04
> > HCI Event: 0x0f plen 4
> 02 01 03 08
>
> Sniff Interval = 6 seg.
> Sniff Attempt = 0.7 seg.
> Connection handle: 0x0006
> Sniff Max Interval: 0x258E
> Sniff Min Interval: 0x258D
> Sniff Attempts: 0x0062
> Sniff Timeout: 0x0062
>
> The notation for sniff command line is LSB-MSB ? How can I do sniff work
> in a pand
> connection ?
> I work with FedoraCore-3, Linux kernel 2.6.9-1.667smp and a usb
> bluetooth dongle BT3030
> from BroadCom
>
> Sds,
> Alexandre
>
> On Fri, 07 Apr 2006 16:02:06 +0100, Steven Singer wrote
> > Alexandre Coser Monteiro wrote:
> > > < HCI Command: ogf 0x02, ocf 0x0003, plen 9
> > > 06 10 00 00 10 FF F7 00 07
> > > > HCI Event: 0x0f plen 4
> > > 12 01 03 08
> >
> > The Command Status event shows error code 0x12 = Invalid HCI Command
> > Parameters.
> >
> > This means that the controller didn't like one of the parameters to
> the
> > sniff mode command.
> >
> > The sniff mode command you gave had the parameters:
> >
> > Connection handle: 0x1006
> > Sniff Max Interval: 0x0000
> > Sniff Min Interval: 0xff10
> > Sniff Attempts: 0x00f7
> > Sniff Timeout: 0x??07
> >
> > Notes:
> >
> > The connection handle is invalid. The valid range is 0x0000..0x0eff
> >
> > The maximum interval is invalid. The valid range is 0x0002..0xfffe
> >
> > The minimum interval is invalid. The valid range is 0x0002..max
> > interval.
> >
> > The sniff attempts is highly unusual (but not actually invalid).
> >
> > The sniff timeout field is truncated, it should be two bytes.
> >
> > So, it's not surprising that the controller is rejecting it.
> >
> > Where is the sniff mode command being generated? How is it getting
> > through the BlueZ APIs to generate such an invalid event? Are the
> > normal APIs being bypassed and is a raw command being sent.
> >
> > - Steven
> > --
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply
* Re: [PATCH] Fix swap entry for MIPS32 36-bit physical address
From: Sergei Shtylyov @ 2006-04-07 21:20 UTC (permalink / raw)
To: linux-mips; +Cc: Bob Breuer, Jordan Crouse, Konstantin Baidarov
In-Reply-To: <4436C301.2060001@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 568 bytes --]
Hello.
With 64-bit physical address enabled, 'swapon' was causing kernel oops
on Alchemy CPUs (MIPS32) because of the swap entry type field corrupting the
_PAGE_FILE bit in pte_low. So, change layout of the swap entry to use all bits
except _PAGE_PRESENT and _PAGE_FILE (the harware protection bits are loaded
from pte_high which should be cleared by __swp_entry_to_pte() macro) -- which
gives 25 bits for the swap entry offset.
WBR, Sergei
Signed-off-by: Konstantin Baydarov <kbaidarov@ru.mvista.com>
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
[-- Attachment #2: MIPS32-36bit-phys-addr-swap-entry-fix.patch --]
[-- Type: text/plain, Size: 1202 bytes --]
diff --git a/include/asm-mips/pgtable-32.h b/include/asm-mips/pgtable-32.h
index 4d6bc45..b0ad112 100644
--- a/include/asm-mips/pgtable-32.h
+++ b/include/asm-mips/pgtable-32.h
@@ -190,11 +190,27 @@ pfn_pte(unsigned long pfn, pgprot_t prot
#else
+#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32)
+/*
+ * For 36-bit physical address we store swap entry in pte_low and 0 in pte_high,
+ * which gives us 25 bits available for the offset...
+ */
+#define __swp_type(x) ((x).val & 0x1f)
+#define __swp_offset(x) ((((x).val >> 5) & 0x1) | \
+ (((x).val >> 6) & 0xe) | \
+ (((x).val >> 11) << 4))
+#define __swp_entry(type,offset) \
+ ((swp_entry_t) { ((type) & 0x1f) | \
+ (((offset) & 0x1) << 5) | \
+ (((offset) & 0xe) << 6) | \
+ (((offset) >> 4 ) << 11) })
+#else
/* Swap entries must have VALID and GLOBAL bits cleared. */
#define __swp_type(x) (((x).val >> 8) & 0x1f)
#define __swp_offset(x) ((x).val >> 13)
#define __swp_entry(type,offset) \
((swp_entry_t) { ((type) << 8) | ((offset) << 13) })
+#endif /* defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32) */
/*
* Bits 0, 1, 2, 7 and 8 are taken, split up the 27 bits of offset
^ permalink raw reply related
* Re: [LARTC] u32 and iptables do not work together
From: Jody Shumaker @ 2006-04-07 21:10 UTC (permalink / raw)
To: lartc
In-Reply-To: <4436AEB8.1070300@cnett.com.br>
On 4/7/06, Nataniel Klug <nata@cnett.com.br> wrote:
> Andreas,
>
> This is not the problem becouse if I disable the rules I am using, and
> use other script just with rules using fwmark them the other script
> works fine.
>
> Att,
>
> Nataniel Klug
>
> Andreas Klauer escreveu:
> > On Fri, Apr 07, 2006 at 03:26:00PM -0300, Nataniel Klug wrote:
> >
> >> RTNETLINK answers: Invalid argument
> >> We have an error talking to the kernel
> >>
> >
> > This message usually translates to: 'tc understood your syntax just
> > fine, and tried to tell the kernel about it, but the kernel did not
> > understand, most likely because it does not support this feature.'
> >
> > Do you have 'Netfilter marks support' enabled?
> > (Just a guess, may be a different setting)
> >
> > Regards
> > Andreas Klauer
> >
> >
When comparing your commands to mine, i noticed that you are never
incrementing the prio. Possibly try your command but with prio 2. I
seem to recall having issues when i was only using one prio for
everything, but incrementing it with each group of filters seemed to
work better.
Currently i have filter rules like this:
tc filter add dev $DEV parent 1:0 protocol ip prio 8 handle ${MARKP2P}
fw classid 1:13
which is followed by
tc filter add dev $DEV parent 1: protocol ip prio 12 u32 \
match ip tos 0x10 0xff \
flowid 1:11
If this doesn't work, then it is likely some kernel options you need
to enable, or possible you need to recompile iptables/tc?
- Jody
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: Gigabyte i-Ram cards
From: Jure Pečar @ 2006-04-07 21:10 UTC (permalink / raw)
To: linux-ide; +Cc: jeff
In-Reply-To: <20060321235313.dd36d8ff.pegasus@nerv.eu.org>
On Tue, 21 Mar 2006 23:53:13 +0100
Jure Pečar <pegasus@nerv.eu.org> wrote:
> I hope I'll manage to post my benchmarks by the end of the week. So far
> it looks very useful.
Finally, I have something: http://nerv.eu.org/iram/
I plan to do some more tests, when time permits.
--
Jure Pečar
http://jure.pecar.org/
^ permalink raw reply
* Re: [PATCH] Fix swap entry for MIPS32 36-bit physical address
From: Sergei Shtylyov @ 2006-04-07 21:19 UTC (permalink / raw)
Cc: linux-mips, Ralf Baechle, Pete Popov, Jordan Crouse
In-Reply-To: <4436C301.2060001@ru.mvista.com>
Hello.
Sergei Shtylyov wrote:
>> Additionally, PTEs in MIPS32R2 should have the same layout for the
>> 36-bit physical address case as in MIPS32R1, according to the
>> architecture manuals -- so, fix the #ifdef's.
> I've decided to tead off that part (incomplete anyway) and move it to
> a separate patch which I'll post shortly.
I'm really not sure that we need that #if defined(CONFIG_CPU_MIPS32) -- it
renders CONFIG_64BIT_PHYS_ADDR non-working on all other 32-bit CPUs for which
Kconfig entry claims that this support exists:
config 64BIT_PHYS_ADDR
bool "Support for 64-bit physical address space"
depends on (CPU_R4X00 || CPU_R5000 || CPU_RM7000 || CPU_RM9000 ||
CPU_R10000 || CPU_SB1 || CPU_MIPS32 || CPU_MIPS64) && 32BIT
At least RM7000 has the same PTE layout as MIPS32, I guess the others also
do. I suspect that the intent was to limit this option to the Alchemy CPUs
where it's *really* necessary?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] Fix swap entry for MIPS32 36-bit physical address
From: Sergei Shtylyov @ 2006-04-07 21:19 UTC (permalink / raw)
Cc: linux-mips, Ralf Baechle, Pete Popov, Jordan Crouse
In-Reply-To: <4436C301.2060001@ru.mvista.com>
Hello.
Sergei Shtylyov wrote:
>> Additionally, PTEs in MIPS32R2 should have the same layout for the
>> 36-bit physical address case as in MIPS32R1, according to the
>> architecture manuals -- so, fix the #ifdef's.
> I've decided to tead off that part (incomplete anyway) and move it to
> a separate patch which I'll post shortly.
I'm really not sure that we need that #if defined(CONFIG_CPU_MIPS32) -- it
renders CONFIG_64BIT_PHYS_ADDR non-working on all other 32-bit CPUs for which
Kconfig entry claims that this support exists:
config 64BIT_PHYS_ADDR
bool "Support for 64-bit physical address space"
depends on (CPU_R4X00 || CPU_R5000 || CPU_RM7000 || CPU_RM9000 ||
CPU_R10000 || CPU_SB1 || CPU_MIPS32 || CPU_MIPS64) && 32BIT
At least RM7000 has the same PTE layout as MIPS32, I guess the others also
do. I suspect that the intent was to limit this option to the Alchemy CPUs
where it's *really* necessary?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/5] generic clocksource updates
From: john stultz @ 2006-04-07 21:08 UTC (permalink / raw)
To: Roman Zippel; +Cc: Thomas Gleixner, Andrew Morton, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0604072239110.32445@scrub.home>
On Fri, 2006-04-07 at 22:43 +0200, Roman Zippel wrote:
> Hi,
>
> On Thu, 6 Apr 2006, Thomas Gleixner wrote:
>
> > > Currently this field isn't needed and as soon we have a need for it, we
> > > can add proper capability information.
> >
> > Is there a reason, why requirements which are known from existing
> > experience must be discarded to be reintroduced later ?
>
> Then please explain these requirements.
> This field shouldn't have been added in first place, I guess I managed to
> confuse John when I talked about handling of continuous vs. tick based
> clocks. Currently no user should even care about this, it's an
> implementation detail of the clock.
I don't think you confused me on this issue (although, I admit I'm prone
to confusion).
The is_continuous flag on the clocksource is used so other systems can
query if timekeeping is able to function without regular timer ticks.
This would be necessary for the HRT patchset, as well as the dynamic
tick patches, as they both reprograms the tick frequency, and need to
know if that will affect time.
I can reasonably drop this bit from the current patches, but it is very
small and and will be needed shortly, so I'm not sure its that big of a
deal.
thanks
-john
^ permalink raw reply
* Re: 2.6.17-rc1: bcm43xx problems with BCM4306 on x86_64
From: Rafael J. Wysocki @ 2006-04-07 21:08 UTC (permalink / raw)
To: Michael Buesch; +Cc: bcm43xx-dev, LKML, discuss
In-Reply-To: <200604072105.53994.mb@bu3sch.de>
On Friday 07 April 2006 21:05, Michael Buesch wrote:
> On Friday 07 April 2006 18:59, Rafael J. Wysocki wrote:
> > I've just tried the version of the driver included in 2.6.17-rc1 on an
> > x86_64 box (Asus L5D) with a built-in PCI BCM4306 adapter (Broadcom
> > Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)), and
> > unfortunately it doesn't seem to work.
> >
> > The driver loads and seems to initialize the adapter, but that's all,
> > apparently.
> >
> > First, I compiled the driver with DMA and PIO support, but it hanged my box
> > solid when I tried "iwconfig eth1 essid on" on it. On the next boot I
> > noticed it caused the following messages to appear in dmesg:
> >
> > nommu_map_single: overflow 58ee7010+2404 of device mask 3fffffff
> > nommu_map_single: overflow 53669010+2404 of device mask 3fffffff
> > nommu_map_single: overflow 50180010+2404 of device mask 3fffffff
>
> You should probably report that to the x86_64 people.
I'll try -mm first and report if this still happens there.
> > and so on, down to 455aa010. Then I thought the adapter might be unable
> > to DMA for some reason and compiled it with PIO support only. It did not
> > hang the box any more, but I couldn't make it work.
>
> PIO does not work, yet. Give me some other few weeks, please.
Oops. Sorry for the noice then. ;-)
Greetings,
Rafael
^ permalink raw reply
* RE: How to know when file data has been flushed into disk?
From: Michael Guo @ 2006-04-07 21:07 UTC (permalink / raw)
To: Xin Zhao, linux-os (Dick Johnson); +Cc: linux-kernel, linux-fsdevel
1)Checking source code following fsync() system call. I believe that you would get more information.
2)Dick tell you ext3 based on journaling is a crash safety filesystem
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Xin Zhao
Sent: Friday, April 07, 2006 1:19 PM
To: linux-os (Dick Johnson)
Cc: linux-kernel; linux-fsdevel@vger.kernel.org
Subject: Re: How to know when file data has been flushed into disk?
Thanks for reply.
I think Douglas answered the third question, I guess you are trying to
answer the first two questions. Maybe I don't get your point. But my
question is:
Since ext3 will commit the transaction AFTER all data is flushed to
disk, it must know when the data flush is done. But how does ext3 know
that? Where can I find this code in ext3 module?
Maybe software has no way to know when the data is really written into
disk platters since hard drive has cache too. But software (like
flushd) should know when it finishes sending the data to hard drive. I
guess ext3 will commit transaction at that time. So the mysterious
thing to me is how ext3 get notified that data has been flushed.
Any further thoughts?
cheers,
Xin
On 4/7/06, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:
>
> On Fri, 7 Apr 2006, Xin Zhao wrote:
>
> > Thanks for your reply.
> >
> > That make sense. But at least ext3 needs to know when all data has
> > been flushed so that it can commit the meta data. Question is how can
> > ext3 knows that? The data flushing is done by flush daemon. There go
> > to be some way to notify ext3 that data is flushed. Where is this
> > part of code in ext3 module?
> >
> > Xin
> >
> > On 4/7/06, Douglas McNaught <doug@mcnaught.org> wrote:
> >> "Xin Zhao" <uszhaoxin@gmail.com> writes:
> >>
> >>> 3. Does sys_close() have to be blocked until all data and metadata
> >>> are committed? If not, sys_close() may give application an illusion
> >>> that the file is successfully written, which can cause the application
> >>> to take subsequent operation. However, data flush could be failed. In
> >>> this case, file system seems to mislead the application. Is this true?
> >>> If so, any solutions?
> >>
> >> The fsync() call is the way to make sure written data has hit the
> >> disk. close() doesn't guarantee that.
> >>
> >> -Doug
> >>
>
> In principle, you __never__ know that the data got to the
> disk platter(s). Any database that thinks differently is
> broken by design. You need transaction processing to be
> assured that you have all the (correct) data available
> in the database. Transaction processing provides atomic
> stepping stones so that, in the event of a failure, the
> transactions can be rolled back to the last complete one
> and then restarted.
>
> The simplest example is the use of a number of journal
> files, each containing a record of the previous
> transactions and enough information to roll-back the
> database to the point at which these files were saved.
> These files are checksummed and saved in order. In the
> event of a crash, these files are read until the latest
> of the readable ones has a correct checksum. The database
> manager uses the information in the file to roll-back
> the main database to the exact content at the time the
> journal file was saved.
>
> Once the database is restarted, any previous journal
> files can be deleted as well as the bad ones that followed.
> However, the journal file that was used to restart the
> database is never deleted until it has been superseded
> by another that worked in a database restart. That way,
> there is always a way to get back to a clean database.
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.15.4 on an i686 machine (5589.42 BogoMips).
> Warning : 98.36% of all statistics are fiction, book release in April.
> _
> \x1a\x04
>
> ****************************************************************
> The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
>
> Thank you.
>
-
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/
^ 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.