Re: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2
On Wed, Dec 10, 2014 at 11:30:30PM +, KY Srinivasan wrote:
>
> > >
> > > + {"Msft", "Virtual Disk", "1.0", BLIST_TRY_VPD_PAGES},
> > >
> > > Is that version field meaningful or is it safe for us to inquire about
> > > VPD pages without problems on older versions?
> >
> > This version is used in all current Hyper-V hosts: Windows 2008 R2, 2012 and
> > 2012 R2. However it may change in future Windows releases.
>
> The next version of the host will be claiming conformance to SPC-3
Will the version number ("1.0") of Virtual Disks also be changed? Part
of me hopes it will as it will mean certain quirks for virtual disks
will be easier to apply and won't need host version (are you 2008, 2012,
2016) version logic...
--
Sitsofe | http://sucs.org/~sits/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v18 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support
Hi Daniel, Am Mittwoch, 10. Dezember 2014, 20:36:17 schrieb Daniel Kurtz: > This driver adds HDMI to rockchip/drm. The fact that rockchip's hdmi > uses dw_hdmi is an implementation detail. I do not think that the names > used for rk3288-hdmi should include "dw" in them. > > See inline for what I mean... I guess in general this is more a matter of preference. Past practices suggest that having the dw in the name is a sane solution too, like in dw_mmc-foo (mmc/host), dwmac-foo (net/ethernet/stmicro/stmmac). And personally I'd keep to this already established naming scheme ... i.e. not hiding the dw heritage. And also it looks like other involved parties like Philipp and Russell seemed to be ok with the naming through the revisions till now. [...] > > +static enum drm_mode_status > > +dw_hdmi_rockchip_mode_valid(struct drm_connector *connector, > > Similarly, I would rename these function names to start with > rockchip_hdmi (or maybe rk_hdmi for brevity). > Especially the ones for the module & driver: (bind/unbind/probe/remove). Please keep to one rk <-> rockchip style at least per subsystem. The core drm driver uses rockchip, so the hdmi driver should too (instead of rk). Heiko ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Fwd: improve support for usb board camera
The kernel version is 3.13.0-32-generic Here is one example: BUG: unable to handle kernel NULL pointer dereference at... IP: [...] xhci_stream_id_to_ring+0x40/0x60 PGD 362a1067 PUD c9f49067 PMD 0 Oops: [#1] SMP Modules linked in: elo_mt_input_mod(0F) eeepc_wmi ... CPU: 1 PID: 20665 Comm: ... Tainted: GF W 0 3.13.0-32-generic #57-Ubuntu Hardware name: ASUS All Series/B85M-E, BIOS 2105 08/08/2014 task: ... RIP: ... xhci_stream_id_to_ring+0x40/0x60 ... Call Trace: handle_cmd_completion xhci_irq xhci_mis_irq handle_irq_event_percpu handle_irq_event handle_edge_irq handle_irq do_IRQ common_interrupt ... Kernel panic - not syncing: Fatal exception in interrupt Shutting down cpus with MMI drm_kms_helper: panic occured, switching back to text console Thank you for your help and let me know if I should still contact the media mailing list. Kris On Wed, Dec 10, 2014 at 9:00 PM, Greg KH wrote: > On Wed, Dec 10, 2014 at 07:35:48PM -0500, Kristopher Borer wrote: >> Hello, >> >> I am looking to improve support for a USB board camera. It currently >> works fairly well, but we occasionally cause kernel panics while using >> OpenCV on Ubuntu 14.04. > > What kernel version is that, and what is the oops report show? > >> Here is the device: e-consystems.com/5mp-usb-cameraboard.asp >> >> We do not need an NDA. We can provide hardware, test scripts, and we >> have some internal engineers who can help out. > > You might do best by posting this on the linux-me...@vger.kernel.org > mailing list, as that is where the authors for that driver are, it might > just be a simple quirk or bugfix is needed to get this resolved. > > If that doesn't work out, please let me know. > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] Drivers: hv: balloon: Fix the deadlock issue in the memory hot-add code
On Thu 11-12-14 00:21:09, KY Srinivasan wrote: > > > > -Original Message- > > From: Michal Hocko [mailto:mho...@suse.cz] > > Sent: Tuesday, December 9, 2014 2:56 AM > > To: Yasuaki Ishimatsu > > Cc: KY Srinivasan; gre...@linuxfoundation.org; linux- > > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > > a...@canonical.com; linux...@kvack.org > > Subject: Re: [PATCH 2/2] Drivers: hv: balloon: Fix the deadlock issue in the > > memory hot-add code > > > > On Tue 09-12-14 19:25:50, Yasuaki Ishimatsu wrote: > > > (2014/12/09 18:08), Michal Hocko wrote: > > [...] > > > >Doesn't udev retry the operation if it gets EBUSY or EAGAIN? > > > > > > It depend on implementation of udev.rules. So we can retry > > > online/offline operation in udev.rules. > > [...] > > > > # Memory hotadd request > > SUBSYSTEM=="memory", ACTION=="add", > > DEVPATH=="/devices/system/memory/memory*[0-9]", > > TEST=="/sys$devpath/state", RUN+="/bin/sh -c 'echo online > > > /sys$devpath/state'" > > > > OK so this is not prepared for a temporary failures and retries. > > > > > >And again, why cannot we simply make the onlining fail or try_lock > > > >and retry internally if the event consumer cannot cope with errors? > > > > > > Did you mean the following Srinivasan's first patch looks good to you? > > > https://lkml.org/lkml/2014/12/2/662 > > > > Heh, I was just about to post this. Because I haven't noticed the previous > > patch yet. Yeah, Something like that. Except that I would expect EAGAIN or > > EBUSY rather than ERESTARTSYS which should never leak into userspace. And > > that would happen here AFAICS because signal_pending will not be true > > usually. > Michal, > > I agree that the fix to this problem must be outside the clients > of add_memory() and that is the reason I had sent that patch: > https://lkml.org/lkml/2014/12/2/662. Let me know if you want me to > resend this patch with the correct return value. Please think about the other suggested options as well. > Regards, > > K. Y > > > > So there are two options. Either make the udev rule more robust and retry > > within RUN section or do the retry withing online_pages (try_lock and go > > into > > interruptible sleep which gets signaled by finished add_memory()). The later > > option is safer wrt. the userspace because the operation wouldn't fail > > unexpectedly. > > Another option would be generating the sysfs file after all the internal > > initialization is done and call it outside of the memory hotplug lock. > > > > -- > > Michal Hocko > > SUSE Labs -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Fwd: improve support for usb board camera
On Thu, Dec 11, 2014 at 07:43:15AM -0500, Kristopher Borer wrote: > The kernel version is 3.13.0-32-generic Ick, that's 68 thousand patches old (i.e. one year...) Have you tried the 3.18 kernel release to see if it is better, because: > > Here is one example: > > BUG: unable to handle kernel NULL pointer dereference at... > IP: [...] xhci_stream_id_to_ring+0x40/0x60 > PGD 362a1067 PUD c9f49067 PMD 0 > Oops: [#1] SMP > Modules linked in: elo_mt_input_mod(0F) eeepc_wmi ... > CPU: 1 PID: 20665 Comm: ... Tainted: GF W 0 3.13.0-32-generic #57-Ubuntu > Hardware name: ASUS All Series/B85M-E, BIOS 2105 08/08/2014 > task: ... > RIP: ... xhci_stream_id_to_ring+0x40/0x60 > ... > Call Trace: > > handle_cmd_completion > xhci_irq > xhci_mis_irq > handle_irq_event_percpu > handle_irq_event > handle_edge_irq > handle_irq > do_IRQ > common_interrupt > > ... > Kernel panic - not syncing: Fatal exception in interrupt > Shutting down cpus with MMI That's a xhci (the USB 3 controller) issue, and there have been lots of xhci fixes in the past year as new controllers have been released and we have fixed the bugs in them. And you are using USB 3 streams in your USB 2 camera? That doesn't make sense. What camera driver is this? Anyway, please try 3.18, that should work. If not, let's drag this over to the linux-...@vger.kernel.org mailing list as the xhci developers should learn about this, it doesn't look like a media driver issue just yet. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: writeboost: Add dm-writeboost
On Wed, Dec 10 2014 at 6:42am -0500, Akira Hayakawa wrote: > This patch adds dm-writeboost to staging tree. > > dm-writeboost is a log-structured SSD-caching driver. > It caches data in log-structured way on the cache device > so that the performance is maximized. > > The merit of putting this driver in staging tree is > to make it possible to get more feedback from users > and polish the codes. > > Signed-off-by: Akira Hayakawa Joe Thornber Nacked this from going into staging based on his further review of the code. On the basis that you should _not_ be copying all pages associated with each bio into an in-core buffer. Have you addressed that fundamental problem? But taking a step back: Why do you think going into staging actually helps you? Anyone who is willing to test this code should be able to apply a patch to their kernel. Having to feed changes to Greg to deliver updates to any early consumers of this _EXPERIMENTAL_ target seems misplaced when you consider that Joe has detailed important fixes, capabilties and tools that need addressing before anyone should trust their production data to dm-writeboost. I think you're completely missing that you are pushing _hard_ for this target to go upstream before it is actually ready. In doing so you're so hung up on that "upstream" milestone that you cannot appreciate the reluctance that Joe and I have given the quantity of code you're pushing -- especially when coupled with the limited utility of dm-writeboost in comparison with full featured upstream drivers like dm-cache and bcache. As for this v2, you didn't detail what you changed (I can obviously apply v1 and then v2 to see the difference but a brief summary would be helpful in general when you revise a patch) But one inline comment: > diff --git a/drivers/staging/writeboost/TODO b/drivers/staging/writeboost/TODO > new file mode 100644 > index 000..761a9fe > --- /dev/null > +++ b/drivers/staging/writeboost/TODO > @@ -0,0 +1,52 @@ > +TODO: > + > +- Get the GitExtract test so it's performance is similar to raw spindle. No, the whole point of a write cache is to improve performance. You should be trying to surpass the performance of the raw spindle. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2
> -Original Message-
> From: Sitsofe Wheeler [mailto:sits...@gmail.com]
> Sent: Thursday, December 11, 2014 2:54 AM
> To: KY Srinivasan
> Cc: Long Li; Martin K. Petersen; Haiyang Zhang; jbottom...@parallels.com;
> linux-s...@vger.kernel.org; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2
>
> On Wed, Dec 10, 2014 at 11:30:30PM +, KY Srinivasan wrote:
> >
> > > >
> > > > + {"Msft", "Virtual Disk", "1.0", BLIST_TRY_VPD_PAGES},
> > > >
> > > > Is that version field meaningful or is it safe for us to inquire
> > > > about VPD pages without problems on older versions?
> > >
> > > This version is used in all current Hyper-V hosts: Windows 2008 R2,
> > > 2012 and
> > > 2012 R2. However it may change in future Windows releases.
> >
> > The next version of the host will be claiming conformance to SPC-3
>
> Will the version number ("1.0") of Virtual Disks also be changed? Part of me
> hopes it will as it will mean certain quirks for virtual disks will be easier
> to
> apply and won't need host version (are you 2008, 2012,
> 2016) version logic...
Spoke to the folks on Windows side of the house. They currently don't have
plans to
Change the version number ("1.0").
K. Y
>
> --
> Sitsofe | http://sucs.org/~sits/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH socfpga-nex] staging: fpga manager: socfpga_fpga_ops can be static
On Thu, 11 Dec 2014 09:43:24 +0800 kbuild test robot wrote: > drivers/staging/fpga/socfpga.c:655:25: sparse: symbol 'socfpga_fpga_ops' was > not declared. Should it be static? > > Signed-off-by: Fengguang Wu Ought to be const as well by the look of it - we don't want function pointers in patchable memory spaces. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723au: Fix sparse warnings
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
rtw_wlan_util.c:1546:25: warning: cast to restricted __le16
This patch changes declared types of the struct fields involved.
Signed-off-by: Krzysztof Konopko
---
drivers/staging/rtl8723au/include/wifi.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723au/include/wifi.h
b/drivers/staging/rtl8723au/include/wifi.h
index fd3da3b..8a2adc5 100644
--- a/drivers/staging/rtl8723au/include/wifi.h
+++ b/drivers/staging/rtl8723au/include/wifi.h
@@ -28,7 +28,7 @@
struct AC_param {
unsigned char ACI_AIFSN;
unsigned char CW;
- unsigned short TXOP_limit;
+ __le16 TXOP_limit;
} __packed;
struct WMM_para_element {
@@ -39,9 +39,9 @@ struct WMM_para_element {
struct ADDBA_request {
unsigned char dialog_token;
- unsigned short BA_para_set;
+ __le16 BA_para_set;
unsigned short BA_timeout_value;
- unsigned short BA_starting_seqctrl;
+ __le16 BA_starting_seqctrl;
} __packed;
--
2.1.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
On 12/11/2014 04:23 PM, Krzysztof Konopko wrote:
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
rtw_wlan_util.c:1546:25: warning: cast to restricted __le16
This patch changes declared types of the struct fields involved.
Signed-off-by: Krzysztof Konopko
---
drivers/staging/rtl8723au/include/wifi.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723au/include/wifi.h
b/drivers/staging/rtl8723au/include/wifi.h
index fd3da3b..8a2adc5 100644
--- a/drivers/staging/rtl8723au/include/wifi.h
+++ b/drivers/staging/rtl8723au/include/wifi.h
@@ -28,7 +28,7 @@
struct AC_param {
unsigned char ACI_AIFSN;
unsigned char CW;
- unsigned short TXOP_limit;
+ __le16 TXOP_limit;
} __packed;
struct WMM_para_element {
@@ -39,9 +39,9 @@ struct WMM_para_element {
struct ADDBA_request {
unsigned char dialog_token;
- unsigned short BA_para_set;
+ __le16 BA_para_set;
unsigned short BA_timeout_value;
- unsigned short BA_starting_seqctrl;
+ __le16 BA_starting_seqctrl;
} __packed;
This fix may make the sparse warnings go away, but I think it introduces new
bugs. In particular, did you test on big-endian hardware after you made this
change? I recently found that the driver for RTL8188EU needed to have
BA_para_set to unsigned short, and the endianess warnings needed to be fixed in
the code. Then it would work on my PowerBook G4 with a PPC processor.
In RTL8188EU, both BA_starting_seqctrl and TXOP_limit are unsigned short.
Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: writeboost: Add dm-writeboost
Mike, Below is my comments against Joe's previous comments: 1. Writeboost shouldn't split the bio into 4KB chunks. No. It is necessary. I know WALB (https://github.com/starpos/walb) logs data without splitting but the data structure becomes complicated. If you read my code carefully, you will notice that splitting helps the design simplicity and performance. 2. Writeboost has to avoid copying of data to in-core buffer. No. It is also necessary. Think about partial write (smaller than 4KB). Also, think about it's incoming I/O amount is even smaller than the memory throughput. So, it won't affect the performance and it's actually not (see the fio performance). I will also copy data when I implement read-caching that will be surely criticized by you or Joe eventually. As for the way of discussing, it's NOT fair to discuss based on technically not meaningful data that is measured on VM in this case. It's violence, not discussion. I am really amazed by you two suddenly "unstably" turning into nacking within a day. I showed you a data that Writeboost already surpasses the spindle but you ignored it is also unfair. Did you think I cheated? With read-caching, Writeboost can be more performant for sure. My conclusion at this point is I don't like to change these two fundamental design decision. If you want to nack without knowing how important these things, it's fairly OK because device-mapper is your castle. But in that case, I can't (not won't) persuade you and sadly, retrieve from not only upstreaming *forever*. I think you don't even try to understand the importance of Writeboost. Although this guy really understand it (https://github.com/yongseokoh/dm-src). The SSD-caching should be log-structured. - Akira On 12/12/14 12:26 AM, Mike Snitzer wrote: > On Wed, Dec 10 2014 at 6:42am -0500, > Akira Hayakawa wrote: > >> This patch adds dm-writeboost to staging tree. >> >> dm-writeboost is a log-structured SSD-caching driver. >> It caches data in log-structured way on the cache device >> so that the performance is maximized. >> >> The merit of putting this driver in staging tree is >> to make it possible to get more feedback from users >> and polish the codes. >> >> Signed-off-by: Akira Hayakawa > > Joe Thornber Nacked this from going into staging based on his further > review of the code. On the basis that you should _not_ be copying all > pages associated with each bio into an in-core buffer. Have you > addressed that fundamental problem? > > But taking a step back: Why do you think going into staging actually > helps you? Anyone who is willing to test this code should be able to > apply a patch to their kernel. Having to feed changes to Greg to > deliver updates to any early consumers of this _EXPERIMENTAL_ target > seems misplaced when you consider that Joe has detailed important > fixes, capabilties and tools that need addressing before anyone should > trust their production data to dm-writeboost. > > I think you're completely missing that you are pushing _hard_ for this > target to go upstream before it is actually ready. In doing so you're > so hung up on that "upstream" milestone that you cannot appreciate the > reluctance that Joe and I have given the quantity of code you're pushing > -- especially when coupled with the limited utility of dm-writeboost in > comparison with full featured upstream drivers like dm-cache and bcache. > > As for this v2, you didn't detail what you changed (I can obviously > apply v1 and then v2 to see the difference but a brief summary would be > helpful in general when you revise a patch) > > But one inline comment: > >> diff --git a/drivers/staging/writeboost/TODO >> b/drivers/staging/writeboost/TODO >> new file mode 100644 >> index 000..761a9fe >> --- /dev/null >> +++ b/drivers/staging/writeboost/TODO >> @@ -0,0 +1,52 @@ >> +TODO: >> + >> +- Get the GitExtract test so it's performance is similar to raw spindle. > > No, the whole point of a write cache is to improve performance. You > should be trying to surpass the performance of the raw spindle. > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2
> "Long" == Long Li writes: >> Handle the issues or handle WRITE SAME(10/16)? Long> With this patch, the SCSI layer will be able to correctly send Long> WRITE_SAME_16 to the Hyper-V host. It will not send WRITE_SAME_10: Long> it has been disabled in the driver template. Do you want me to Long> send another patch with these details? no_write_same prevents us from attempting to use WRITE SAME(10/16) to zero block ranges. This is completely orthogonal to using the WRITE SAME(10/16) commands with the UNMAP bit set to discard block ranges. The latter is controlled by the logical block provisioning heuristics and is not affected by no_write_same at all. -- Martin K. Petersen Oracle Linux Engineering ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
