without power cycling
(it's nRESET pin is connected to P3V3).
I found that removing regulator-always-on from buck8_reg: BUCK8 in the
dts file fixes this problem.
Yes, that fixes the problem. Thanks!
Tested-by: Daniel Drake dr...@endlessm.com
--
To unsubscribe from this list: send the line
Hi,
On Tue, Jun 24, 2014 at 5:08 PM, Tomasz Figa t.f...@samsung.com wrote:
Tested on Odroid U3, with HSIC/USB hub using CLKOUT as reference clock,
with some additional patches.
for all the patches:
Tested-by: Daniel Drake dr...@endlessm.com
Tested on ODROID-U2 alongside
phy: phy-samsung
Hi Tomasz,
On Tue, Jun 24, 2014 at 2:57 PM, Tomasz Figa t.f...@samsung.com wrote:
ISP special clocks have dedicated gating registers and so MUX SRC_MASK
register should not be used. This patch fixes the problem of
Exynos4x12-based boards freezing on system suspend, because those
mux outputs
Hi Tomasz,
On Tue, Jun 24, 2014 at 2:57 PM, Tomasz Figa t.f...@samsung.com wrote:
Due to recently merged patches and previous merge conflicts, the Samsung
PM Debug functionality no longer can be enabled. This patch fixes
incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds
On Tue, Jun 24, 2014 at 1:54 PM, Kamil Debski wrote:
> The Exynos4412 USB 2.0 PHY hardware differs from the description provided
> in the documentation. Some register bits have different function. This
> patch fixes the defines of register bits and changes the way how phys are
> powered on and
On Tue, Jun 24, 2014 at 1:54 PM, Kamil Debski k.deb...@samsung.com wrote:
The Exynos4412 USB 2.0 PHY hardware differs from the description provided
in the documentation. Some register bits have different function. This
patch fixes the defines of register bits and changes the way how phys are
Hi Tomasz,
On Tue, May 20, 2014 at 5:43 PM, Tomasz Figa wrote:
> Since the block responsible for handling the pin is PMU, not CMU,
> a separate driver, that binds to PMU node is required and acquires
> all input clocks by standard DT clock look-up. This way we don't need
> any cross-IP block
Hi Tomasz,
On Tue, May 20, 2014 at 5:43 PM, Tomasz Figa t.f...@samsung.com wrote:
Since the block responsible for handling the pin is PMU, not CMU,
a separate driver, that binds to PMU node is required and acquires
all input clocks by standard DT clock look-up. This way we don't need
any
Hi,
On Fri, Jun 13, 2014 at 3:59 PM, Tomasz Figa wrote:
> I have attached, three patches which make the kernel boot fine with L2
> cache enabled on ODROID-U3. Could you test them on your setup to verify
> that they indeed fix the issue?
Nice work, now my ODROID-U2 boots fine.
L2C: platform
Hi,
On Fri, Jun 13, 2014 at 3:59 PM, Tomasz Figa t.f...@samsung.com wrote:
I have attached, three patches which make the kernel boot fine with L2
cache enabled on ODROID-U3. Could you test them on your setup to verify
that they indeed fix the issue?
Nice work, now my ODROID-U2 boots fine.
Hi Tomasz,
Thanks for working on this!
I have just tried this, against Linus master
64b2d1fbbfda07765dae3f601862796a61b2c451.
Added patch "ARM: dts: Initial ODROID U2 support" and booted on
ODROID-U2. I believe this board has the security enabled.
Unfortunately, it hangs during early boot. With
Hi Tomasz,
Thanks for working on this!
I have just tried this, against Linus master
64b2d1fbbfda07765dae3f601862796a61b2c451.
Added patch ARM: dts: Initial ODROID U2 support and booted on
ODROID-U2. I believe this board has the security enabled.
Unfortunately, it hangs during early boot. With
Hi Pavel,
On Sat, Jun 7, 2014 at 11:53 PM, Pavel Machek wrote:
> I broke installation on olpc-1.75, and I guess its time for it to
> start running self-compiled kernel. (It still boots if I hold right
> game key, but I can no longer control backlight. It does not boot at
> all by default.)
>
>
Hi Pavel,
On Sat, Jun 7, 2014 at 11:53 PM, Pavel Machek pa...@ucw.cz wrote:
I broke installation on olpc-1.75, and I guess its time for it to
start running self-compiled kernel. (It still boots if I hold right
game key, but I can no longer control backlight. It does not boot at
all by
and olpc-xo1-sci failed to load due to an inability to
communicate with the EC. The user-visible effect was a lack of battery
monitoring, missing ebook/lid switch input devices, etc.
Signed-off-by: Daniel Drake
---
drivers/platform/olpc/olpc-ec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
and olpc-xo1-sci failed to load due to an inability to
communicate with the EC. The user-visible effect was a lack of battery
monitoring, missing ebook/lid switch input devices, etc.
Signed-off-by: Daniel Drake d...@laptop.org
---
drivers/platform/olpc/olpc-ec.c | 2 +-
1 file changed, 1 insertion(+), 1
and
restructured.
Use arch_initcall so that olpc-ec is readied earlier, matching the
previous behaviour. Fixes various drivers such as olpc-battery and
olpc-xo1-sci.
Signed-off-by: Daniel Drake
---
drivers/platform/olpc/olpc-ec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
and
restructured.
Use arch_initcall so that olpc-ec is readied earlier, matching the
previous behaviour. Fixes various drivers such as olpc-battery and
olpc-xo1-sci.
Signed-off-by: Daniel Drake d...@laptop.org
---
drivers/platform/olpc/olpc-ec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Commit-ID: d55e37bb0f51316e552376ddc0a3fff34ca7108b
Gitweb: http://git.kernel.org/tip/d55e37bb0f51316e552376ddc0a3fff34ca7108b
Author: Daniel Drake
AuthorDate: Fri, 9 Aug 2013 18:14:20 -0400
Committer: H. Peter Anvin
CommitDate: Fri, 9 Aug 2013 15:29:48 -0700
x86: Don't clear
by the sentinel-detection code, and all users of olpc_ofw_header are
somewhat protected through checking for the OLPC_OFW_SIG magic value
before using it. So this should not cause any problems for anyone.
Signed-off-by: Daniel Drake
Acked-by: Yinghai Lu
---
arch/x86/include/asm/bootparam_utils.h | 4 ++--
1
by the sentinel-detection code, and all users of olpc_ofw_header are
somewhat protected through checking for the OLPC_OFW_SIG magic value
before using it. So this should not cause any problems for anyone.
Signed-off-by: Daniel Drake d...@laptop.org
Acked-by: Yinghai Lu ying...@kernel.org
---
arch/x86/include
Commit-ID: d55e37bb0f51316e552376ddc0a3fff34ca7108b
Gitweb: http://git.kernel.org/tip/d55e37bb0f51316e552376ddc0a3fff34ca7108b
Author: Daniel Drake d...@laptop.org
AuthorDate: Fri, 9 Aug 2013 18:14:20 -0400
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Fri, 9 Aug 2013 15:29
-detection code, and all users of olpc_ofw_header are
somewhat protected through checking for the OLPC_OFW_SIG magic value
before using it. So this should not cause any problems for anyone.
Signed-off-by: Daniel Drake
---
arch/x86/include/asm/bootparam_utils.h | 4 ++--
1 file changed, 2 insertions
On Fri, Jul 12, 2013 at 6:35 PM, Haojian Zhuang
wrote:
> These patches couldn't be applied. Since we're moving irq drivers from arch
> directories to irq directories.
It does not seem in line with the collaborative manner of kernel
development to block my patches for a whole month because they
On Fri, Jul 12, 2013 at 6:35 PM, Haojian Zhuang
haojian.zhu...@gmail.com wrote:
These patches couldn't be applied. Since we're moving irq drivers from arch
directories to irq directories.
It does not seem in line with the collaborative manner of kernel
development to block my patches for a
-detection code, and all users of olpc_ofw_header are
somewhat protected through checking for the OLPC_OFW_SIG magic value
before using it. So this should not cause any problems for anyone.
Signed-off-by: Daniel Drake d...@laptop.org
---
arch/x86/include/asm/bootparam_utils.h | 4 ++--
1 file changed, 2
On Fri, Jul 12, 2013 at 9:57 AM, Jason Cooper wrote:
> This also means we should do a patch for stable v3.5+ appending the
> "mrvl,..." string to the drivers that had it removed improperly, as
> Daniel discovered. Daniel, since you are probably most familiar (and
> most able to test ;-) ), would
On Thu, Jul 11, 2013 at 5:54 PM, Haojian Zhuang
wrote:
>> Well, Daniel Drake spoke up for OLPC. Does that count?
>
> We don't know they used DT on Marvell MMP2/MMP3. So they don't have DTS file
> in kernel, we could use both old name & new name in driver.
You are liste
On Thu, Jul 11, 2013 at 5:54 PM, Haojian Zhuang
haojian.zhu...@gmail.com wrote:
Well, Daniel Drake spoke up for OLPC. Does that count?
We don't know they used DT on Marvell MMP2/MMP3. So they don't have DTS file
in kernel, we could use both old name new name in driver.
You are listed as one
On Fri, Jul 12, 2013 at 9:57 AM, Jason Cooper ja...@lakedaemon.net wrote:
This also means we should do a patch for stable v3.5+ appending the
mrvl,... string to the drivers that had it removed improperly, as
Daniel discovered. Daniel, since you are probably most familiar (and
most able to
On Wed, Jul 10, 2013 at 6:20 AM, Jason Cooper wrote:
> Please keep in mind that the DT is supposed to be tied to the hardware,
> *not* the kernel. iow, a dtb comes with a board, and the user/OS
> upgrades the kernel as needed w/o upgrading or changing the dtb.
Thank you for making this position
On Wed, Jul 10, 2013 at 6:20 AM, Jason Cooper ja...@lakedaemon.net wrote:
Please keep in mind that the DT is supposed to be tied to the hardware,
*not* the kernel. iow, a dtb comes with a board, and the user/OS
upgrades the kernel as needed w/o upgrading or changing the dtb.
Thank you for
On Mon, Feb 25, 2013 at 5:21 PM, Bing Zhao wrote:
> Do you have any concern for OLPC platforms with above change? If it doesn't
> seem to break OLPC I will send a patch to the list.
Looks fine to me. Thanks for investigating.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe
On Mon, Feb 25, 2013 at 5:21 PM, Bing Zhao bz...@marvell.com wrote:
Do you have any concern for OLPC platforms with above change? If it doesn't
seem to break OLPC I will send a patch to the list.
Looks fine to me. Thanks for investigating.
Daniel
--
To unsubscribe from this list: send the
On Fri, Jan 18, 2013 at 8:35 PM, H. Peter Anvin wrote:
> Can we simply disable paging before mucking with CR4? The other option
> that I can see is to always enable PSE and PGE, since they are simply
> features opt-ins that don't do any harm if unused. At the same time,
> though, entering the
On Fri, Jan 18, 2013 at 8:35 PM, H. Peter Anvin h...@linux.intel.com wrote:
Can we simply disable paging before mucking with CR4? The other option
that I can see is to always enable PSE and PGE, since they are simply
features opt-ins that don't do any harm if unused. At the same time,
Hi,
Bump :)
On Thu, Jul 19, 2012 at 9:42 AM, Daniel Drake wrote:
> I'm having trouble with the loop device partition scanning code.
>
> If I create a blank file, put a partition table on it with fdisk, and
> then immediately turn it into a partitioned loop device, the
> partiti
Hi,
Bump :)
On Thu, Jul 19, 2012 at 9:42 AM, Daniel Drake d...@laptop.org wrote:
I'm having trouble with the loop device partition scanning code.
If I create a blank file, put a partition table on it with fdisk, and
then immediately turn it into a partitioned loop device, the
partitions
Hi,
I'm having trouble with the loop device partition scanning code.
If I create a blank file, put a partition table on it with fdisk, and
then immediately turn it into a partitioned loop device, the
partitions dont always show up.
Here is a script to test this:
Hi,
I'm having trouble with the loop device partition scanning code.
If I create a blank file, put a partition table on it with fdisk, and
then immediately turn it into a partitioned loop device, the
partitions dont always show up.
Here is a script to test this:
From: Richard A. Smith
Reduce the mAh value for the BYD LiFe battery from 3100mAh to 2800mAh
to better reflect the average usable capacity as measured by olpc-pwr-log.
Signed-off-by: Richard A. Smith
Signed-off-by: Daniel Drake
---
drivers/power/olpc_battery.c |6 ++
1 file changed
energy
capacity.
Adding the VOLTAGE_MAX_DESIGN property allows upowerd to compute the
same energy every time.
Signed-off-by: Richard A. Smith
Signed-off-by: Daniel Drake
---
drivers/power/olpc_battery.c | 54 ++
1 file changed, 54 insertions(+)
diff
a slightly different energy
capacity.
Adding the VOLTAGE_MAX_DESIGN property allows upowerd to compute the
same energy every time.
Signed-off-by: Richard A. Smith rich...@laptop.org
Signed-off-by: Daniel Drake d...@laptop.org
---
drivers/power/olpc_battery.c | 54
From: Richard A. Smith rich...@laptop.org
Reduce the mAh value for the BYD LiFe battery from 3100mAh to 2800mAh
to better reflect the average usable capacity as measured by olpc-pwr-log.
Signed-off-by: Richard A. Smith rich...@laptop.org
Signed-off-by: Daniel Drake d...@laptop.org
---
drivers
Randy Dunlap wrote:
We (the -stable team) are announcing the release of the 2.6.24.3
kernel.
When HEADERS_CHECK=y:
make[3]: *** No rule to make target
`/local/linsrc/linux-2.6.24.3/include/linux/if_addrlabel.h', needed by
`/local/linsrc/linux-2.6.24.3/usr/include/linux/if_addrlabel.h'.
Greg Kroah-Hartman wrote:
We (the -stable team) are announcing the release of the 2.6.24.3
kernel.
patch-2.6.24.2-3.* files are missing from
http://www.kernel.org/pub/linux/kernel/v2.6/incr/
The 2.6.23.17 patches which were released at the same time are there, so
it doesn't seem to be a
Randy Dunlap wrote:
We (the -stable team) are announcing the release of the 2.6.24.3
kernel.
When HEADERS_CHECK=y:
make[3]: *** No rule to make target
`/local/linsrc/linux-2.6.24.3/include/linux/if_addrlabel.h', needed by
`/local/linsrc/linux-2.6.24.3/usr/include/linux/if_addrlabel.h'.
Greg Kroah-Hartman wrote:
We (the -stable team) are announcing the release of the 2.6.24.3
kernel.
patch-2.6.24.2-3.* files are missing from
http://www.kernel.org/pub/linux/kernel/v2.6/incr/
The 2.6.23.17 patches which were released at the same time are there, so
it doesn't seem to be a
[EMAIL PROTECTED] wrote:
I am trying to write a device driver for a USB device that is not currently
supported by Linux. Trouble is all the examples I have found so far (
usb-skel.c and others ) give an example of a driver that is a middle man
between a userspace application and the device. So
Hi,
The patch titled pci-disable-decoding-during-sizing-of-bars.patch in -mm
was previously used as a candidate to fix a boot hang with Intel's Q35
chipset: https://bugs.gentoo.org/show_bug.cgi?id=198810
However, that particular issue is solved by commit a0ca9909609 in Linus
tree:
Hi,
The patch titled pci-disable-decoding-during-sizing-of-bars.patch in -mm
was previously used as a candidate to fix a boot hang with Intel's Q35
chipset: https://bugs.gentoo.org/show_bug.cgi?id=198810
However, that particular issue is solved by commit a0ca9909609 in Linus
tree:
This should be asked on linux-hotplug and not linux-kernel, but anyway...
sacarde wrote:
how can I view udev variables value ?
for examples:
what is value of:
BUS
SYSFS{idProduct}
SYSFS{idVendor}
when I insert my stick-usb wireless ?
This documentation should help you:
This should be asked on linux-hotplug and not linux-kernel, but anyway...
sacarde wrote:
how can I view udev variables value ?
for examples:
what is value of:
BUS
SYSFS{idProduct}
SYSFS{idVendor}
when I insert my stick-usb wireless ?
This documentation should help you:
Ivan Kokshaysky wrote:
On alpha, ia64 and ppc64 only relocations to local data can go into
read-only sections. The vast majority of module parameters use the global
generic param_set_*/param_get_* functions, so the 'const' attribute for
struct kernel_param is not only useless, but it also causes
Ivan Kokshaysky wrote:
On alpha, ia64 and ppc64 only relocations to local data can go into
read-only sections. The vast majority of module parameters use the global
generic param_set_*/param_get_* functions, so the 'const' attribute for
struct kernel_param is not only useless, but it also causes
connection handle 92
This patch solves the issue. I'm not sure of its correctness, it is based
on work by Ossi Berg and Tim Gardner on the Ubuntu bug tracker.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
resending due to no response after 2 weeks
diff --git a/drivers/bluetooth/hci_u
connection handle 92
This patch solves the issue. I'm not sure of its correctness, it is based
on work by Ossi Berg and Tim Gardner on the Ubuntu bug tracker.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
---
resending due to no response after 2 weeks
diff --git a/drivers/bluetooth/hci_usb.c b
James Bottomley wrote:
However, I think you're right, the vanilla TUR does eat NOT_READY for
removable media, which CDs are. Does this fix it?
Works great, thanks!
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Hi James,
James Bottomley wrote:
It's been a while with no status on this one, so I corrected the patch
based on my original input. The attached is what I think is the best
way of doing this (I've replaced the home grown test_unit_ready routine
with the SCSI one and updated some of the sense
Hi James,
James Bottomley wrote:
It's been a while with no status on this one, so I corrected the patch
based on my original input. The attached is what I think is the best
way of doing this (I've replaced the home grown test_unit_ready routine
with the SCSI one and updated some of the sense
Konstantin Kletschke wrote:
Am 2008-02-05 14:26 +0100 schrieb Xavier Bestel:
+UNUSUAL_DEV( 0x04b0, 0x0411, 0x0100, 0x0110,
Maybe you should leave them both here.
I suppose the device is checked against a range between
bcdDeviceMin -> bcdDeviceMax to take care of the possibility new
Konstantin Kletschke wrote:
Am 2008-02-05 14:26 +0100 schrieb Xavier Bestel:
+UNUSUAL_DEV( 0x04b0, 0x0411, 0x0100, 0x0110,
Maybe you should leave them both here.
I suppose the device is checked against a range between
bcdDeviceMin - bcdDeviceMax to take care of the possibility new
Hi Andrew,
Nothing major, but the From: line in your -mm patch
pci-disable-decoding-during-sizing-of-bars.patch is wrong.
The patch is from Matthew Wilcox <[EMAIL PROTECTED]>, just Andreas helped
bring the issue to people's attention :)
Thanks,
Daniel
--
To unsubscribe from this list: send
Hi Andrew,
Nothing major, but the From: line in your -mm patch
pci-disable-decoding-during-sizing-of-bars.patch is wrong.
The patch is from Matthew Wilcox [EMAIL PROTECTED], just Andreas helped
bring the issue to people's attention :)
Thanks,
Daniel
--
To unsubscribe from this list: send
Here's a document I wrote after figuring out what unaligned memory access
is all about. I've tried to cover the information I was looking for when
trying to learn about this, without producing a hopelessly detailed/complex
spew. I hope it is useful to others.
Signed-off-by: Daniel Drake <[EM
Toralf Förster wrote:
Today I tried to hibernate my ThinkPad but got the following :
And the outcome was what exactly? It didn't suspend, and hard-hung? Or
didn't suspend, came back to a usable system? ...
Dec 3 14:14:29 n22 c420
Dec 3 14:14:29 n22 dca29fb8 dca29f90 d30ad4c4
Toralf Förster wrote:
Today I tried to hibernate my ThinkPad but got the following :
And the outcome was what exactly? It didn't suspend, and hard-hung? Or
didn't suspend, came back to a usable system? ...
Dec 3 14:14:29 n22 c420
Dec 3 14:14:29 n22 dca29fb8 dca29f90 d30ad4c4
Here's a document I wrote after figuring out what unaligned memory access
is all about. I've tried to cover the information I was looking for when
trying to learn about this, without producing a hopelessly detailed/complex
spew. I hope it is useful to others.
Signed-off-by: Daniel Drake [EMAIL
y(),
where the source or destination (or both) are of type u8* or unsigned char*.
Due to the byte-wise nature of this operation, unaligned accesses are avoided.
--
Author: Daniel Drake <[EMAIL PROTECTED]>
With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
Johannes Berg, Kyle
(),
where the source or destination (or both) are of type u8* or unsigned char*.
Due to the byte-wise nature of this operation, unaligned accesses are avoided.
--
Author: Daniel Drake [EMAIL PROTECTED]
With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
Johannes Berg, Kyle Moffett
above). You could
even use put_unaligned() rather than memcpy() in order to solve the bug in
the first example (myfunc()) given above.
--
Author: Daniel Drake <[EMAIL PROTECTED]>
With help from: Johannes Berg, Uli Kunitz.
-
To unsubscribe from this list: send the line "unsubscribe l
(not just 32 bits as in the example above). You could
even use put_unaligned() rather than memcpy() in order to solve the bug in
the first example (myfunc()) given above.
--
Author: Daniel Drake [EMAIL PROTECTED]
With help from: Johannes Berg, Uli Kunitz.
-
To unsubscribe from this list: send the line
subdirectory is now only created
when CONFIG_PM_SLEEP is set, however, it should be created whenever CONFIG_PM
is set to handle the above situation. The following patch fixes the
regression.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
Index: linux-2.6.24-rc1-git14/drivers/base/
subdirectory is now only created
when CONFIG_PM_SLEEP is set, however, it should be created whenever CONFIG_PM
is set to handle the above situation. The following patch fixes the
regression.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Index: linux-2.6.24-rc1-git14/drivers/base/core.c
Tejun Heo wrote:
However, there's still remaining issues. What does happen if you raise
allocation length and buffersize of the test program to 16? ie. Change
0x0a in cmd[] to 0x10 and increase buffer[10] to buffer[16].
Eek. The process hangs in D state for a good 60 seconds or so.
Caught a
Tejun Heo wrote:
However, there's still remaining issues. What does happen if you raise
allocation length and buffersize of the test program to 16? ie. Change
0x0a in cmd[] to 0x10 and increase buffer[10] to buffer[16].
Eek. The process hangs in D state for a good 60 seconds or so.
Caught a
Tejun Heo wrote:
<4>ata2.00: HSM violation: eh_analyze_tf: BUSY|DRQ
<3>ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
<3>ata2.00: cmd a0/00:00:00:0a:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data
10 in
<4> res 58/00:02:00:0a:00/00:00:00:00:00/a0 Emask 0x2 (HSM
violation)
Tejun Heo wrote:
4ata2.00: HSM violation: eh_analyze_tf: BUSY|DRQ
3ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
3ata2.00: cmd a0/00:00:00:0a:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data
10 in
4 res 58/00:02:00:0a:00/00:00:00:00:00/a0 Emask 0x2 (HSM
violation)
3ata2.00:
Tejun Heo wrote:
Yeap, the SG command is fine. The drive is being weird tho. The
allocation length field says 10 bytes, so it should just have
transferred 10 bytes without causing HSM violation.
Can you please apply the attached patch and report what the kernel says
after triggering the error
Tejun Heo wrote:
Yeap, the SG command is fine. The drive is being weird tho. The
allocation length field says 10 bytes, so it should just have
transferred 10 bytes without causing HSM violation.
Can you please apply the attached patch and report what the kernel says
after triggering the error
Alan Cox wrote:
Lots of *other* problems occur instead. Daniel is reporting that if he
makes a stupid request to a buggy drive he gets a reset and the system
continues happily. Even that reset being a reset not a new command issue
is actually us being excessively paranoid.
Sorry if I'm
Alan Cox wrote:
Lots of *other* problems occur instead. Daniel is reporting that if he
makes a stupid request to a buggy drive he gets a reset and the system
continues happily. Even that reset being a reset not a new command issue
is actually us being excessively paranoid.
Sorry if I'm
Jeff Garzik wrote:
Jens Axboe wrote:
Right, that's of course problematic... There has to be a way to recover
that situation though, or you can't export any user command issue
facility.
You cannot hope to handle all possible effects arising from an app
providing an invalid sg header / cdb.
Jeff Garzik wrote:
Jens Axboe wrote:
Right, that's of course problematic... There has to be a way to recover
that situation though, or you can't export any user command issue
facility.
You cannot hope to handle all possible effects arising from an app
providing an invalid sg header / cdb.
Alan Cox wrote:
I would guess Brasero is issuing a command with the length of data
wrongly set. In the old code that might well just produce errors of the
"Umm wtf is this data left over for ?", with the new code the drive is
likely to change state as it knows the transfer size and that will
Alan Cox wrote:
Not immediately - but if you've got wrong transfer lengths its a
candidate for this.
Ok lets start with the basics
If you mount a CD and use it does it work
Yep.
If you use cdrecord does it work ?
Yep (tested with wodim from debburn, effectively the same thing)
What
Hi Alan,
In 2.6.23 and previous, CD writing works fine on my system. I'm using
ata_piix on:
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA
IDE Controller (rev 01)
When I'm running CD writing utilities, I sometimes see this message in
the kernel logs:
Hi Alan,
In 2.6.23 and previous, CD writing works fine on my system. I'm using
ata_piix on:
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA
IDE Controller (rev 01)
When I'm running CD writing utilities, I sometimes see this message in
the kernel logs:
Alan Cox wrote:
Not immediately - but if you've got wrong transfer lengths its a
candidate for this.
Ok lets start with the basics
If you mount a CD and use it does it work
Yep.
If you use cdrecord does it work ?
Yep (tested with wodim from debburn, effectively the same thing)
What
Alan Cox wrote:
I would guess Brasero is issuing a command with the length of data
wrongly set. In the old code that might well just produce errors of the
Umm wtf is this data left over for ?, with the new code the drive is
likely to change state as it knows the transfer size and that will
Marc Pignat wrote:
Hi all!
On Monday 15 October 2007, Daniel Drake wrote:
...
Acked-by: Daniel Drake <[EMAIL PROTECTED]>
Is there any hope to apply this to 2.6.23.2, as this is a regression fix?
Yes, already planned, it just has to go upstream first.
Thanks,
Daniel
-
To unsubscrib
Marc Pignat wrote:
Hi all!
On Monday 15 October 2007, Daniel Drake wrote:
...
Acked-by: Daniel Drake [EMAIL PROTECTED]
Is there any hope to apply this to 2.6.23.2, as this is a regression fix?
Yes, already planned, it just has to go upstream first.
Thanks,
Daniel
-
To unsubscribe from
Marc Pignat wrote:
The disconnect function can dereference the net_device structure before it is
allocated. This is the case when ejecting the device installer.
Signed-off-by: Marc Pignat <[EMAIL PROTECTED]>
s/before it is allocated/when it is never allocated/
Acked-by: Daniel Drake &
Marc Pignat wrote:
The disconnect function can dereference the net_device structure before it is
allocated. This is the case when ejecting the device installer.
Signed-off-by: Marc Pignat [EMAIL PROTECTED]
s/before it is allocated/when it is never allocated/
Acked-by: Daniel Drake [EMAIL
Jesper Juhl wrote:
What would be wrong in applying my patch that removes the cast of the
kmalloc() return value and then also remove the "__nocast" here?
We use it as a safety measure when coding. For example the write
register function takes an address and a value. We got one of these the
Jesper Juhl wrote:
Since kmalloc() returns a void pointer there is no reason to cast
its return value.
This patch also removes a pointless initialization of a variable.
NAK: adds a sparse warning
zd_chip.c:116:15: warning: implicit cast to nocast type
Signed-off-by: Jesper Juhl <[EMAIL
ot strong, but you can see why
fast swapoff would be mighty convenient.
Thanks for all the info so far. It does sound like my earlier idea
wouldn't be any faster in the general case due to excess disk seeking.
Oh well...
--
Daniel Drake
Brontes Technologies, A 3M Company
http://www.brontes3d.com/o
, but you can see why
fast swapoff would be mighty convenient.
Thanks for all the info so far. It does sound like my earlier idea
wouldn't be any faster in the general case due to excess disk seeking.
Oh well...
--
Daniel Drake
Brontes Technologies, A 3M Company
http://www.brontes3d.com/opensource
Jesper Juhl wrote:
Since kmalloc() returns a void pointer there is no reason to cast
its return value.
This patch also removes a pointless initialization of a variable.
NAK: adds a sparse warning
zd_chip.c:116:15: warning: implicit cast to nocast type
Signed-off-by: Jesper Juhl [EMAIL
Jesper Juhl wrote:
What would be wrong in applying my patch that removes the cast of the
kmalloc() return value and then also remove the __nocast here?
We use it as a safety measure when coding. For example the write
register function takes an address and a value. We got one of these the
201 - 300 of 540 matches
Mail list logo
