* [tip:x86/mm] x86: Work around old gas bug
From: tip-bot for Jan Beulich @ 2011-03-03 11:52 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, shaohua.li, akpm, jbeulich, JBeulich,
tglx, mingo
In-Reply-To: <4D6F81B10200007800034B0B@vpn.id2.novell.com>
Commit-ID: d04c579f971bf7d995db1ef7a7161c0143068859
Gitweb: http://git.kernel.org/tip/d04c579f971bf7d995db1ef7a7161c0143068859
Author: Jan Beulich <JBeulich@novell.com>
AuthorDate: Thu, 3 Mar 2011 10:55:29 +0000
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Thu, 3 Mar 2011 12:47:08 +0100
x86: Work around old gas bug
Add extra parentheses around a couple of definitions introduced
by "x86: Cleanup vector usage" and used in assembly macro
arguments, and remove spaces. Without that old (2.16.1) gas
would see more macro arguments than were actually specified.
Reported-and-tested-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: Shaohua Li <shaohua.li@intel.com>
LKML-Reference: <4D6F81B10200007800034B0B@vpn.id2.novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/include/asm/irq_vectors.h | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h
index 4980f48..6e976ee 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -126,14 +126,14 @@
/* up to 32 vectors used for spreading out TLB flushes: */
#if NR_CPUS <= 32
-# define NUM_INVALIDATE_TLB_VECTORS NR_CPUS
+# define NUM_INVALIDATE_TLB_VECTORS (NR_CPUS)
#else
-# define NUM_INVALIDATE_TLB_VECTORS 32
+# define NUM_INVALIDATE_TLB_VECTORS (32)
#endif
-#define INVALIDATE_TLB_VECTOR_END 0xee
+#define INVALIDATE_TLB_VECTOR_END (0xee)
#define INVALIDATE_TLB_VECTOR_START \
- (INVALIDATE_TLB_VECTOR_END - NUM_INVALIDATE_TLB_VECTORS + 1)
+ (INVALIDATE_TLB_VECTOR_END-NUM_INVALIDATE_TLB_VECTORS+1)
#define NR_VECTORS 256
^ permalink raw reply related
* Re: [PATCH] add new Fermi 5xx codec IDs to snd-hda
From: Takashi Iwai @ 2011-03-03 11:52 UTC (permalink / raw)
To: Stephen Warren; +Cc: alsa-devel@alsa-project.org, Nitin Daga, Richard Samson
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF045687B08A@HQMAIL01.nvidia.com>
At Tue, 1 Mar 2011 09:45:54 -0800,
Stephen Warren wrote:
>
> Richard Samson wrote at Tuesday, March 01, 2011 10:16 AM:
> > Le mardi 01 mars 2011 à 08:40 -0800, Stephen Warren a écrit :
> > > Richard Samson wrote at Tuesday, March 01, 2011 8:15 AM:
> > > > Le lundi 28 février 2011 à 19:09 +0100, Takashi Iwai a écrit :
> > > > > At Mon, 28 Feb 2011 18:56:20 +0100,
> > > > > samson.richard@gmail.com wrote:
> > > > > > As Stephen Warren said, a patch with full support of 5xx cards will be
> > > > > > more useful.
> > > > >
> > > > > OK, Stephen, could you prepare the patch including all missing IDs?
> > > >
> > > > I wrote an new patch with three new codec IDs for Nvidia Fermi cards.
> > > > I attended to use existing IDs and online technical specifications to
> > > > get two others cards :
> > > > - Nvidia GeForce GTX 470 : id = 0x10de0015
> > > > - Nvidia GeForce GTX 560 Ti : id = 0x10de0016 (works fine)
> > > > - Nvidia GeForce GTX 570 : id = 0x10de0017
> > >
> > > They don't appear to match our Windows driver. Where did you get the values
> > > from? (0x17 isn't in the Windows driver at all. 0x15 shouldn't be a GTX 470)
> >
> > I ask to a reseller, it seems a bad idea.
>
> The only way to find the values that I know of would be to plug the card
> in, run Linux, and look at the ALSA /proc files. (Perhaps there's some
> equivalent tool under Windows)
>
> > If I can help, where are these values in the Windows driver ?
>
> They encoded into the binary. I doubt they're user-accessible.
>
> So, I think the best way to proceed is for you to modify your patch to add
> IDs 0x15 and 0x16 only. I'm pretty sure ID 0x17 isn't assigned to anything.
> Let's not remove any NVIDIA IDs even though I'm pretty sure a couple aren't
> actually assigned; if I'm wrong, we'd just have to add them back later, and
> having them in won't harm anything.
OK, I modified Richard's patch to get rid of 0x17 and merged now
to sound git tree.
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH] hwmon: (ads1015) Add devicetree documentation
From: Wolfram Sang @ 2011-03-03 11:51 UTC (permalink / raw)
To: Dirk Eibach; +Cc: linux-kernel, linux-doc, rdunlap, devicetree-discuss, khali
In-Reply-To: <1299143805-13133-1-git-send-email-eibach@gdsys.de>
[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]
On Thu, Mar 03, 2011 at 10:16:45AM +0100, Dirk Eibach wrote:
> Signed-off-by: Dirk Eibach <eibach@gdsys.de>
> ---
> Documentation/devicetree/bindings/i2c/ads1015.txt | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/i2c/ads1015.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/ads1015.txt b/Documentation/devicetree/bindings/i2c/ads1015.txt
> new file mode 100644
> index 0000000..3a7d67a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/ads1015.txt
> @@ -0,0 +1,15 @@
> +ADS1015 (I2C)
> +
> +Optional properties:
> +
> + - exported-channels : exported_channels is a bitmask that specifies which
> + inputs should be exported to sysfs.
Hmm, device tree bindings should be OS-neutral, sysfs is not. Maybe
"active-channels" would be better; then the OS could decide what to do
with the active channels. Then again, what is the drawback of exporting
all channels? Is there another hwmon-driver doing so (couldn't find
one)?
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v2] staging: keucr: use kernel byteorder functions
From: Jack Stone @ 2011-03-03 11:51 UTC (permalink / raw)
To: Jonathan Neuschäfer; +Cc: Greg Kroah-Hartman, Al Cho, devel, linux-kernel
In-Reply-To: <1299152300-5585-1-git-send-email-j.neuschaefer@gmx.net>
On 03/03/2011 11:38, Jonathan Neuschäfer wrote:
> ---
> drivers/staging/keucr/TODO | 1 -
> drivers/staging/keucr/common.h | 12 ------------
> drivers/staging/keucr/ms.c | 28 +++++++++++++++-------------
> 3 files changed, 15 insertions(+), 26 deletions(-)
You'll need at least a Signed-off-by and possibly a brief changelog
Pending that
Reviewed-by: Jack Stone <jwjstone@fastmail.fm>
Thanks,
Jack
^ permalink raw reply
* Re: [PATCH 1/2] staging: brcm80211: Add buf_size parameter to ampdu_action handler function
From: Javier Martinez Canillas @ 2011-03-03 11:50 UTC (permalink / raw)
To: Arend van Spriel
Cc: Brett Rudley, Henry Ptasinski, Dowan Kim, Roland Vossen,
Greg Kroah-Hartman, linux-wireless@vger.kernel.org,
devel@driverdev.osuosl.org
In-Reply-To: <op.vrqdhre53ri7v4@arend-laptop>
>>
> This currently gives a warning on staging-next branch:
>
> drivers/staging/brcm80211/brcmsmac/wl_mac80211.c:699: warning:
> initialization from incompatible pointer type
>
>
> Probably you have used a newer net/mac80211.h as reference which has not yet
> landed on the staging-next branch.
>
> Gr. AvS
> --
Hi Arend,
I tried to compile the driver in today linux-next (which already has
the patch applied) and doesn't gives any warning.
Please tell me if you still are having issues with it.
Thanks a lot.
--
-----------------------------------------
Javier Martínez Canillas
(+34) 682 39 81 69
PhD Student in High Performance Computing
Computer Architecture and Operating System Department (CAOS)
Universitat Autònoma de Barcelona
Barcelona, Spain
^ permalink raw reply
* Switching to 4.174.64.19 firmware for G-PHY cards?
From: Rafał Miłecki @ 2011-03-03 11:50 UTC (permalink / raw)
To: b43-dev
In-Reply-To: <AANLkTin1SKsQSsMMUq-+0K_j=8GUxWQmP0HyyaxtD3z3@mail.gmail.com>
W dniu 3 marca 2011 08:58 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> 2011/3/3 chris at martin.cc <chris@martin.cc>:
>> root at OpenWrt:/etc/config# wifi up
>> Error for wireless request "Set Power Management" (8B2C) :
>> ? ?SET failed on device wlan0 ; Operation not supported.
>> compat-wireless-2011-02-25/drivers/net/wireless/b43/main.c:2262
>> kzalloc 332 bytes
>> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
>> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 96 bytes
>> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 96 bytes
>> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 96 bytes
>> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 96 bytes
>> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 96 bytes
>> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 96 bytes
>> b43-phy0 ERROR: PHY transmission error
>> b43-phy0 ERROR: PHY transmission error
>> b43-phy0 ERROR: PHY transmission error
>> b43-phy0 ERROR: PHY transmission error
>> b43-phy0 ERROR: PHY transmission error
>
> This gave me some hint, may be very important. I would like you to
> test two patches (together, both at same time), TX header related.
> Unfortunately second one doesn't exist yet and I'm leaving for my
> studies class soon. I'll send you patches later today.
Please, apply that two patches. First one:
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=3311abbbbff1719bbbc8208761e4a75f095f383c
Second one is the one I attached.
You can revert your switching to PIO and debugging messages if you
wish. That doesn't matter.
My idea of what is happening:
1) We try to use newer firmware which does not forgive us broken TX
header anymore
2) Radio does not transmit, or transmits rubbishes
3) mac80211 detects failure of transmitting and hits some allocation
loop, memory leak
If that patches help, it means we satisfied newer firmware and TX
transmission goes fine. However there still probably is some alloc bug
in mac80211 that was exposed by b43.
--
Rafa?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lp.tx.ctl1.patch
Type: application/octet-stream
Size: 917 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110303/6e7792df/attachment.obj>
^ permalink raw reply
* [Buildroot] buildroot version from year 2007
From: zergman at gmx.de @ 2011-03-03 11:50 UTC (permalink / raw)
To: buildroot
Hi,
is there a way to get an old version of the buildroot tool?
To fix a bug in an really old project, I need a toolchain for the ARM platform with
gcc-4.0.3
binutils-2.16.1
uClibc-0.9.28
Unfortunately, the current releases of buildroot, do not support this versions anymore, and the download page goes only until 2009. If I remember correctly, the version I used was from 2007.
Thanks in advance
Karsten Planert
PS: the reason why I'm asking: the first time you know, whether your backups are good, is the point you need it. :-(
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone
^ permalink raw reply
* scheduling - more doubts
From: sudheer.divakaran at wipro.com @ 2011-03-03 11:50 UTC (permalink / raw)
To: kernelnewbies
Hi,
I had asked a similar question before, but I've some doubts regarding the correctness of the following code. Please see the following code snippet from the file linux-2.6.37/arch/x86/kernel/apm_32.c. This is the core function of apm thread.
Question:
Suppose the apm thread has just completed execution of the line 1442 and the scheduling happens for some reason, AFAIK, since the apm thread's state has been set to TASK_INTERRUPTIBLE, it will be removed from the run-queue. So there is a chance for the apm thread to remain suspended indefinitely as nobody is there to wakeup the apm thread, correct?
I'm asking this because the same function has been given as an example in the following link and would like to confirm the accuracy of the example.
http://www.linuxjournal.com/node/8144/print
1437 static void apm_mainloop(void)
1438 {
1439 DECLARE_WAITQUEUE(wait, current);
1440
1441 add_wait_queue(&apm_waitqueue, &wait);
1442 set_current_state(TASK_INTERRUPTIBLE);
1443 for (;;) {
1444 schedule_timeout(APM_CHECK_TIMEOUT);
1445 if (kthread_should_stop())
1446 break;
1447 /*
1448 * Ok, check all events, check for idle (and mark us sleeping
1449 * so as not to count towards the load average)..
1450 */
1451 set_current_state(TASK_INTERRUPTIBLE);
1452 apm_event_handler();
1453 }
1454 remove_wait_queue(&apm_waitqueue, &wait);
1455 }
--
Thanks,
Sudheer
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110303/4de626d8/attachment-0001.html
^ permalink raw reply
* Re: [RFC] snapshot mode, flash capabilities and control
From: Laurent Pinchart @ 2011-03-03 11:50 UTC (permalink / raw)
To: Andy Walls
Cc: Hans Verkuil, Guennadi Liakhovetski, Hans Verkuil,
Sylwester Nawrocki, Sakari Ailus, Kim HeungJun,
Linux Media Mailing List, Stanimir Varbanov
In-Reply-To: <1299114300.22292.21.camel@localhost>
Hi Andy,
On Thursday 03 March 2011 02:05:00 Andy Walls wrote:
> On Wed, 2011-03-02 at 19:19 +0100, Hans Verkuil wrote:
> > On Wednesday, March 02, 2011 18:51:43 Guennadi Liakhovetski wrote:
> > > ...Just occurred to me:
> > >
> > > On Mon, 28 Feb 2011, Guennadi Liakhovetski wrote:
> > > > On Mon, 28 Feb 2011, Guennadi Liakhovetski wrote:
> > > > > On Mon, 28 Feb 2011, Hans Verkuil wrote:
> > > > >
> > > > > These are not the features, that we _have_ to implement, these are
> > > > > just the ones, that are related to the snapshot mode:
> > > > >
> > > > > * flash strobe (provided, we do not want to control its timing from
> > > > >
> > > > > generic controls, and leave that to "reasonable defaults" or to
> > > > > private controls)
>
> I consider a flash strobe to be an illuminator. I modifies the subject
> matter to be captured in the image.
>
> > > Wouldn't it be a good idea to also export an LED (drivers/leds/) API
> > > from our flash implementation? At least for applications like torch.
> > > Downside: the LED API itself is not advanced enough for all our uses,
> > > and exporting two interfaces to the same device is usually a bad idea.
> > > Still, conceptually it seems to be a good fit.
> >
> > I believe we discussed LEDs before (during a discussion about adding
> > illuminator controls). I think the preference was to export LEDs as V4L
> > controls.
>
> That is certainly my preference, especially for LED's integrated into
> what the end user considers a discrete, consumer electronics device:
> e.g. a USB connected webcam or microscope.
>
> I cannot imagine a real use-case repurposing the flash strobe of a
> camera purposes other than subject matter illumination. (Inducing
> seizures? An intrusion detection systems alarm that doesn't use the
> camera to which the flash is connected?)
>
> For laptop frame integrated webcam LEDs, I can understand the desire to
> perhaps co-opt the LED for some other indicator purpose. A WLAN NIC
> traffic indicator was suggested previously.
>
> Does anyone know of any example where it could possibly make sense to
> repurpose the LED of a discrete external camera or capture device for
> some indication other than the camera/capture function? (I consider
> both extisngishing the LED for lighting purposes, and manipulating the
> LED for the purpose of deception of the actual state of the
> camera/capture function, still related to the camera function.)
What about using the flash LED on a cellphone as a torch ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCHv1] ARM: imx: Add support for low power suspend on MX51.
From: Uwe Kleine-König @ 2011-03-03 11:49 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux, Dinh.Nguyen, s.hauer, linux-kernel, xiao-lizhang,
linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1103031140330.2701@localhost6.localdomain6>
Hello Thomas,
On Thu, Mar 03, 2011 at 12:02:15PM +0100, Thomas Gleixner wrote:
> On Thu, 3 Mar 2011, Uwe Kleine-König wrote:
> > On Thu, Mar 03, 2011 at 12:51:32AM +0100, Thomas Gleixner wrote:
> > > > > +static int __init mx5_pm_init(void)
> > > > I'd prefer to have that called by imx51_init_early.
> > >
> > > And the reason is?
> > >
> > > 1) your personal preference
> > > 2) there is some useful technical reason
> > >
> > > If #1, then this comment was just waste of electrons
> > > If #2, you failed to provide some reasonable explanation
> > Actually it's #2, and to quote a different review[1]:
> >
> > Reviewers hint to a correct solution and you are supposed to
> > lookup what that solution means and act accordingly. If you do
> > not understand the hint or its implications please ask [...]
>
> I said the above when I hinted to use DEFINE_SPINLOCK(lock) instead of
> static spinlock_t lock. And that requires to lookup what
> DEFINE_SPINLOCK() actually does, which is a reasonable request.
>
> How is the author of that code supposed to figure out what the merit
> of s/mx5_pm_init/imx51_init_early/ is? By looking up your preferences
> in google or what?
Note I didn't suggest to change the function name.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCHv1] ARM: imx: Add support for low power suspend on MX51.
From: Uwe Kleine-König @ 2011-03-03 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1103031140330.2701@localhost6.localdomain6>
Hello Thomas,
On Thu, Mar 03, 2011 at 12:02:15PM +0100, Thomas Gleixner wrote:
> On Thu, 3 Mar 2011, Uwe Kleine-K?nig wrote:
> > On Thu, Mar 03, 2011 at 12:51:32AM +0100, Thomas Gleixner wrote:
> > > > > +static int __init mx5_pm_init(void)
> > > > I'd prefer to have that called by imx51_init_early.
> > >
> > > And the reason is?
> > >
> > > 1) your personal preference
> > > 2) there is some useful technical reason
> > >
> > > If #1, then this comment was just waste of electrons
> > > If #2, you failed to provide some reasonable explanation
> > Actually it's #2, and to quote a different review[1]:
> >
> > Reviewers hint to a correct solution and you are supposed to
> > lookup what that solution means and act accordingly. If you do
> > not understand the hint or its implications please ask [...]
>
> I said the above when I hinted to use DEFINE_SPINLOCK(lock) instead of
> static spinlock_t lock. And that requires to lookup what
> DEFINE_SPINLOCK() actually does, which is a reasonable request.
>
> How is the author of that code supposed to figure out what the merit
> of s/mx5_pm_init/imx51_init_early/ is? By looking up your preferences
> in google or what?
Note I didn't suggest to change the function name.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [ kvm-Bugs-2962575 ] MINIX 3.1.6 works in QEMU-0.12.3 only with KVM disabled
From: SourceForge.net @ 2011-03-03 11:46 UTC (permalink / raw)
To: noreply
Bugs item #2962575, was opened at 2010-03-03 13:20
Message generated for change (Comment added) made by jessorensen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2962575&group_id=180599
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: intel
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Erik van der Kouwe (erikvdk)
Assigned to: Nobody/Anonymous (nobody)
Summary: MINIX 3.1.6 works in QEMU-0.12.3 only with KVM disabled
Initial Comment:
Dear all,
If one runs the following commands after installing qemu-0.12.3 or qemu-kvm-0.12.3:
wget http://www.minix3.org/download/minix_R3.1.6-r6084.iso.bz2
bunzip2 minix_R3.1.6-r6084.iso.bz2
qemu-system-x86_64 -cdrom minix_R3.1.6-r6084.iso -enable-kvm
and presses 1 (Regular MINIX 3), the following error message results when loading MINIX:
kvm: unhandled exit 80000021
kvm_run returned -22
The guest stops after that.
This error message does not occur without the -enable-kvm switch. It does not occur with qemu-kvm-0.11.0 as bundled with Ubuntu. The problem occurs with the "qemu" binary from qemu-0.12.3 as well as "qemu-system-x86_64" from qemu-kvm-0.12.3, but in the former case no error message is printed.
The code that is running when it fails is in https://gforge.cs.vu.nl/gf/project/minix/scmsvn/?action=browse&path=%2Ftrunk%2Fsrc%2Fboot%2Fboothead.s&revision=5918&view=markup. It happens in ext_copy:
ext_copy:
mov x_dst_desc+2, ax
movb x_dst_desc+4, dl ! Set base of destination segment
mov ax, 8(bp)
mov dx, 10(bp)
mov x_src_desc+2, ax
movb x_src_desc+4, dl ! Set base of source segment
mov si, #x_gdt ! es:si = global descriptor table
shr cx, #1 ! Words to move
movb ah, #0x87 ! Code for extended memory move
int 0x15
The line that fails is "int 0x15", which performs a BIOS call to copy data from low memory to above the 1MB barrier. The machine is running in 16-bit real mode when this code is executed.
Output for "uname -a" on the host:
Linux hp364 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:05:19 UTC 2010 i686 GNU/Linux
Output for "cat /proc/cpuinfo" on the host:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8600 @ 3.33GHz
stepping : 10
cpu MHz : 1998.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips : 6650.50
clflush size : 64
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8600 @ 3.33GHz
stepping : 10
cpu MHz : 1998.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips : 6649.80
clflush size : 64
power management:
With kind regards,
Erik
----------------------------------------------------------------------
>Comment By: Jes Sorensen (jessorensen)
Date: 2011-03-03 12:46
Message:
Checked exact command and works fine with current QEMU on a Fedora 14
system. Looks
to be fixed, so closing.
----------------------------------------------------------------------
Comment By: Erik van der Kouwe (erikvdk)
Date: 2010-03-10 15:16
Message:
Thanks to Avi Kivity I now have a workaround for this issue, namely
16-byte
align the addresses in the GDT passed to the BIOS extended copy function.
The BIOS left the unaligned descriptor causing MINIX to operate in unreal
mode, which is not well supported by KVM on Intel.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2962575&group_id=180599
^ permalink raw reply
* Re: [PATCH V3 05/10] MIPS: lantiq: add watchdog support
From: Sergei Shtylyov @ 2011-03-03 11:44 UTC (permalink / raw)
To: John Crispin
Cc: Ralf Baechle, Ralph Hempel, Wim Van Sebroeck, linux-mips,
linux-watchdog
In-Reply-To: <1299146626-17428-6-git-send-email-blogic@openwrt.org>
Hello.
On 03-03-2011 13:03, John Crispin wrote:
> This patch adds the driver for the watchdog found inside the Lantiq SoC family.
> Signed-off-by: John Crispin<blogic@openwrt.org>
> Signed-off-by: Ralph Hempel<ralph.hempel@lantiq.com>
> Cc: Wim Van Sebroeck<wim@iguana.be>
> Cc: linux-mips@linux-mips.org
> Cc: linux-watchdog@vger.kernel.org
[...]
> diff --git a/drivers/watchdog/lantiq_wdt.c b/drivers/watchdog/lantiq_wdt.c
> new file mode 100644
> index 0000000..d49ddaa
> --- /dev/null
> +++ b/drivers/watchdog/lantiq_wdt.c
> @@ -0,0 +1,235 @@
[...]
> +static void
> +ltq_wdt_disable(void)
> +{
> +#ifndef CONFIG_WATCHDOG_NOWAYOUT
> + ltq_wdt_ok_to_close = 0;
> +#endif
> + /* write the first paswword magic */
^
You still didn't fix the typo here. :-)
> + ltq_w32(LTQ_WDT_PW1, ltq_wdt_membase + LTQ_WDT_CR);
> + /* write the second paswword magic with no config
^
And here...
> +static int
> +ltq_wdt_probe(struct platform_device *pdev)
Should be __init now that you're using platform_driver_probe()...
> + /* we do not need to enable the clock as it is always running */
> + clk = clk_get(&pdev->dev, "io");
> + if (!clk)
> + BUG();
BUG_ON(!clk);
> +static struct platform_driver ltq_wdt_driver = {
> + .probe = ltq_wdt_probe,
No need to initialize it now that you're using platform_driver_probe()...
> + .remove = ltq_wdt_remove,
Shouldn't 'ltq_wdt_remove' be enclosed in __exit_p()?
WBR, Sergei
^ permalink raw reply
* Re: bonding...
From: Neil Horman @ 2011-03-03 11:45 UTC (permalink / raw)
To: David Miller; +Cc: fubar, netdev
In-Reply-To: <20110302.214910.112578818.davem@davemloft.net>
On Wed, Mar 02, 2011 at 09:49:10PM -0800, David Miller wrote:
>
> Hey, if someone could step up and help with bonding maintainence
> in some tangible way, I'd really appreciate it.
>
> Currently the situation is that many people work on bonding patches,
> and whilst I do try and wait for some ACKs to arrive, I am the person
> who has to sort out when changes are ready, decide to apply them, and
> poke for review when things fall through the cracks.
>
> Sometimes patches go for weeks without ACKs, and in that situation
> I have to either try to understand the changes myself, or wait
> potentially forever for someone with bonding knowledge to take a
> good look at the patch and properly review it.
>
> It was nearly 2 weeks before Oleg V. Ukhno's 802.3ad round-robin patch
> got looked at by anyone with bonding knowledge. And it only happened
> because I got tired of seeing his poor patch rot in patchwork
> and had to explicitly asked for review the other day.
>
> This is unacceptable, people are submitting multiple bonding patches
> every single day now. It needs a clueful bonding person looking at
> these submissions on a constant basis.
>
> This is a serious problem and is backlogging the netdev patch queue.
>
> So if someone would become an active bonding patch-accumulator, and
> send me sets of patches that are ready to apply, I would really
> appreciate it.
>
> Thanks.
I nominate gospo. If he doesn't want to, I can do it
Neil
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Xen not running the pmtimer's timer on VCPUs different from VCPU#0
From: Paolo Bonzini @ 2011-03-03 11:45 UTC (permalink / raw)
To: xen-devel; +Cc: keir.fraser, kouya
Hi,
in order to support kdump/kexec on multiprocessor HVM guests, the patch at
http://xenbits.xensource.com/xen-unstable.hg/rev/19907 was committed.
The patch migrates all timers (via the pt infrastructure) to a VCPU whose
LAPIC is configured to receive the legacy 8259 interrupts.
In doing this, however, the pmtimer is left out. Its timer won't ever
move away from VCPU#0. Is there a reason for this, or is it just an
oversight?
Thanks in advance,
Paolo
^ permalink raw reply
* [PATCH] ste: enable multiple oFono runs without restarting the oFono
From: Jussi Kangas @ 2011-03-03 11:45 UTC (permalink / raw)
To: ofono
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
---
Hi,
This enables SIM detection in workstation after disabling and enabling the
modem without rebooting the oFono.
Br,
Jussi
plugins/ste.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/plugins/ste.c b/plugins/ste.c
index b786571..d2a6cc1 100644
--- a/plugins/ste.c
+++ b/plugins/ste.c
@@ -184,6 +184,7 @@ static gboolean init_sim_reporting(gpointer user_data)
{
struct ofono_modem *modem = user_data;
struct ste_data *data = ofono_modem_get_data(modem);
+ data->have_sim = FALSE;
g_at_chat_send(data->chat, "AT*ESIMSR=1;*ESIMSR?", NULL,
handle_sim_state,
--
1.7.1
^ permalink raw reply related
* [ kvm-Bugs-2914397 ] Virtio drivers for Windows - large volumes fail
From: SourceForge.net @ 2011-03-03 11:42 UTC (permalink / raw)
To: noreply
Bugs item #2914397, was opened at 2009-12-14 22:06
Message generated for change (Comment added) made by jessorensen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2914397&group_id=180599
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Brian Jackson (iggy_cav)
Assigned to: Nobody/Anonymous (nobody)
Summary: Virtio drivers for Windows - large volumes fail
Initial Comment:
When passing a 3T volume to a Windows 2008 guest using virtio drivers, the guest is unable to properly initialize the drive.
Windows logs the following error:
VDS fails to write boot code on a disk during clean operation. Error code: 80070013@02070008
It works correctly when using IDE emulation.
This occurs with self built drivers from a checkout on Dec. 8
Host:
Xeon 5130
Volumes are attached via iSCSI
Guest:
Windows 2008R2 64bit
kvm -smp 2 -m 2000 -name p3hq-share01 -drive file=/dev/mapper/SPIVOT3__RAIGE_VOLUME___600176c3547ddd11a18e92c748d535e6,cache=none -drive file=/dev/mapper/SPIVOT3__RAIGE_VOLUME___600176c3851660644b72bd9548d535e6,cache=none,if=virtio -net nic,macaddr=52:54:00:41:86:28,vlan=0,model=virtio -net tap,vlan=0,script=/etc/kvm/kvm-ifup -usb -vnc :0 -vga std -daemonize
----------------------------------------------------------------------
>Comment By: Jes Sorensen (jessorensen)
Date: 2011-03-03 12:42
Message:
No reply to suggestion of 2010-11-26, so assuming fixed.
----------------------------------------------------------------------
Comment By: Jes Sorensen (jessorensen)
Date: 2010-11-26 13:06
Message:
Make sure you have the latest virtio-win drivers from:
http://www.linux-kvm.com/content/latest-windows-virtio-drivers
If this still fails, please open a bug in launchpad.
Thanks,
Jes
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2914397&group_id=180599
^ permalink raw reply
* Re: [PATCH] Make explicit message when guest failed to suspend
From: Ian Campbell @ 2011-03-03 11:41 UTC (permalink / raw)
To: Frank Pan
Cc: Ian Jackson, xen-devel@lists.xensource.com, Jeremy, Fitzhardinge,
Stefano Stabellini
In-Reply-To: <AANLkTin2chB-nfrxk1H98qq=93zG2wo24O5-5ds5kYsn@mail.gmail.com>
On Thu, 2011-03-03 at 11:22 +0000, Frank Pan wrote:
> > This is a bug in Xend, it should never enter an infinite loop regardless
> > of guest behaviour. The code certainly appears to expect to be managing
> > a timeout, perhaps it has bitrotted?
> >
> > I don't think you can change the xenbus protocol in this way without
> > further rationale regarding it's correctness.
> >
> > Perhaps a separate control/shutdown-error key? The message written
> > should be more verbose than just "failed" if/when more specific
> > information is available to the kernel.
>
> FP: Maybe I should seperate it into 2 patches? One for bug fixing, the
> other for new protocol?
The patch to xend should be separate in any case -- since the kernel and
xend live in different trees.
also if you are changing the protocol you need to implement it for
libxl/xl as well. so you actually need (are least) two series:
xen-unstable.hg 1/2 -- xend bugfix
xen-unstable.hg 2/2 -- xend+libxl/xl side of protocol change
kernel 1/1 -- protocol change
etc.
>
> > In particular you need to consider and explain how it remains compatible
> > with a new kernel running on older toolstacks and vice versa.
> >
>
> FP: Right. This is something I haven't considered yet.
>
^ permalink raw reply
* Re: [PATCH] sctp: fix the fast retransmit limit
From: Neil Horman @ 2011-03-03 11:41 UTC (permalink / raw)
To: Wei Yongjun
Cc: David Miller, Vlad Yasevich, netdev@vger.kernel.org, lksctp,
Mingyuan Zhu
In-Reply-To: <4D6F5F83.705@cn.fujitsu.com>
On Thu, Mar 03, 2011 at 05:29:39PM +0800, Wei Yongjun wrote:
> If chunk is still lost after fast retransmit, SCTP stack will
> never allow the second fast retransmit of this chunk, even if
> the peer need we do this. This chunk will be retransmit until
> the rtx timeout. This limit is introduce by the following patch:
> sctp: reduce memory footprint of sctp_chunk structure
> (c226ef9b83694311327f3ab0036c6de9c22e9daf)
>
> This patch revert this limit and removed useless SCTP_DONT_FRTX.
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
> ---
> include/net/sctp/structs.h | 1 -
> net/sctp/outqueue.c | 4 ++--
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index cc9185c..82a0f84 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -751,7 +751,6 @@ struct sctp_chunk {
>
> #define SCTP_CAN_FRTX 0x0
> #define SCTP_NEED_FRTX 0x1
> -#define SCTP_DONT_FRTX 0x2
> __u16 rtt_in_progress:1, /* This chunk used for RTT calc? */
> has_tsn:1, /* Does this chunk have a TSN yet? */
> has_ssn:1, /* Does this chunk have a SSN yet? */
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index 8c6d379..7ed5862 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -657,7 +657,7 @@ redo:
> * after it is retransmitted.
> */
> if (chunk->fast_retransmit == SCTP_NEED_FRTX)
> - chunk->fast_retransmit = SCTP_DONT_FRTX;
> + chunk->fast_retransmit = SCTP_CAN_FRTX;
>
> q->empty = 0;
> break;
> @@ -679,7 +679,7 @@ redo:
> if (rtx_timeout || fast_rtx) {
> list_for_each_entry(chunk1, lqueue, transmitted_list) {
> if (chunk1->fast_retransmit == SCTP_NEED_FRTX)
> - chunk1->fast_retransmit = SCTP_DONT_FRTX;
> + chunk1->fast_retransmit = SCTP_CAN_FRTX;
> }
> }
>
> --
> 1.6.5.2
>
>
>
^ permalink raw reply
* Re: [PATCH] sctp: fix the fast retransmit limit
From: Neil Horman @ 2011-03-03 11:41 UTC (permalink / raw)
To: Wei Yongjun
Cc: David Miller, Vlad Yasevich, netdev@vger.kernel.org, lksctp,
Mingyuan Zhu
In-Reply-To: <4D6F5F83.705@cn.fujitsu.com>
On Thu, Mar 03, 2011 at 05:29:39PM +0800, Wei Yongjun wrote:
> If chunk is still lost after fast retransmit, SCTP stack will
> never allow the second fast retransmit of this chunk, even if
> the peer need we do this. This chunk will be retransmit until
> the rtx timeout. This limit is introduce by the following patch:
> sctp: reduce memory footprint of sctp_chunk structure
> (c226ef9b83694311327f3ab0036c6de9c22e9daf)
>
> This patch revert this limit and removed useless SCTP_DONT_FRTX.
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
> ---
> include/net/sctp/structs.h | 1 -
> net/sctp/outqueue.c | 4 ++--
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index cc9185c..82a0f84 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -751,7 +751,6 @@ struct sctp_chunk {
>
> #define SCTP_CAN_FRTX 0x0
> #define SCTP_NEED_FRTX 0x1
> -#define SCTP_DONT_FRTX 0x2
> __u16 rtt_in_progress:1, /* This chunk used for RTT calc? */
> has_tsn:1, /* Does this chunk have a TSN yet? */
> has_ssn:1, /* Does this chunk have a SSN yet? */
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index 8c6d379..7ed5862 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -657,7 +657,7 @@ redo:
> * after it is retransmitted.
> */
> if (chunk->fast_retransmit = SCTP_NEED_FRTX)
> - chunk->fast_retransmit = SCTP_DONT_FRTX;
> + chunk->fast_retransmit = SCTP_CAN_FRTX;
>
> q->empty = 0;
> break;
> @@ -679,7 +679,7 @@ redo:
> if (rtx_timeout || fast_rtx) {
> list_for_each_entry(chunk1, lqueue, transmitted_list) {
> if (chunk1->fast_retransmit = SCTP_NEED_FRTX)
> - chunk1->fast_retransmit = SCTP_DONT_FRTX;
> + chunk1->fast_retransmit = SCTP_CAN_FRTX;
> }
> }
>
> --
> 1.6.5.2
>
>
>
^ permalink raw reply
* Re: [PATCH] procfs: fix /proc/<pid>/maps heap check
From: Aaro Koskinen @ 2011-03-03 11:37 UTC (permalink / raw)
To: KOSAKI Motohiro; +Cc: Aaro Koskinen, linux-mm, linux-kernel, akpm, stable
In-Reply-To: <20110303102631.B939.A69D9226@jp.fujitsu.com>
Hi,
On Thu, 3 Mar 2011, KOSAKI Motohiro wrote:
>> On Tue, 1 Mar 2011, Aaro Koskinen wrote:
>>> The current check looks wrong and prints "[heap]" only if the mapping
>>> matches exactly the heap. However, the heap may be merged with some
>>> other mappings, and there may be also be multiple mappings.
>>>
>>> Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
>>> Cc: stable@kernel.org
[...]
> Your description said,
> the heap may be merged with some other mappings,
> ^^^^^^
> but your example is splitting case. not merge. In other words, your
> patch care splitting case but break merge case.
>
> Ok, we have no obvious correct behavior. This is debatable. So,
> Why do you think vma splitting case is important than merge?
Sorry, I was unclear.
The current behaviour is wrong for both merged and split cases, and I
think the patch fixes both.
And yes, the example program is for the split case. I'll see if I can
make a test program for the merged case...
A.
^ permalink raw reply
* Re: [PATCH] procfs: fix /proc/<pid>/maps heap check
From: Aaro Koskinen @ 2011-03-03 11:37 UTC (permalink / raw)
To: KOSAKI Motohiro; +Cc: Aaro Koskinen, linux-mm, linux-kernel, akpm, stable
In-Reply-To: <20110303102631.B939.A69D9226@jp.fujitsu.com>
Hi,
On Thu, 3 Mar 2011, KOSAKI Motohiro wrote:
>> On Tue, 1 Mar 2011, Aaro Koskinen wrote:
>>> The current check looks wrong and prints "[heap]" only if the mapping
>>> matches exactly the heap. However, the heap may be merged with some
>>> other mappings, and there may be also be multiple mappings.
>>>
>>> Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
>>> Cc: stable@kernel.org
[...]
> Your description said,
> the heap may be merged with some other mappings,
> ^^^^^^
> but your example is splitting case. not merge. In other words, your
> patch care splitting case but break merge case.
>
> Ok, we have no obvious correct behavior. This is debatable. So,
> Why do you think vma splitting case is important than merge?
Sorry, I was unclear.
The current behaviour is wrong for both merged and split cases, and I
think the patch fixes both.
And yes, the example program is for the split case. I'll see if I can
make a test program for the merged case...
A.
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [ kvm-Bugs-2729621 ] usb_add on garmin gps fails
From: SourceForge.net @ 2011-03-03 11:39 UTC (permalink / raw)
To: noreply
Bugs item #2729621, was opened at 2009-04-04 05:02
Message generated for change (Comment added) made by jessorensen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2729621&group_id=180599
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: qemu
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Byron Clark (byron_clark)
Assigned to: Nobody/Anonymous (nobody)
Summary: usb_add on garmin gps fails
Initial Comment:
When I attempt to usb_add my Garmin Venture HC GPS with this command:
usb_add host:091e:0003
I get the following error:
usb_linux_update_endp_table: Broken pipe
strace log:
write(1, "husb: open device 5.3\n", 22) = 22
open("/proc/bus/usb/005/003", O_RDWR|O_NONBLOCK) = 26
read(26, "\22\1\20\1\377\377\377@\36\t\3\0\1\0\0\0\0\1\t\2'\0\1\1\0\300\0\t\4\0\0\3"..., 1024) = 57
write(1, "husb: config #1 need -1\n", 24) = 24
ioctl(26, USBDEVFS_IOCTL, 0x7fff0bb74300) = -1 ENODATA (No data available)
ioctl(26, USBDEVFS_CLAIMINTERFACE, 0x7fff0bb7431c) = 0
write(1, "husb: 1 interfaces claimed for c"..., 47) = 47
ioctl(26, USBDEVFS_CONNECTINFO, 0x7fff0bb74750) = 0
write(1, "husb: grabbed usb device 5.3\n", 29) = 29
ioctl(26, USBDEVFS_CONTROL, 0x7fff0bb742f0) = -1 EPIPE (Broken pipe)
dup(2) = 27
fcntl(27, F_GETFL) = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
fstat(27, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 9), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4e03b67000
lseek(27, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(27, "usb_linux_update_endp_table: Bro"..., 41) = 41
close(27) = 0
cpu:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz
stepping : 11
cpu MHz : 2194.427
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida tpr_shadow vnmi flexpriority
bogomips : 4388.85
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
host distribution: debian sid
bitness: 64
guest distribution: windows xp
bitness: 32
----------------------------------------------------------------------
>Comment By: Jes Sorensen (jessorensen)
Date: 2011-03-03 12:39
Message:
Last comment is a bit unclear - can you confirm that this actually works?
Thanks,
Jes
----------------------------------------------------------------------
Comment By: Nicholas J Kreucher (kreucher)
Date: 2009-12-03 20:18
Message:
Scratch the hal comment... it actually works perfectly :)
----------------------------------------------------------------------
Comment By: Nicholas J Kreucher (kreucher)
Date: 2009-12-03 20:05
Message:
Perhaps this is a usb serial device? Seems there is a workaround for such
devices here:
http://ubuntuforums.org/archive/index.php/t-910796.html
See IntuitiveNipple's Sep 7th post. The patch worked for me (sort of, the
guest device now exists and works, but the hal properties don't seem to be
populated correctly).
----------------------------------------------------------------------
Comment By: Byron Clark (byron_clark)
Date: 2009-04-04 05:08
Message:
kvm-84, kernel 2.6.29.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2729621&group_id=180599
^ permalink raw reply
* [PATCH v2] staging: keucr: use kernel byteorder functions
From: Jonathan Neuschäfer @ 2011-03-03 11:38 UTC (permalink / raw)
To: Jack Stone
Cc: Greg Kroah-Hartman, Al Cho, devel, linux-kernel,
Jonathan Neuschäfer
In-Reply-To: <20110303113225.GA1341@debian.debian>
---
drivers/staging/keucr/TODO | 1 -
drivers/staging/keucr/common.h | 12 ------------
drivers/staging/keucr/ms.c | 28 +++++++++++++++-------------
3 files changed, 15 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/keucr/TODO b/drivers/staging/keucr/TODO
index 179b7fe..1c48e40 100644
--- a/drivers/staging/keucr/TODO
+++ b/drivers/staging/keucr/TODO
@@ -6,7 +6,6 @@ TODO:
be merged into the drivers/usb/storage/ directory and
infrastructure instead.
- review by the USB developer community
- - common.h: use kernel swap, le, & be functions
- smcommon.h & smilsub.c: use kernel hweight8(), hweight16()
Please send any patches for this driver to Al Cho <acho@novell.com> and
diff --git a/drivers/staging/keucr/common.h b/drivers/staging/keucr/common.h
index f2be045..b87dc7a 100644
--- a/drivers/staging/keucr/common.h
+++ b/drivers/staging/keucr/common.h
@@ -9,17 +9,5 @@ typedef u16 *PWORD;
typedef u32 DWORD;
typedef u32 *PDWORD;
-#define swapWORD(w) ((((unsigned short)(w) << 8) & 0xff00) | \
- (((unsigned short)(w) >> 8) & 0x00ff))
-#define swapDWORD(dw) ((((unsigned long)(dw) << 24) & 0xff000000) | \
- (((unsigned long)(dw) << 8) & 0x00ff0000) | \
- (((unsigned long)(dw) >> 8) & 0x0000ff00) | \
- (((unsigned long)(dw) >> 24) & 0x000000ff))
-
-#define LittleEndianWORD(w) (w)
-#define LittleEndianDWORD(dw) (dw)
-#define BigEndianWORD(w) swapWORD(w)
-#define BigEndianDWORD(dw) swapDWORD(dw)
-
#endif
diff --git a/drivers/staging/keucr/ms.c b/drivers/staging/keucr/ms.c
index 452ea8f..48496e4 100644
--- a/drivers/staging/keucr/ms.c
+++ b/drivers/staging/keucr/ms.c
@@ -1,4 +1,6 @@
#include <linux/slab.h>
+#include <asm/byteorder.h>
+
#include "usb.h"
#include "scsiglue.h"
#include "transport.h"
@@ -166,8 +168,8 @@ int MS_CardInit(struct us_data *us)
continue;
if (((extdat.mngflg & MS_REG_MNG_SYSFLG) == MS_REG_MNG_SYSFLG_USER) ||
- (BigEndianWORD(((MemStickBootBlockPage0 *)PageBuffer0)->header.wBlockID) != MS_BOOT_BLOCK_ID) ||
- (BigEndianWORD(((MemStickBootBlockPage0 *)PageBuffer0)->header.wFormatVersion) != MS_BOOT_BLOCK_FORMAT_VERSION) ||
+ (be16_to_cpu(((MemStickBootBlockPage0 *)PageBuffer0)->header.wBlockID) != MS_BOOT_BLOCK_ID) ||
+ (be16_to_cpu(((MemStickBootBlockPage0 *)PageBuffer0)->header.wFormatVersion) != MS_BOOT_BLOCK_FORMAT_VERSION) ||
(((MemStickBootBlockPage0 *)PageBuffer0)->header.bNumberOfDataEntry != MS_BOOT_BLOCK_DATA_ENTRIES))
continue;
@@ -266,7 +268,7 @@ int MS_LibCheckDisableBlock(struct us_data *us, WORD PhyBlock)
MS_ReaderReadPage(us, PhyBlock, 1, (DWORD *)PageBuf, &extdat);
do
{
- blk = BigEndianWORD(PageBuf[index]);
+ blk = be16_to_cpu(PageBuf[index]);
if (blk == MS_LB_NOT_USED)
break;
if (blk == us->MS_Lib.Log2PhyMap[0])
@@ -355,7 +357,7 @@ int MS_LibProcessBootBlock(struct us_data *us, WORD PhyBlock, BYTE *PageData)
SysInfo= &(((MemStickBootBlockPage0 *)PageData)->sysinf);
if ((SysInfo->bMsClass != MS_SYSINF_MSCLASS_TYPE_1) ||
- (BigEndianWORD(SysInfo->wPageSize) != MS_SYSINF_PAGE_SIZE) ||
+ (be16_to_cpu(SysInfo->wPageSize) != MS_SYSINF_PAGE_SIZE) ||
((SysInfo->bSecuritySupport & MS_SYSINF_SECURITY) == MS_SYSINF_SECURITY_SUPPORT) ||
(SysInfo->bReserved1 != MS_SYSINF_RESERVED1) ||
(SysInfo->bReserved2 != MS_SYSINF_RESERVED2) ||
@@ -376,12 +378,12 @@ int MS_LibProcessBootBlock(struct us_data *us, WORD PhyBlock, BYTE *PageData)
goto exit;
}
- us->MS_Lib.blockSize = BigEndianWORD(SysInfo->wBlockSize);
- us->MS_Lib.NumberOfPhyBlock = BigEndianWORD(SysInfo->wBlockNumber);
- us->MS_Lib.NumberOfLogBlock = BigEndianWORD(SysInfo->wTotalBlockNumber)- 2;
+ us->MS_Lib.blockSize = be16_to_cpu(SysInfo->wBlockSize);
+ us->MS_Lib.NumberOfPhyBlock = be16_to_cpu(SysInfo->wBlockNumber);
+ us->MS_Lib.NumberOfLogBlock = be16_to_cpu(SysInfo->wTotalBlockNumber) - 2;
us->MS_Lib.PagesPerBlock = us->MS_Lib.blockSize * SIZE_OF_KIRO / MS_BYTES_PER_PAGE;
us->MS_Lib.NumberOfSegment = us->MS_Lib.NumberOfPhyBlock / MS_PHYSICAL_BLOCKS_PER_SEGMENT;
- us->MS_Model = BigEndianWORD(SysInfo->wMemorySize);
+ us->MS_Model = be16_to_cpu(SysInfo->wMemorySize);
if (MS_LibAllocLogicalMap(us)) //Allocate to all number of logicalblock and physicalblock
goto exit;
@@ -394,10 +396,10 @@ int MS_LibProcessBootBlock(struct us_data *us, WORD PhyBlock, BYTE *PageData)
{
DWORD EntryOffset, EntrySize;
- if ((EntryOffset = BigEndianDWORD(SysEntry->entry[i].dwStart)) == 0xffffff)
+ if ((EntryOffset = be32_to_cpu(SysEntry->entry[i].dwStart)) == 0xffffff)
continue;
- if ((EntrySize = BigEndianDWORD(SysEntry->entry[i].dwSize)) == 0)
+ if ((EntrySize = be32_to_cpu(SysEntry->entry[i].dwSize)) == 0)
continue;
if (EntryOffset + MS_BYTES_PER_PAGE + EntrySize > us->MS_Lib.blockSize * (DWORD)SIZE_OF_KIRO)
@@ -429,7 +431,7 @@ int MS_LibProcessBootBlock(struct us_data *us, WORD PhyBlock, BYTE *PageData)
PrevPageNumber = PageNumber;
}
- if ((phyblk = BigEndianWORD(*(WORD *)(PageBuffer + (EntryOffset % MS_BYTES_PER_PAGE)))) < 0x0fff)
+ if ((phyblk = be16_to_cpu(*(WORD *)(PageBuffer + (EntryOffset % MS_BYTES_PER_PAGE)))) < 0x0fff)
MS_LibSetInitialErrorBlock(us, phyblk);
EntryOffset += 2;
@@ -455,10 +457,10 @@ int MS_LibProcessBootBlock(struct us_data *us, WORD PhyBlock, BYTE *PageData)
}
idi = &((MemStickBootBlockCIS_IDI *)(PageBuffer + (EntryOffset % MS_BYTES_PER_PAGE)))->idi.idi;
- if (LittleEndianWORD(idi->wIDIgeneralConfiguration) != MS_IDI_GENERAL_CONF)
+ if (le16_to_cpu(idi->wIDIgeneralConfiguration) != MS_IDI_GENERAL_CONF)
goto exit;
- us->MS_Lib.BytesPerSector = LittleEndianWORD(idi->wIDIbytesPerSector);
+ us->MS_Lib.BytesPerSector = le16_to_cpu(idi->wIDIbytesPerSector);
if (us->MS_Lib.BytesPerSector != MS_BYTES_PER_PAGE)
goto exit;
}
--
1.7.4.1
^ permalink raw reply related
* [Qemu-devel] Re: [V6 PATCH 4/9] virtio-9p: Add qemu side interfaces for chroot environment
From: Stefan Hajnoczi @ 2011-03-03 11:38 UTC (permalink / raw)
To: M. Mohan Kumar; +Cc: qemu-devel
In-Reply-To: <1298892156-11667-5-git-send-email-mohan@in.ibm.com>
On Mon, Feb 28, 2011 at 11:22 AM, M. Mohan Kumar <mohan@in.ibm.com> wrote:
> + retval = recvmsg(sockfd, &msg, 0);
> + if (retval < 0) {
> + *sock_error = 1;
> + return -EIO;
> + }
Are we guaranteed this will be called with signals blocked? Otherwise
we need to handle EINTR.
> + if (fd_info.fi_flags & FI_FD_SOCKERR) {
> + *sock_error = 1;
> + return -EIO;
> + }
> + /* If fd is invalid, ancillary data is not present */
> + if (fd_info.fi_fd < 0 || fd_info.fi_flags & FI_FD_INVALID) {
> + return fd_info.fi_fd;
> + }
Testing fd_info.fi_flags & FI_FD_INVALID looks dangerous to me. If
for some reason fi_fd >= 0 then we'd return success here. fd_fd < 0
should be a sufficient check, perhaps you wanted an assert() instead?
Stefan
^ 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.