* [U-Boot-Users] Re: [DNX#2006040542000055] [patch] add .gitignore
From: DENX Support System @ 2006-04-05 15:00 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a follow up
to [DNX#2006040542000055] was entered through the web interface:
<snip>
> Dear Hiroshi Ito,
>
> in message <20060405.233002.48531924.ito@mlb.co.jp> you wrote:
> >
> > * add .gitignore
> > Patch by Hiroshi Ito, 5 Apr 2006
>
> I'm sorry, but for reasons explained before (see mailing list
> archive) I do not *want* to have any .gitignore files in the U-Boot
> tree.
>
> Please bear with me, but I'm so used to this style of working that I
> don't to change it.
>
> Patch rejected.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> You see things; and you say ``Why?'' But I dream things that never
> were; and I say ``Why not?''
> - George Bernard Shaw _Back to Methuselah_ (1921) pt. 1, act 1
</snip>
Your U-Boot support team
^ permalink raw reply
* [PATCH] [IPSEC] Avoid null pointer dereference in xfrm4_rcv_encap
From: Dave Kleikamp @ 2006-04-05 14:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller; +Cc: netdev, linux-kernel
I'm getting a panic that I've traced back to this changeset:
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e695633e21ffb6a443a8c2f8b3f095c7f1a48eb0
xfrm4_rcv_encap dereferences x->encap without testing it for null.
Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com>
--- linux-2.6.17-rc1-mm1/net/ipv4/xfrm4_input.c.orig 2006-04-04
07:37:23.444068000 -0500
+++ linux-2.6.17-rc1-mm1/net/ipv4/xfrm4_input.c 2006-04-05
09:01:08.798510500 -0500
@@ -90,7 +90,7 @@ int xfrm4_rcv_encap(struct sk_buff *skb,
if (unlikely(x->km.state != XFRM_STATE_VALID))
goto drop_unlock;
- if (x->encap->encap_type != encap_type)
+ if (x->encap && (x->encap->encap_type != encap_type))
goto drop_unlock;
if (x->props.replay_window && xfrm_replay_check(x, seq))
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree
From: Dmitry Torokhov @ 2006-04-05 14:59 UTC (permalink / raw)
To: Rene Herman
Cc: Greg KH, alsa-devel, linux-kernel, tiwai, Andrew Morton,
Russell King
In-Reply-To: <4433CB34.6010707@keyaccess.nl>
On 4/5/06, Rene Herman <rene.herman@keyaccess.nl> wrote:
> Dmitry Torokhov wrote:
>
> > On Tuesday 04 April 2006 18:12, Rene Herman wrote:
>
> >> To Dmitry, I see you saying "probe() failing is driver's problem.
> >> The device is still there and should still be presented in sysfs.".
> >> No, at least in the case of these platform drivers (or at least
> >> these old ISA cards using the platform driver interface), a -ENODEV
> >> return from the probe() method would mean the device is _not_
> >> present (or not found at least). NODEV.
> >
> > Or you could separate device probing code from driver->probe(). BTW I
> > think that ->probe() is not the best name for that method.
>
> Right...
>
> > It really is supposed to allocate resources and initialize the device
> > so that it is ready to be used, not to verify that device is present.
> > The code that created device shoudl've done that.
>
> How do you feel about the flag that I've been proposing that a driver
> that needs to probe for its hardware could set and that says "if we
> return an error (or specifically -ENODEV I guess) the hardware's
> reallyreally not present and the device should not register"?
>
> Greg, and how do you feel about such a flag?
>
> As an alternative to the flag, how would either of you feel about either
>
> 1) adding a .discover method to struct device_driver that noone other
> than drivers for this old non generically discoverable hardware would
> set but which would make a registration fail if set and returning < 0?
>
> 2) adding that method only to platform_driver?
>
> 3) ... and after a few months when people aren't paying attention
> anymore rename .probe to .init and .discover back to .probe? ;-)
>
You need to let go of the model that driver that drives hardware also
do the device discovery and it will all fall into place. While it may
be contained in the same source module it is 2 different code chunks
(for the lack of the better word) and we should not mix them together.
> Russel, you wrote:
>
> > Note also that this patch will not do what the ALSA folk want - they
> > want to know if the device was found or whether the probe returned
> > -ENODEV. We knock -ENODEV and -ENXIO to zero in
> > driver_probe_device(), so they won't even see that.
>
> Yes, I know about the -ENODEV / -ENXIO thing. I asked for comment on
> that as well, but haven't gotten any.
>
> Anyways, the additional method would, I feel, be the conceptually
> cleanest approach. Practically speaking though, simply doing a manual
> probe and only calling platform_register() after everything is found to
> be present and accounted for is not much of a problem either.
>
Unfortunately it breaks manual driver binding/unbinding through sysfs
so I don't think it is a good long-term solution.
--
Dmitry
^ permalink raw reply
* Re: patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree
From: Dmitry Torokhov @ 2006-04-05 14:59 UTC (permalink / raw)
To: Rene Herman
Cc: Greg KH, alsa-devel, linux-kernel, tiwai, Andrew Morton,
Russell King
In-Reply-To: <4433CB34.6010707@keyaccess.nl>
On 4/5/06, Rene Herman <rene.herman@keyaccess.nl> wrote:
> Dmitry Torokhov wrote:
>
> > On Tuesday 04 April 2006 18:12, Rene Herman wrote:
>
> >> To Dmitry, I see you saying "probe() failing is driver's problem.
> >> The device is still there and should still be presented in sysfs.".
> >> No, at least in the case of these platform drivers (or at least
> >> these old ISA cards using the platform driver interface), a -ENODEV
> >> return from the probe() method would mean the device is _not_
> >> present (or not found at least). NODEV.
> >
> > Or you could separate device probing code from driver->probe(). BTW I
> > think that ->probe() is not the best name for that method.
>
> Right...
>
> > It really is supposed to allocate resources and initialize the device
> > so that it is ready to be used, not to verify that device is present.
> > The code that created device shoudl've done that.
>
> How do you feel about the flag that I've been proposing that a driver
> that needs to probe for its hardware could set and that says "if we
> return an error (or specifically -ENODEV I guess) the hardware's
> reallyreally not present and the device should not register"?
>
> Greg, and how do you feel about such a flag?
>
> As an alternative to the flag, how would either of you feel about either
>
> 1) adding a .discover method to struct device_driver that noone other
> than drivers for this old non generically discoverable hardware would
> set but which would make a registration fail if set and returning < 0?
>
> 2) adding that method only to platform_driver?
>
> 3) ... and after a few months when people aren't paying attention
> anymore rename .probe to .init and .discover back to .probe? ;-)
>
You need to let go of the model that driver that drives hardware also
do the device discovery and it will all fall into place. While it may
be contained in the same source module it is 2 different code chunks
(for the lack of the better word) and we should not mix them together.
> Russel, you wrote:
>
> > Note also that this patch will not do what the ALSA folk want - they
> > want to know if the device was found or whether the probe returned
> > -ENODEV. We knock -ENODEV and -ENXIO to zero in
> > driver_probe_device(), so they won't even see that.
>
> Yes, I know about the -ENODEV / -ENXIO thing. I asked for comment on
> that as well, but haven't gotten any.
>
> Anyways, the additional method would, I feel, be the conceptually
> cleanest approach. Practically speaking though, simply doing a manual
> probe and only calling platform_register() after everything is found to
> be present and accounted for is not much of a problem either.
>
Unfortunately it breaks manual driver binding/unbinding through sysfs
so I don't think it is a good long-term solution.
--
Dmitry
-------------------------------------------------------
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\x110944&bid$1720&dat\x121642
^ permalink raw reply
* Re: [Qemu-devel] Missing ARMv6 instructions?
From: Thiemo Seufer @ 2006-04-05 14:41 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <1143996162.6857.110.camel@localhost>
On Sun, Apr 02, 2006 at 04:42:42PM +0000, Chris Wilson wrote:
> Hi Jamie,
>
> > I like the idea, but do you know of anyone using OpenCores devices
> > implemented in silicon? It seems to me the motivation for ARM
> > emulation is to be able to simulate embedded devices that people may
> > feasibly end up using.
>
> I'm no expert, but it appears that OpenCores have a working core that
> runs most of the MIPS instruction set. MIPS is a very well known, tried
> and trusted architecture. My cable modem has a MIPS-compatible processor
> made by Toshiba. It seems to me that MIPS is just as realistic and
> usable platform as ARM. But I would be very interested to hear from
> anyone who knows better.
>
> Now, I wonder when Qemu will support MIPS emulation? :-)
When somebody implements more of the necessary support. The specs
are available from mips.com (free registration needed).
Thiemo
^ permalink raw reply
* Re: It seems I've found why conntrack blocks some packets
From: Steven M Campbell @ 2006-04-05 14:55 UTC (permalink / raw)
To: Carlos Pastorino; +Cc: netfilter
In-Reply-To: <cc4fcc140604040536l21166fd3j489ef6b1619c11b@mail.gmail.com>
Carlos Pastorino wrote:
>
> By the way, do you keep rp_filter enabled or disabled?
>
enabled but I'm originally a network geek by trade so my network is very clean with regards to where subnets are so reverse path filters work for me.
^ permalink raw reply
* [2.6 patch] remove Documentation/scsi/cpqfc.txt
From: Adrian Bunk @ 2006-04-05 14:50 UTC (permalink / raw)
To: James.Bottomley; +Cc: linux-scsi, linux-kernel
This patch removes the documentation for an already removed driver.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
Documentation/scsi/00-INDEX | 2
Documentation/scsi/cpqfc.txt | 272 -----------------------------------
2 files changed, 274 deletions(-)
--- linux-2.6.17-rc1-mm1-full/Documentation/scsi/00-INDEX.old 2006-04-05 16:47:24.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/Documentation/scsi/00-INDEX 2006-04-05 16:47:33.000000000 +0200
@@ -30,8 +30,6 @@
- info on driver for Adaptec controllers
aic7xxx_old.txt
- info on driver for Adaptec controllers, old generation
-cpqfc.txt
- - info on driver for Compaq Tachyon TS adapters
dpti.txt
- info on driver for DPT SmartRAID and Adaptec I2O RAID based adapters
dtc3x80.txt
--- linux-2.6.17-rc1-mm1-full/Documentation/scsi/cpqfc.txt 2006-03-20 06:53:29.000000000 +0100
+++ /dev/null 2006-02-12 01:05:26.000000000 +0100
@@ -1,272 +0,0 @@
-Notes for CPQFCTS driver for Compaq Tachyon TS
-Fibre Channel Host Bus Adapter, PCI 64-bit, 66MHz
-for Linux (RH 6.1, 6.2 kernel 2.2.12-32, 2.2.14-5)
-SMP tested
-Tested in single and dual HBA configuration, 32 and 64bit busses,
-33 and 66MHz. Only supports FC-AL.
-SEST size 512 Exchanges (simultaneous I/Os) limited by module kmalloc()
- max of 128k bytes contiguous.
-
-Ver 2.5.4 Oct 03, 2002
- * fixed memcpy of sense buffer in ioctl to copy the smaller defined size
-Ver 2.5.3 Aug 01, 2002
- * fix the passthru ioctl to handle the Scsi_Cmnd->request being a pointer
-Ver 2.5.1 Jul 30, 2002
- * fix ioctl to pay attention to the specified LUN.
-Ver 2.5.0 Nov 29, 2001
- * eliminated io_request_lock. This change makes the driver specific
- to the 2.5.x kernels.
- * silenced excessively noisy printks.
-
-Ver 2.1.2 July 23, 2002
- * initialize DumCmnd->lun in cpqfcTS_ioctl (used in fcFindLoggedInPorts as LUN index)
-
-Ver 2.1.1 Oct 18, 2001
- * reinitialize Cmnd->SCp.sent_command (used to identify commands as
- passthrus) on calling scsi_done, since the scsi mid layer does not
- use (or reinitialize) this field to prevent subsequent comands from
- having it set incorrectly.
-
-Ver 2.1.0 Aug 27, 2001
- * Revise driver to use new kernel 2.4.x PCI DMA API, instead of
- virt_to_bus(). (enables driver to work w/ ia64 systems with >2Gb RAM.)
- Rework main scatter-gather code to handle cases where SG element
- lengths are larger than 0x7FFFF bytes and use as many scatter
- gather pages as necessary. (Steve Cameron)
- * Makefile changes to bring cpqfc into line w/ rest of SCSI drivers
- (thanks to Keith Owens)
-
-Ver 2.0.5 Aug 06, 2001
- * Reject non-existent luns in the driver rather than letting the
- hardware do it. (some HW behaves differently than others in this area.)
- * Changed Makefile to rely on "make dep" instead of explicit dependencies
- * ifdef'ed out fibre channel analyzer triggering debug code
- * fixed a jiffies wrapping issue
-
-Ver 2.0.4 Aug 01, 2001
- * Incorporated fix for target device reset from Steeleye
- * Fixed passthrough ioctl so it doesn't hang.
- * Fixed hang in launch_FCworker_thread() that occurred on some machines.
- * Avoid problem when number of volumes in a single cabinet > 8
-
-Ver 2.0.2 July 23, 2001
- Changed the semiphore changes so the driver would compile in 2.4.7.
- This version is for 2.4.7 and beyond.
-
-Ver 2.0.1 May 7, 2001
- Merged version 1.3.6 fixes into version 2.0.0.
-
-Ver 2.0.0 May 7, 2001
- Fixed problem so spinlock is being initialized to UNLOCKED.
- Fixed updated driver so it compiles in the 2.4 tree.
-
- Ver 1.3.6 Feb 27, 2001
- Added Target_Device_Reset function for SCSI error handling
- Fixed problem with not reseting addressing mode after implicit logout
-
-
-Ver 1.3.4 Sep 7, 2000
- Added Modinfo information
- Fixed problem with statically linking the driver
-
-Ver 1.3.3, Aug 23, 2000
- Fixed device/function number in ioctl
-
-Ver 1.3.2, July 27, 2000
- Add include for Alpha compile on 2.2.14 kernel (cpq*i2c.c)
- Change logic for different FCP-RSP sense_buffer location for HSG80 target
- And search for Agilent Tachyon XL2 HBAs (not finished! - in test)
-
-Tested with
-(storage):
- Compaq RA-4x000, RAID firmware ver 2.40 - 2.54
- Seagate FC drives model ST39102FC, rev 0006
- Hitachi DK31CJ-72FC rev J8A8
- IBM DDYF-T18350R rev F60K
- Compaq FC-SCSI bridge w/ DLT 35/70 Gb DLT (tape)
-(servers):
- Compaq PL-1850R
- Compaq PL-6500 Xeon (400MHz)
- Compaq PL-8500 (500MHz, 66MHz, 64bit PCI)
- Compaq Alpha DS20 (RH 6.1)
-(hubs):
- Vixel Rapport 1000 (7-port "dumb")
- Gadzoox Gibralter (12-port "dumb")
- Gadzoox Capellix 2000, 3000
-(switches):
- Brocade 2010, 2400, 2800, rev 2.0.3a (& later)
- Gadzoox 3210 (Fabric blade beta)
- Vixel 7100 (Fabric beta firmare - known hot plug issues)
-using "qa_test" (esp. io_test script) suite modified from Unix tests.
-
-Installation:
-make menuconfig
- (select SCSI low-level, Compaq FC HBA)
-make modules
-make modules_install
-
-e.g. insmod -f cpqfc
-
-Due to Fabric/switch delays, driver requires 4 seconds
-to initialize. If adapters are found, there will be a entries at
-/proc/scsi/cpqfcTS/*
-
-sample contents of startup messages
-
-*************************
- scsi_register allocating 3596 bytes for CPQFCHBA
- ioremap'd Membase: c887e600
- HBA Tachyon RevId 1.2
-Allocating 119808 for 576 Exchanges @ c0dc0000
-Allocating 112904 for LinkQ @ c0c20000 (576 elements)
-Allocating 110600 for TachSEST for 512 Exchanges
- cpqfcTS: writing IMQ BASE 7C0000h PI 7C4000h
- cpqfcTS: SEST c0e40000(virt): Wrote base E40000h @ c887e740
-cpqfcTS: New FC port 0000E8h WWN: 500507650642499D SCSI Chan/Trgt 0/0
-cpqfcTS: New FC port 0000EFh WWN: 50000E100000D5A6 SCSI Chan/Trgt 0/1
-cpqfcTS: New FC port 0000E4h WWN: 21000020370097BB SCSI Chan/Trgt 0/2
-cpqfcTS: New FC port 0000E2h WWN: 2100002037009946 SCSI Chan/Trgt 0/3
-cpqfcTS: New FC port 0000E1h WWN: 21000020370098FE SCSI Chan/Trgt 0/4
-cpqfcTS: New FC port 0000E0h WWN: 21000020370097B2 SCSI Chan/Trgt 0/5
-cpqfcTS: New FC port 0000DCh WWN: 2100002037006CC1 SCSI Chan/Trgt 0/6
-cpqfcTS: New FC port 0000DAh WWN: 21000020370059F6 SCSI Chan/Trgt 0/7
-cpqfcTS: New FC port 00000Fh WWN: 500805F1FADB0E20 SCSI Chan/Trgt 0/8
-cpqfcTS: New FC port 000008h WWN: 500805F1FADB0EBA SCSI Chan/Trgt 0/9
-cpqfcTS: New FC port 000004h WWN: 500805F1FADB1EB9 SCSI Chan/Trgt 0/10
-cpqfcTS: New FC port 000002h WWN: 500805F1FADB1ADE SCSI Chan/Trgt 0/11
-cpqfcTS: New FC port 000001h WWN: 500805F1FADBA2CA SCSI Chan/Trgt 0/12
-scsi4 : Compaq FibreChannel HBA Tachyon TS HPFC-5166A/1.2: WWN 500508B200193F50
- on PCI bus 0 device 0xa0fc irq 5 IObaseL 0x3400, MEMBASE 0xc6ef8600
-PCI bus width 32 bits, bus speed 33 MHz
-FCP-SCSI Driver v1.3.0
-GBIC detected: Short-wave. LPSM 0h Monitor
-scsi : 5 hosts.
- Vendor: IBM Model: DDYF-T18350R Rev: F60K
- Type: Direct-Access ANSI SCSI revision: 03
-Detected scsi disk sdb at scsi4, channel 0, id 0, lun 0
- Vendor: HITACHI Model: DK31CJ-72FC Rev: J8A8
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdc at scsi4, channel 0, id 1, lun 0
- Vendor: SEAGATE Model: ST39102FC Rev: 0006
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdd at scsi4, channel 0, id 2, lun 0
- Vendor: SEAGATE Model: ST39102FC Rev: 0006
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sde at scsi4, channel 0, id 3, lun 0
- Vendor: SEAGATE Model: ST39102FC Rev: 0006
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdf at scsi4, channel 0, id 4, lun 0
- Vendor: SEAGATE Model: ST39102FC Rev: 0006
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdg at scsi4, channel 0, id 5, lun 0
- Vendor: SEAGATE Model: ST39102FC Rev: 0006
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdh at scsi4, channel 0, id 6, lun 0
- Vendor: SEAGATE Model: ST39102FC Rev: 0006
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdi at scsi4, channel 0, id 7, lun 0
- Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.48
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdj at scsi4, channel 0, id 8, lun 0
- Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.48
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdk at scsi4, channel 0, id 8, lun 1
- Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.40
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdl at scsi4, channel 0, id 9, lun 0
- Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.40
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdm at scsi4, channel 0, id 9, lun 1
- Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdn at scsi4, channel 0, id 10, lun 0
- Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdo at scsi4, channel 0, id 11, lun 0
- Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdp at scsi4, channel 0, id 11, lun 1
- Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdq at scsi4, channel 0, id 12, lun 0
- Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54
- Type: Direct-Access ANSI SCSI revision: 02
-Detected scsi disk sdr at scsi4, channel 0, id 12, lun 1
-resize_dma_pool: unknown device type 12
-resize_dma_pool: unknown device type 12
-SCSI device sdb: hdwr sector= 512 bytes. Sectors= 35843670 [17501 MB] [17.5 GB]
- sdb: sdb1
-SCSI device sdc: hdwr sector= 512 bytes. Sectors= 144410880 [70513 MB] [70.5 GB]
- sdc: sdc1
-SCSI device sdd: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB]
- sdd: sdd1
-SCSI device sde: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB]
- sde: sde1
-SCSI device sdf: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB]
- sdf: sdf1
-SCSI device sdg: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB]
- sdg: sdg1
-SCSI device sdh: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB]
- sdh: sdh1
-SCSI device sdi: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB]
- sdi: sdi1
-SCSI device sdj: hdwr sector= 512 bytes. Sectors= 2056160 [1003 MB] [1.0 GB]
- sdj: sdj1
-SCSI device sdk: hdwr sector= 512 bytes. Sectors= 2052736 [1002 MB] [1.0 GB]
- sdk: sdk1
-SCSI device sdl: hdwr sector= 512 bytes. Sectors= 17764320 [8673 MB] [8.7 GB]
- sdl: sdl1
-SCSI device sdm: hdwr sector= 512 bytes. Sectors= 8380320 [4091 MB] [4.1 GB]
- sdm: sdm1
-SCSI device sdn: hdwr sector= 512 bytes. Sectors= 17764320 [8673 MB] [8.7 GB]
- sdn: sdn1
-SCSI device sdo: hdwr sector= 512 bytes. Sectors= 17764320 [8673 MB] [8.7 GB]
- sdo: sdo1
-SCSI device sdp: hdwr sector= 512 bytes. Sectors= 17764320 [8673 MB] [8.7 GB]
- sdp: sdp1
-SCSI device sdq: hdwr sector= 512 bytes. Sectors= 2056160 [1003 MB] [1.0 GB]
- sdq: sdq1
-SCSI device sdr: hdwr sector= 512 bytes. Sectors= 2052736 [1002 MB] [1.0 GB]
- sdr: sdr1
-
-*************************
-
-If a GBIC of type Short-wave, Long-wave, or Copper is detected, it will
-print out; otherwise, "none" is displayed. If the cabling is correct
-and a loop circuit is completed, you should see "Monitor"; otherwise,
-"LoopFail" (on open circuit) or some LPSM number/state with bit 3 set.
-
-
-ERRATA:
-1. Normally, Linux Scsi queries FC devices with INQUIRY strings. All LUNs
-found according to INQUIRY should get READ commands at sector 0 to find
-partition table, etc. Older kernels only query the first 4 devices. Some
-Linux kernels only look for one LUN per target (i.e. FC device).
-
-2. Physically removing a device, or a malfunctioning system which hides a
-device, leads to a 30-second timeout and subsequent _abort call.
-In some process contexts, this will hang the kernel (crashing the system).
-Single bit errors in frames and virtually all hot plugging events are
-gracefully handled with internal driver timer and Abort processing.
-
-3. Some SCSI drives with error conditions will not handle the 7 second timeout
-in this software driver, leading to infinite retries on timed out SCSI commands.
-The 7 secs balances the need to quickly recover from lost frames (esp. on sequence
-initiatives) and time needed by older/slower/error-state drives in responding.
-This can be easily changed in "Exchanges[].timeOut".
-
-4. Due to the nature of FC soft addressing, there is no assurance that the
-same LUNs (drives) will have the same path (e.g. /dev/sdb1) from one boot to
-next. Dynamic soft address changes (i.e. 24-bit FC port_id) are
-supported during run time (e.g. due to hot plug event) by the use of WWN to
-SCSI Nexus (channel/target/LUN) mapping.
-
-5. Compaq RA4x00 firmware version 2.54 and later supports SSP (Selective
-Storage Presentation), which maps LUNs to a WWN. If RA4x00 firmware prior
-2.54 (e.g. older controller) is used, or the FC HBA is replaced (another WWN
-is used), logical volumes on the RA4x00 will no longer be visible.
-
-
-Send questions/comments to:
-Amy Vanzant-Hodge (fibrechannel@compaq.com)
-
^ permalink raw reply
* [U-Boot-Users] Re: [DNX#2006040542000055] [patch] add .gitignore
From: Wolfgang Denk @ 2006-04-05 14:50 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060405.233002.48531924.ito@mlb.co.jp>
Dear Hiroshi Ito,
in message <20060405.233002.48531924.ito@mlb.co.jp> you wrote:
>
> * add .gitignore
> Patch by Hiroshi Ito, 5 Apr 2006
I'm sorry, but for reasons explained before (see mailing list
archive) I do not *want* to have any .gitignore files in the U-Boot
tree.
Please bear with me, but I'm so used to this style of working that I
don't to change it.
Patch rejected.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You see things; and you say ``Why?'' But I dream things that never
were; and I say ``Why not?''
- George Bernard Shaw _Back to Methuselah_ (1921) pt. 1, act 1
^ permalink raw reply
* Re: VPN module
From: Christopher J. PeBenito @ 2006-04-05 14:49 UTC (permalink / raw)
To: Erich Schubert; +Cc: SE Linux
In-Reply-To: <1144238374.19128.11.camel@wintermute.xmldesign.de>
On Wed, 2006-04-05 at 13:59 +0200, Erich Schubert wrote:
> Hi,
> I'll probably write a OpenVPN module sometime soon.
> We already have a "vpn" module, but that is only for the vpnc client so
> far.
> Should I
> - try to make a single module for both (I consider that a bad idea,
> since vpnc is a client only for cisco VPNs, whereas OpenVPN can be used
> as a full-blown VPN server and is much more flexible)
> - rename the vpn policy to vpnc and make a new "openvpn" module?
Creating openvpn will be fine, but the vpn module has to stay as is,
because we can't rename modules, because it causes upgrade issues. For
example, if you have a vpn module inserted, and you try to insert vpnc
module, it fails because of duplicate symbols. Perhaps we need support
in modules for one module to deprecate another, so if you insert the
vpnc module, libsemanage automatically removes vpn as part of the
transaction.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: OOM kills if swappiness set to 0, swap storms otherwise
From: Charles Shannon Hendrix @ 2006-04-05 14:47 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20060327195905.7f666cb5.akpm@osdl.org>
Mon, 27 Mar 2006 @ 19:59 -0800, Andrew Morton said:
> Much porkiness.
>
> /proc/meminfo is very useful for obtaining a top-level view of where all
> the memory's gone to. I'd tentatively say that your options are to put up
> with the swapping or find a new mail client.
I use mutt for my email, and I have the same issue on a 1GB system.
I really wish we could put an upper limit on what file cache can use.
I understand the original poster was running a lot of pork, but you
don't have to and still see a problem with swapping. Even running KDE
my total application memory most of the time is 300MB or less on a
machine with 1GB of memory.
I shouldn't be suffering from swap storms.
For example, my normal working set of programs eats about 250MB of memory. If
I also start a job running to something like tag some mp3s, copy a CD, or just
process a lot of files, it only takes a few minutes before performance becomes
unacceptable.
If you are doing some work where you switch among several applications
frequently, the pigginess of file cache becomes a serious problem.
Isn't that bad behavior by any measure?
--
shannon "AT" widomaker.com -- ["It's a damn poor mind that can only think
of one way to spell a word." -- Andrew Jackson]
^ permalink raw reply
* Re: [Lhms-devel] [RFC 0/6] Swapless Page Migration V1: Overview
From: Lee Schermerhorn @ 2006-04-05 14:46 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-mm, lhms-devel, Hirokazu Takahashi, Marcelo Tosatti,
KAMEZAWA Hiroyuki
In-Reply-To: <20060404065739.24532.95451.sendpatchset@schroedinger.engr.sgi.com>
On Mon, 2006-04-03 at 23:57 -0700, Christoph Lameter wrote:
> Swapless Page migration
>
> Currently page migration is depending on the ability to assign swap entries
> to pages. This means that page migration will not work without swap although
> that swap space is never used.
>
> This patchset removes that dependency by introducing a special type of
> swap entry that encodes a pfn number of the page being migrated. If that
> swap pte is encountered then do_swap_page() will simply wait for the page
> to become unlocked again (meaning page migration is complete) and then refetch
> the pte. The special type of swap entry is only in use while the page to be
> migrated is locked and therefore we can hopefully get away with just a few
> supporting functions.
>
> To some extend this covers the same ground as Lee's and Marcelo's migration
> cache. However, I hope that this approach simplifies things without opening
> up any holes. Please check.
>
Christoph:
Does this approach still allow "migrate-on-fault" for anon pages?
Especially, in the case where the migrating page has >1 pte referencing
it? How will the fault handler find all of the pte's referencing the
old page? Actually, I don't think we'd want to burden the task whose
fault caused the migration with finding and replacing and replacing all
pte's referecing the old page. Using a real cache, this isn't a problem
because we replace the old page with a new one in the cache, and the
cache ptes reference the cache entry. Tasks are free to fault in a real
pte for the new page at any time. I'd hate to lose this capability. I
believe that this is one of the reasons that Marcello used a real idr-
based cache for the migration cache.
Lee
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Xenomai-help] problems building xenomai 2.1 for ppc
From: Philippe Gerum @ 2006-04-05 14:45 UTC (permalink / raw)
To: Landau, Bracha; +Cc: xenomai
In-Reply-To: <02AA386EB831044F8537A696BA785C78A664EF@ILEX5.IL.NDS.COM>
Landau, Bracha wrote:
> I'm trying to build xenomai 2.1 for an 8272 architecture using kernel 2.6.14.
> I've successfully put in the adeos patch.
> Here are the problems I've encountered.
>
> 1) When doing ./scripts/prepare-kernel.sh I get an error that it can't find the file /include/asm-powerpc/ipipe.h.
> I copied the file ipipe.h from /include/asm-ppc and reran prepare-kernel.sh with no errors.
>
You don't need to move kernel files around manually (actually, this
almost never works properly). Please have a look at README.INSTALL,
section 1 "Preparing the target kernel".
> 2) After doing the above and configuring the "prepared" kernel for running with xenomai, I tried to build the kernel. I got link errors doing it. An example of such a link error is:
>
> kernel/built-in.o: In function 'rthal_init':
> :undefined reference to 'rthal_arch_init'
>
>
> (The list is much longer - many undefined references of this sort.)
>
> Any ideas what the problem may be?
>
> ***********************************************************************************
> This email message and any attachments thereto are intended only for use by the addressee(s) named above, and may contain legally privileged and/or confidential information. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the postmaster@domain.hid and destroy the original message.
> ***********************************************************************************
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>
--
Philippe.
^ permalink raw reply
* Re: [libnetfilter_queue]
From: Eric Leblond @ 2006-04-05 14:44 UTC (permalink / raw)
To: David Vogt; +Cc: netfilter@lists.netfilter.org
In-Reply-To: <859616420604050556t39a5e7eeled57a3e25ed5d10a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]
Le mercredi 05 avril 2006 à 14:56 +0200, David Vogt a écrit :
> Dear all,
>
> I would like to send different packets to different userland
> applications using libnetfilter_queue. As far as I understand,
> different queues can be distingusihed using some kind of queue number.
> How does the appropriate iptables command look like that sends packets
> to a specific queue?
This is :
iptables -A .... -j NFQUEUE --queue-num $ID
BR,
--
Éric Leblond, eleblond@inl.fr
Téléphone : 01 44 89 46 39, Fax : 01 44 89 45 01
INL, http://www.inl.fr
[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Avoid a crash if realloc returns a different pointer.
From: Mike McCormack @ 2006-04-05 14:22 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 80 bytes --]
---
imap-send.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
[-- Attachment #2: 235cf581a853777fdb6886806ddbfcd9f782eb98.diff --]
[-- Type: text/x-patch, Size: 369 bytes --]
235cf581a853777fdb6886806ddbfcd9f782eb98
diff --git a/imap-send.c b/imap-send.c
index f3cb79b..d04259a 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -1202,6 +1202,7 @@ read_message( FILE *f, msg_data_t *msg )
p = xrealloc(msg->data, len+1);
if (!p)
break;
+ msg->data = p;
}
r = fread( &msg->data[msg->len], 1, len - msg->len, f );
if (r <= 0)
^ permalink raw reply related
* [PATCH] Avoid a divide by zero if there's no messages to send.
From: Mike McCormack @ 2006-04-05 14:22 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 86 bytes --]
---
imap-send.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
[-- Attachment #2: 8f910a131c905720e9640ddecfd8f85927ddc660.diff --]
[-- Type: text/x-patch, Size: 643 bytes --]
8f910a131c905720e9640ddecfd8f85927ddc660
diff --git a/imap-send.c b/imap-send.c
index d04259a..52e2400 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -1333,6 +1333,12 @@ main(int argc, char **argv)
return 1;
}
+ total = count_messages( &all_msgs );
+ if (!total) {
+ fprintf(stderr,"no messages to send\n");
+ return 1;
+ }
+
/* write it to the imap server */
ctx = imap_open_store( &server );
if (!ctx) {
@@ -1340,7 +1346,6 @@ main(int argc, char **argv)
return 1;
}
- total = count_messages( &all_msgs );
fprintf( stderr, "sending %d message%s\n", total, (total!=1)?"s":"" );
ctx->name = imap_folder;
while (1) {
^ permalink raw reply related
* Re: [PATCH 0/3] [RFC] fixed duration connection
From: Eric Leblond @ 2006-04-05 14:41 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Netfilter Development Mailinglist, NuFW devel
In-Reply-To: <4433CCBF.6060103@trash.net>
[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]
Le mercredi 05 avril 2006 à 15:57 +0200, Patrick McHardy a écrit :
> Eric Leblond wrote:
> > Hi,
> >
> > While working on NuFW development branch, we have had to
> > implement policy just as :
> > * connection to server is authorised from 08h to 18h and
> > connection must be switched off at 18h.
> > For this reason, we've worked on a simple kernel level implementation.
> > This is done via a second "struct timer" that is added in connection
> > structure. Activation of the timer, is for now done via userspace by
> > using libnetfilter_conntrack or by using new option -T of the conntrack
> > tool.
>
> If I understand you correctly, a fixed timeout is just a timeout that
> isn't refreshed, right?
Yes, exactly.
> Why can't we just use the regular timers etc.
> and add a flag that it should not be touched by ip_ct_refresh? This
> would also eliminate the need for any ctnetlink changes since the
> timeout value can already be specified.
This was my first attempt and this may be the good one. In fact I switch
to a second timer because we may have a fixed timeout that exceeds the
protocol timeout. Thus, connection may be removed far too long after
what's needed. For example, we could have an UDP connection with fixed
timeout of a couple day which is more than protool timeout.
In fact, this approach can introduces an overload of conntrack but the
second timer approach may cost more in term of timer handling.
BR,
--
Eric Leblond <eric@inl.fr>
NuFW : http://www.nufw.org
[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [LARTC] Tocken Bucket with priority?
From: Emanuele Colombo @ 2006-04-05 14:41 UTC (permalink / raw)
To: lartc
In-Reply-To: <e67264960604050618t481a1f79uffe3065ac2ebe56f@mail.gmail.com>
> What about using HTB and *then* using PRIO as its leaf class? You would
> use HTB only to shape.
Thanks, it could be a good idea! I'll try this as soon as possible.
Thanks!
--
Emanuele
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* [U-Boot-Users] Re: [DNX#2006040542000055] [patch] add .gitignore
From: DENX Support System @ 2006-04-05 14:40 UTC (permalink / raw)
To: u-boot
Hello list,
inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040542000055] was created:
<snip>
> Hello
>
> add .gitignore
>
> Signed-off-by: Hiroshi Ito <ito@mlb.co.jp>
>
> CHANGELOG:
>
> * add .gitignore
> Patch by Hiroshi Ito, 5 Apr 2006
>
> --------
> Hiroshi Ito
> Media Lab. Inc.,
> URL http://www.mlb.co.jp ( Sorry, Japanese only. )
> TEL +81-3-5294-7255 FAX +81-3-5294-7256
</snip>
Your U-Boot support team
^ permalink raw reply
* [U-Boot-Users] Re: [DNX#2006040542000055] [patch] add .git [...]
From: U-Boot patch tracking system @ 2006-04-05 14:40 UTC (permalink / raw)
To: u-boot
Dear Mr. U. Boot,
thank you for your contribution to the U-Boot project.
Your e-mail was registered at our system under the ticket
number [DNX#2006040542000055].
Your U-Boot support team
Powered by OTRS (http://otrs.org/)
^ permalink raw reply
* Re: [linux-lvm] pvmove on a root partition
From: Christopher Probst @ 2006-04-05 13:51 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <200604051048.59100@bj-ig.de>
Hello Ralf,
Thank you very much for the info. I guess I won't pvmove on a root partition
for a while ;)
Christopher
>From: Ralf M�ller <ralf@bj-ig.de>
>Reply-To: LVM general discussion and development <linux-lvm@redhat.com>
>To: LVM general discussion and development <linux-lvm@redhat.com>
>Subject: Re: [linux-lvm] pvmove on a root partition
>Date: Wed, 5 Apr 2006 10:48:54 +0200
>
>On Tuesday 04 April 2006 20:58, Christopher Probst wrote:
>
> > pvmove /dev/hdb1 /dev/hdb2 where /dev/hdb1 is mounted on "/"
> >
> > makes my system unuseable. I can't log into my machine even in a text
> > console. Has anybody tried this before?
>
>Yes - about a year before. And I failed. After asking I have been told
>there is some locking problem somewhere and there have to be major
>changes before this would work - if I remember correctly. The answer
>gave not the impression that this is rated a high priority problem.
>
>Regards
>Ralf
>
>--
>Van Roy's Law: -------------------------------------------------------
> An unbreakable toy is useful for breaking other toys.
><< attach4 >>
>_______________________________________________
>linux-lvm mailing list
>linux-lvm@redhat.com
>https://www.redhat.com/mailman/listinfo/linux-lvm
>read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
^ permalink raw reply
* reiserfs3 bug?
From: Jason Keltz @ 2006-04-05 14:39 UTC (permalink / raw)
To: reiserfs-list
Our Linux 2.4.32 NFS fileserver exports 4 reiserfs 3.6 filesystems to a
whole bunch of hosts. Somewhere between every 6-30 days, NFS suddenly
seems to "hang" (ie. all the hosts gets the "nfs server not responding"
message). The server is still up (we can ssh to it/etc). Up to this
point, we've thought it was a bug in nfs. We recently installed SGI kdb
(kernel debugger) to help with debugging the problem, and we're
wondering now whether it is actually reiserfs related. We need to get
the output from several crashes in order to do more debugging, although
we believe the problem is probably the same each time.
In a normal state, the WCHAN column on "ps" output lists the nfsd and
[kreiserfsd] processes as "end". When the system gets into this state,
both the nfsd and [kreiserfsd] processes report "down" for WCHAN.
(I can imagine that if kreiserfsd and nfs are both hanging on the same
lock, bad things could happen..)
The backtrace when the problem occurs for kreiserfsd yields:
Mar 28 13:04:24 0xf635a000 247 1 0 1 D 0xf635a370
kreiserfsd
Mar 28 13:04:24 ESP EIP Function (args)
Mar 28 13:04:24 0xf635bef8 0xc011b144 schedule+0x2b4 (0xc0452e40, 0x0,
0xf635a000, 0xd4a10970, 0xd4a10970)
Mar 28 13:04:24 kernel .text 0xc0100000
0xc011ae90 0xc011b3d0
Mar 28 13:04:24 0xf635bf40 0xc014680e __wait_on_buffer+0x6e (0xd4a10920,
0x9e0, 0xf635bf90, 0xc2937000, 0xf8ac6000)
Mar 28 13:04:24 kernel .text 0xc0100000
0xc01467a0 0xc0146840
Mar 28 13:04:24 0xf635bf68 0xf8943e79 [reiserfs]flush_commit_list+0x3e9
Mar 28 13:04:24 reiserfs .text 0xf8921060
0xf8943a90 0xf8943f60
Mar 28 13:04:24 0xf635bfa8 0xf894801d [reiserfs]flush_async_commits+0x3d
(0xf7576800, 0xdd667cc0, 0xf635bfd8, 0xf635bfdc, 0x20)
Mar 28 13:04:24 reiserfs .text 0xf8921060
0xf8947fe0 0xf8948020
Mar 28 13:04:25 0xf635bfb8 0xf894652b
[reiserfs]reiserfs_journal_commit_thread+0x1db
Mar 28 13:04:25 reiserfs .text 0xf8921060
0xf8946350 0xf89465f0
Mar 28 13:04:25 0xf635bff4 0xc010741e arch_kernel_thread+0x2e
Mar 28 13:04:25 kernel .text 0xc0100000
0xc01073f0 0xc0107430
single stepping on the processor after the problem reveals that the
system is "idle"/not doing anything else with this.
I won't bother including the output of the backtrace of the 256 nfs
processes on our fileserver here, but they probably give a lot more of
the story. If you are interested, please see this link for the full
details:
http://www.cs.yorku.ca/~jas/fileserver
If anyone has any ideas, or anywhere we could insert debugging code iin
order to help solve this problem, we would *really* appreciate your help!
We recently upgraded from 2.4.26 to 2.4.32 in the hopes that the bug
would have been fixed, but it didn't make any difference.
ps: A few times, when we issue the "reboot" command, the systems get
"unstuck" (systems get "nfs ok") just before the system reboots...
whatever is stuck seems to get unstuck for a moment before the system is
rebooted.
Thanks..
Jason Keltz
jas@cs.yorku.ca
^ permalink raw reply
* Re: Anybody applied the patch "Add 85xx CDS to arch/powerpc" on the 2.6.16. I failed to apply it:-(
From: Jon Loeliger @ 2006-04-05 14:38 UTC (permalink / raw)
To: fengcheng lu; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <e9aafa30604050732g6ede1f37h450243613bcbca85@mail.gmail.com>
So, like, the other day "fengcheng lu" mumbled:
>
> I downloaded this patch from
> http://patchwork.ozlabs.org/linuxppc/patch?id=3D4910. But I failed to apply
> it. The following is the output:
> debian:/usr/src/linux-2.6.16# patch -p1 <powerpc.patch
> patching file arch/powerpc/config/mpc85xx_cds_deconfig
> patching file arch/powerpc/platforms/85xx/Kconfig
> Hunk #1 FAILED at 11
> 1 out of 1 hunk FAILED -- saving rejects to file
> arch/powerpc/platforms/85xx/Kconfig.rej
> patching file arch/powerpc/platforms/85xx/Makefile
> Hunk #1 FAILED at 3
> 1 out of 1 hunk FAILED -- saving rejects to file
> arch/powerpc/platforms/85xx/Makefile.rej
> patching file arch/powerpc/platforms/85xx/mpc85xx_cds.c
> patching file arch/powerpc/platforms/85xx/mpc85xx_cds.h
> patching file include/asm-ppc/mpc85xx.h
>
> It looks seem the Makefile and Kconfig don't match yours.
What was the repository against which you applied this patch?
Was it Linus' or Paul's? I suspect it needs to be Paul's
powerpc.git repository.
HTH,
jdl
^ permalink raw reply
* Re: [PATCH] add support for XCHG instruction accessing APIC
From: Keir Fraser @ 2006-04-05 14:37 UTC (permalink / raw)
To: Boris Ostrovsky; +Cc: xen-devel
In-Reply-To: <4433D37B.2060102@virtualiron.com>
On 5 Apr 2006, at 15:26, Boris Ostrovsky wrote:
> OK, that's fair. Here is updated patch with lock removed.
Thanks.
> I don't think I then understand why Linux is using atomic accesses to
> local APICs. It's interesting though that 64-bit code doesn't do it ---
> they use vanilla apic_write().
The atomic accesses are to work around APIC bugs in the original
Pentium processors, where an APIC write in some cases needs to be
preceded by a read for the write to work correctly.
The XCHG trick isn't needed on x86_64 because only modern processors
support 64-bit mode and none of them have a buggy LAPIC.
-- Keir
^ permalink raw reply
* [Xenomai-help] problems building xenomai 2.1 for ppc
From: Landau, Bracha @ 2006-04-05 14:33 UTC (permalink / raw)
To: xenomai
I'm trying to build xenomai 2.1 for an 8272 architecture using kernel 2.6.14.
I've successfully put in the adeos patch.
Here are the problems I've encountered.
1) When doing ./scripts/prepare-kernel.sh I get an error that it can't find the file /include/asm-powerpc/ipipe.h.
I copied the file ipipe.h from /include/asm-ppc and reran prepare-kernel.sh with no errors.
2) After doing the above and configuring the "prepared" kernel for running with xenomai, I tried to build the kernel. I got link errors doing it. An example of such a link error is:
kernel/built-in.o: In function 'rthal_init':
:undefined reference to 'rthal_arch_init'
(The list is much longer - many undefined references of this sort.)
Any ideas what the problem may be?
***********************************************************************************
This email message and any attachments thereto are intended only for use by the addressee(s) named above, and may contain legally privileged and/or confidential information. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the postmaster@domain.hid and destroy the original message.
***********************************************************************************
^ permalink raw reply
* RE: Does dom0 see all physical processors? (RE:[Xen-ia64-devel] SAL INFO virtualization)
From: Ian Pratt @ 2006-04-05 14:32 UTC (permalink / raw)
To: Magenheimer, Dan (HP Labs Fort Collins), Keir Fraser, Tian, Kevin
Cc: Jimi Xenidis, xen-devel, okrieg, Tristan Gingold, xen-ia64-devel
> I believe ppc has "paravirtualized spinlocks" in their Linux
> kernel, though even this won't necessarily help with a poorly
> written SMP application.
We have an equivalent of this ("bad pre-emption mitigation"), along with
an alternative ("bad pre-emption avoidance"). Both have various pros and
cons, and can be shown to offer significant benefits in various
contrived benchmarks.
We have benchmark code that records when these bad pre-emptions happen,
and the workloads we've looked at we haven't been moved to check either
scheme in.
That's not to say that we won't have to at some point in the future, but
the limits to scalability are currently elsewhere.
> > > So on a 16-processor system, every time dom0 needs to run
> (e.g. to
> > > handle backend I/O for any one of perhaps hundreds of domains),
> > > *every* domain gets descheduled so that dom0 can be
> (gang-)scheduled
> > > on all 16 processors?
> > >
> > > If true, this sounds like a _horrible_ performance hit, so I hope
> > > I'm misunderstanding something...
> >
> > This isn't an issue.
> >
> > After booting you probably want dom0 to give up all but 1
> vCPU anyway.
>
> Unless of course the PCPU's have data that change over time,
> such as variable cycle rate (for power management) or
> hot-plug memory...
Such events don't happen very often -- dom0 is still free to run
something on a given CPU whenever it wants to.
Ian
^ 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.