* Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: John Stanley @ 2011-01-18 21:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D263BF6.6050305@verizon.net>
Fantastic... looks promising, test-identify-packet is running w/o issue,
and boots, so far, as well. I will further test with a number of warm
and cold boots over the next several days to see if anything crops up.
I'm very grateful for your time and efforts with this, thanks again,
John
On 01/18/2011 10:09 AM, Tejun Heo wrote:
> Hello,
>
> Can you please test whether the following patch fixes the problem?
>
> Thanks.
>
> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index 5defc74..9d46731 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -1099,9 +1099,9 @@ static int ata_scsi_dev_config(struct scsi_device *sdev,
> struct request_queue *q = sdev->request_queue;
> void *buf;
>
> - /* set the min alignment and padding */
> - blk_queue_update_dma_alignment(sdev->request_queue,
> - ATA_DMA_PAD_SZ - 1);
> + sdev->sector_size = ATA_SECT_SIZE;
> +
> + /* set DMA padding */
> blk_queue_update_dma_pad(sdev->request_queue,
> ATA_DMA_PAD_SZ - 1);
>
> @@ -1115,13 +1115,18 @@ static int ata_scsi_dev_config(struct scsi_device *sdev,
>
> blk_queue_dma_drain(q, atapi_drain_needed, buf, ATAPI_MAX_DRAIN);
> } else {
> - /* ATA devices must be sector aligned */
> sdev->sector_size = ata_id_logical_sector_size(dev->id);
> - blk_queue_update_dma_alignment(sdev->request_queue,
> - sdev->sector_size - 1);
> sdev->manage_start_stop = 1;
> }
>
> + /*
> + * ata_pio_sectors() expect sector alignment on buffers. ATAPI
> + * devices also need the alignment as IDENTIFY_PACKET is executed
> + * as ATA_PROT_PIO.
> + */
> + blk_queue_update_dma_alignment(sdev->request_queue,
> + sdev->sector_size - 1);
> +
> if (dev->flags& ATA_DFLAG_AN)
> set_bit(SDEV_EVT_MEDIA_CHANGE, sdev->supported_events);
>
>
^ permalink raw reply
* Re: udev minimum requirement
From: Kay Sievers @ 2011-01-18 17:33 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTikdw11L1adphyv4hDk-aG9vn82V80X0zyvZ+Lkc@mail.gmail.com>
On Tue, Jan 18, 2011 at 18:25, Darcoux Christine <bouloumag@gmail.com> wrote:
> I am a little confused about the minimum kernel version need for udev .
> Is there a contradiction between these two sentences from the README file ?
>
> "The upstream udev project's set of default rules may require a most recent
> kernel release to work properly. This is currently version 2.6.31."
That's what we usually test and should work out-of-the-box.
> and
>
> "Requirements:
> Â - Version 2.6.27 of the Linux kernel"
That's the first version of the old kernels that has all the
requirement to just run udev. It may fail completely with older
versions. But nobody really tests that, I guess, at least not
constantly. Rules may be missing. Many possible issues could be worked
around, are might not be to find in the udev source tree.
> Does it means that the **real** minimum requirement is kernel 2.6.31 ?
> If not, what will works with 2.6.31 that will not work with 2.6.27 ?
Nobody really knows, I guess, because we usually don't run old kernels
on new userspace tools. We only make sure that new kernels can run on
old userspace, not the other way around.
Kay
^ permalink raw reply
* udev minimum requirement
From: Darcoux Christine @ 2011-01-18 17:25 UTC (permalink / raw)
To: linux-hotplug
Hi,
I am a little confused about the minimum kernel version need for udev .
Is there a contradiction between these two sentences from the README file ?
"The upstream udev project's set of default rules may require a most recent
kernel release to work properly. This is currently version 2.6.31."
and
"Requirements:
- Version 2.6.27 of the Linux kernel"
Does it means that the **real** minimum requirement is kernel 2.6.31 ?
If not, what will works with 2.6.31 that will not work with 2.6.27 ?
Christine
^ permalink raw reply
* Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: Tejun Heo @ 2011-01-18 15:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D263BF6.6050305@verizon.net>
Hello,
Can you please test whether the following patch fixes the problem?
Thanks.
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 5defc74..9d46731 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -1099,9 +1099,9 @@ static int ata_scsi_dev_config(struct scsi_device *sdev,
struct request_queue *q = sdev->request_queue;
void *buf;
- /* set the min alignment and padding */
- blk_queue_update_dma_alignment(sdev->request_queue,
- ATA_DMA_PAD_SZ - 1);
+ sdev->sector_size = ATA_SECT_SIZE;
+
+ /* set DMA padding */
blk_queue_update_dma_pad(sdev->request_queue,
ATA_DMA_PAD_SZ - 1);
@@ -1115,13 +1115,18 @@ static int ata_scsi_dev_config(struct scsi_device *sdev,
blk_queue_dma_drain(q, atapi_drain_needed, buf, ATAPI_MAX_DRAIN);
} else {
- /* ATA devices must be sector aligned */
sdev->sector_size = ata_id_logical_sector_size(dev->id);
- blk_queue_update_dma_alignment(sdev->request_queue,
- sdev->sector_size - 1);
sdev->manage_start_stop = 1;
}
+ /*
+ * ata_pio_sectors() expect sector alignment on buffers. ATAPI
+ * devices also need the alignment as IDENTIFY_PACKET is executed
+ * as ATA_PROT_PIO.
+ */
+ blk_queue_update_dma_alignment(sdev->request_queue,
+ sdev->sector_size - 1);
+
if (dev->flags & ATA_DFLAG_AN)
set_bit(SDEV_EVT_MEDIA_CHANGE, sdev->supported_events);
^ permalink raw reply related
* Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: John Stanley @ 2011-01-18 3:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D263BF6.6050305@verizon.net>
Some additional info. If I modify test-identify-packet.c to align on
_SC_PAGESIZE (4096 byte) rather than 512, as shown below, then run the loop:
offset=${1:-0}
increm=${2:-1}
while [ $((offset+=$increm)) -lt $((4096-511)) ]; do
echo -e "+++ ./test-identify-packetpage /dev/sr0 $offset\n"
./test-identify-packet-page /dev/sr0 $offset
sleep 0.5
done
no panics occur, for every offset.
512 -> pagesize modification:
--- test-identify-packet.c 2011-01-17 13:47:25.000000000 -0500
+++ test-identify-packet-page.c 2011-01-17 22:27:11.293999984 -0500
@@ -99,7 +99,8 @@
int main(int argc, char *argv[])
{
- char buf[2048];
+ int pgsz = sysconf(_SC_PAGESIZE);
+ char buf[pgsz<<1];
char *id;
char *path;
int offset = 0;
@@ -116,7 +117,7 @@
if (argc > 2)
offset = atoi(argv[2]);
- if (offset < 0 || offset > 512) {
+ if (offset < 0 || offset > pgsz-512) {
fprintf(stderr, "offset out of range\n");
return 1;
}
@@ -133,7 +134,7 @@
return 1;
}
- id = (void *)((((unsigned long)buf + 511) & ~511) + offset);
+ id = (void *)((((unsigned long)buf + pgsz-1) & ~(pgsz-1)) + offset);
printf("id buffer=%p\n", id);
disk_identify_packet_device_command(fd, id, 512);
John
On 01/17/2011 10:27 AM, Tejun Heo wrote:
> Hello,
>
> On Sun, Jan 16, 2011 at 11:03:06PM -0500, John Stanley wrote:
>> The kernel-panic, which occurs at boot-time in udev/ata_id.c when
>> issuing an ioctl SG_IO sg3 SCSI ATA Pass-through Identify command,
>> appears to arise from DMA'ing into an incorrectly aligned user data
>> buffer pointed to by sg_io_hdr.dxferp .
> The problem is that nobody is DMA'ing in this case. The driver in
> question is ata_piix and the IO path taken is an actual PIO where the
> CPU reads from the IO space and writes to the memory itself.
>
>> My guess is that in the past, use of sg3 would not involve DMA by
>> default, but now, with libata ATA Pass-Through commands, it does (I
>> also may be totally wrong about that, just a thought).
> No DMA in progress here. The only (somewhat) recent related change
> would be libata PIO path now using 32bit IO commands when supported by
> the controller, but I fail to see how that would trigger this type of
> failures.
>
>> I recall documentaion somewhere which emphasized that if direct I/O
>> (DMA) is to used in sg, one should page-align the SCSI response data
>> buffer.. With sg using indirect I/O this wouldn't be necessary, of
>> course, but perhaps now with libata, it is. Just guessing here.
> If the buffer is not aligned, the kernel would just create a bounce
> buffer and bounce the data, so it shouldn't be a problem either. It
> looks like we have an obscure bug in buffer mapping code for SG_IO.
>
> I tried several things but can't reproduce the problem here. Can you
> please try the attached minimal test case? It issues IDENTIFY_PACKET
> and you can specify the alignment offset. By default the buffer would
> be 512byte aligned but you can offset it. ie. specifying 1 would make
> the buffer misaligned by 1 byte and so on.
>
> Can you please see whether the problem can be reliably triggered with
> it? Also, please,
>
> * Attach full kernel log (including boot messages) and the program
> output after triggering the problem.
>
> * Make sure the kernel is built with debug info and frame pointer.
>
> * Please reverse map the reported oops address to the source line.
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-01-17 17:33 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: linux-kernel, linux-hotplug, Steven Rostedt, Ingo Molnar,
Rusty Russell, Amit Kucheria
In-Reply-To: <20110117162105.GA1778@nowhere>
On 17 January 2011 10:21, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Mon, Jan 17, 2011 at 07:49:58AM -0600, Vincent Guittot wrote:
>> I was just wondering which tracepoints format between my 1st proposal
>> and yours was the easier to post process by an application like
>> pytimechart.
>
> No idea as pytimechart uses his own ad hoc event parsing. Either
> way there won't be much differences though.
>
>> I have updated the cpu hotplug tracepoint according to your remarks
>> and steve's ones. I have just replaced the second
>> cpu_arch_die_start/end in your proposal by cpu_arch_dead_start/endfrq
>
> Tracepoints tend to describe actions rather than states, although I can
> show you some exceptions as well. But this tends to be the major
> tendency. I suggest you to be stay consistent with this scheme.
>
For the cpu_die function which is called in the idle loop, we use
cpu_hotplug_arch_die_start/end
and for the __cpu_die function which waits for the cpu death, we could
use cpu_hotplug_arch_wait_death_start/end ?
as a summary we have :
cpu_hotplug_up_start/end
cpu_hotplug_down_start/end
cpu_hotplug_arch_up_start/end
cpu_hotplug_arch_disable_start/end
cpu_hotplug_arch_die_start/end
cpu_hotplug_arch_wait_death_start/end
> Thanks.
>
^ permalink raw reply
* Re: [PATCH] tracing, perf : add cpu hotplug trace events
From: Frederic Weisbecker @ 2011-01-17 16:21 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-hotplug, Steven Rostedt, Ingo Molnar,
Rusty Russell, Amit Kucheria
In-Reply-To: <AANLkTi=nugnkimG75Qh3t2vu8-qy2LKKHwoY2FFFpWDp@mail.gmail.com>
On Mon, Jan 17, 2011 at 07:49:58AM -0600, Vincent Guittot wrote:
> I was just wondering which tracepoints format between my 1st proposal
> and yours was the easier to post process by an application like
> pytimechart.
No idea as pytimechart uses his own ad hoc event parsing. Either
way there won't be much differences though.
> I have updated the cpu hotplug tracepoint according to your remarks
> and steve's ones. I have just replaced the second
> cpu_arch_die_start/end in your proposal by cpu_arch_dead_start/endfrq
Tracepoints tend to describe actions rather than states, although I can
show you some exceptions as well. But this tends to be the major
tendency. I suggest you to be stay consistent with this scheme.
Thanks.
^ permalink raw reply
* Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: Tejun Heo @ 2011-01-17 15:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D263BF6.6050305@verizon.net>
[-- Attachment #1: Type: text/plain, Size: 58 bytes --]
And, of course, forgot to attach. Here it is.
--
tejun
[-- Attachment #2: test-identify-packet.c --]
[-- Type: text/x-c++src, Size: 3283 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <scsi/sg.h>
#include <scsi/scsi_ioctl.h>
#include <linux/bsg.h>
#define COMMAND_TIMEOUT_MSEC (30 * 1000)
static int disk_identify_packet_device_command(int fd,
void *buf,
size_t buf_len)
{
struct sg_io_v4 io_v4;
uint8_t cdb[16];
uint8_t sense[32];
uint8_t *desc = sense+8;
int ret;
/*
* ATA Pass-Through 16 byte command, as described in
*
* T10 04-262r8 ATA Command Pass-Through
*
* from http://www.t10.org/ftp/t10/document.04/04-262r8.pdf
*/
memset(cdb, 0, sizeof(cdb));
cdb[0] = 0x85; /* OPERATION CODE: 16 byte pass through */
cdb[1] = 4 << 1; /* PROTOCOL: PIO Data-in */
cdb[2] = 0x2e; /* OFF_LINE=0, CK_COND=1, T_DIR=1, BYT_BLOK=1, T_LENGTH=2 */
cdb[3] = 0; /* FEATURES */
cdb[4] = 0; /* FEATURES */
cdb[5] = 0; /* SECTORS */
cdb[6] = 1; /* SECTORS */
cdb[7] = 0; /* LBA LOW */
cdb[8] = 0; /* LBA LOW */
cdb[9] = 0; /* LBA MID */
cdb[10] = 0; /* LBA MID */
cdb[11] = 0; /* LBA HIGH */
cdb[12] = 0; /* LBA HIGH */
cdb[13] = 0; /* DEVICE */
cdb[14] = 0xA1; /* Command: ATA IDENTIFY PACKET DEVICE */;
cdb[15] = 0; /* CONTROL */
memset(sense, 0, sizeof(sense));
memset(&io_v4, 0, sizeof(struct sg_io_v4));
io_v4.guard = 'Q';
io_v4.protocol = BSG_PROTOCOL_SCSI;
io_v4.subprotocol = BSG_SUB_PROTOCOL_SCSI_CMD;
io_v4.request_len = sizeof (cdb);
io_v4.request = (uintptr_t) cdb;
io_v4.max_response_len = sizeof (sense);
io_v4.response = (uintptr_t) sense;
io_v4.din_xfer_len = buf_len;
io_v4.din_xferp = (uintptr_t) buf;
io_v4.timeout = COMMAND_TIMEOUT_MSEC;
ret = ioctl(fd, SG_IO, &io_v4);
if (ret != 0) {
/* could be that the driver doesn't do version 4, try version 3 */
if (errno == EINVAL) {
struct sg_io_hdr io_hdr;
memset(&io_hdr, 0, sizeof(struct sg_io_hdr));
io_hdr.interface_id = 'S';
io_hdr.cmdp = (unsigned char*) cdb;
io_hdr.cmd_len = sizeof (cdb);
io_hdr.dxferp = buf;
io_hdr.dxfer_len = buf_len;
io_hdr.sbp = sense;
io_hdr.mx_sb_len = sizeof (sense);
io_hdr.dxfer_direction = SG_DXFER_FROM_DEV;
io_hdr.timeout = COMMAND_TIMEOUT_MSEC;
ret = ioctl(fd, SG_IO, &io_hdr);
if (ret != 0)
goto out;
} else {
goto out;
}
}
if (!(sense[0] == 0x72 && desc[0] == 0x9 && desc[1] == 0x0c)) {
errno = EIO;
ret = -1;
goto out;
}
out:
return ret;
}
int main(int argc, char *argv[])
{
char buf[2048];
char *id;
char *path;
int offset = 0;
int fd;
FILE *fp;
if (argc < 2) {
fprintf(stderr,
"Usage: test-identify-packet /dev/srX [OFFSET]\n");
return 1;
}
path = argv[1];
if (argc > 2)
offset = atoi(argv[2]);
if (offset < 0 || offset > 512) {
fprintf(stderr, "offset out of range\n");
return 1;
}
fd = open(path, O_RDONLY|O_NONBLOCK);
if (fd < 0) {
perror("open");
return 1;
}
fp = popen("hexdump -Cv", "w");
if (!fp) {
perror("popen");
return 1;
}
id = (void *)((((unsigned long)buf + 511) & ~511) + offset);
printf("id buffer=%p\n", id);
disk_identify_packet_device_command(fd, id, 512);
fwrite(id, 512, 1, fp);
fclose(fp);
return 0;
}
^ permalink raw reply
* Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: Tejun Heo @ 2011-01-17 15:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D263BF6.6050305@verizon.net>
Hello,
On Sun, Jan 16, 2011 at 11:03:06PM -0500, John Stanley wrote:
> The kernel-panic, which occurs at boot-time in udev/ata_id.c when
> issuing an ioctl SG_IO sg3 SCSI ATA Pass-through Identify command,
> appears to arise from DMA'ing into an incorrectly aligned user data
> buffer pointed to by sg_io_hdr.dxferp .
The problem is that nobody is DMA'ing in this case. The driver in
question is ata_piix and the IO path taken is an actual PIO where the
CPU reads from the IO space and writes to the memory itself.
> My guess is that in the past, use of sg3 would not involve DMA by
> default, but now, with libata ATA Pass-Through commands, it does (I
> also may be totally wrong about that, just a thought).
No DMA in progress here. The only (somewhat) recent related change
would be libata PIO path now using 32bit IO commands when supported by
the controller, but I fail to see how that would trigger this type of
failures.
> I recall documentaion somewhere which emphasized that if direct I/O
> (DMA) is to used in sg, one should page-align the SCSI response data
> buffer.. With sg using indirect I/O this wouldn't be necessary, of
> course, but perhaps now with libata, it is. Just guessing here.
If the buffer is not aligned, the kernel would just create a bounce
buffer and bounce the data, so it shouldn't be a problem either. It
looks like we have an obscure bug in buffer mapping code for SG_IO.
I tried several things but can't reproduce the problem here. Can you
please try the attached minimal test case? It issues IDENTIFY_PACKET
and you can specify the alignment offset. By default the buffer would
be 512byte aligned but you can offset it. ie. specifying 1 would make
the buffer misaligned by 1 byte and so on.
Can you please see whether the problem can be reliably triggered with
it? Also, please,
* Attach full kernel log (including boot messages) and the program
output after triggering the problem.
* Make sure the kernel is built with debug info and frame pointer.
* Please reverse map the reported oops address to the source line.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-01-17 13:49 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: linux-kernel, linux-hotplug, Steven Rostedt, Ingo Molnar,
Rusty Russell, Amit Kucheria
In-Reply-To: <20110114183516.GB1926@nowhere>
On 14 January 2011 12:35, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Fri, Jan 07, 2011 at 07:25:08PM +0100, Vincent Guittot wrote:
>> On 7 January 2011 16:12, Frederic Weisbecker <fweisbec@gmail.com> wrote:
>> >> +
>> >> + TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
>> >
>> > I feel a bit uncomfortable with these opaque type and step.
>> >
>> > What about splitting the events:
>> >
>> > cpu_down_start
>> > cpu_down_end
>> >
>> > cpu_up_start
>> > cpu_up_end
>> >
>> > This ways they are much more self-explanatory.
>> >
>> > I also feel uncomfortable about exposing arch step details in core
>> > tracepoints.
>> >
>> > But if we consider the following sequence:
>> >
>> > cpu_down() {
>> > __cpu_disable() {
>> > platform_cpu_disable();
>> > }
>> > }
>> >
>> > Then exposing start/end of cpu_disable() makes sense, by way of:
>> >
>> > cpu_arch_disable_start
>> > cpu_arch_disable_end
>> >
>> > cpu_arch_enable_start
>> > cpu_arch_enable_end
>> >
>> >
>> > cpu_arch_die_start
>> > cpu_arch_die_end
>> >
>> > cpu_arch_die_start
>> > cpu_arch_die_end
>> >
>> > Because they are arch events that you can retrieve everywhere, the tracepoints
>> > are still called from the code code.
>> >
>> > Now for the machine part, it's very highly arch specific, most notably for arm
>> > so I wonder if it would make more sense to keep that seperate into arch
>> > tracepoints.
>> >
>>
>> May be we could find some event names that matches for all system and
>> that can be kept in the same file ?
>
> But that's only an ARM concern, right? So ARM can create its own
> set of tracepoints for that. If that becomes more widely useful then
> we can think about gathering the whole into a single file.
>
OK, we can do like that
>> > How does that all look? I hope I'm not overengineering.
>> >
>>
>> that's could be ok for me, I can find almost the same kind of
>> information with this solution. I just wonder what traces are the
>> easiest to treat for extracting some latency measurement or to treat
>> with other event like the power event.
>
> Hmm, I'm not sure what you mean. You want to know which tracepoints
> can be useful to measure latencies? Well, it depends on what kind
> of latency you seek in general: scheduler, io, etc...
>
I was just wondering which tracepoints format between my 1st proposal
and yours was the easier to post process by an application like
pytimechart.
I have updated the cpu hotplug tracepoint according to your remarks
and steve's ones. I have just replaced the second
cpu_arch_die_start/end in your proposal by cpu_arch_dead_start/endfrq
^ permalink raw reply
* Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: John Stanley @ 2011-01-17 5:07 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D263BF6.6050305@verizon.net>
Some additional info: Several weeks ago, for one laptop which has no
cd/dvd drives on which I installed udev-165, I got a similar
kernel-panic (udevd tainted) seveal times, so the issue appears to not
necessarily be tightly coupled to cd drives.
John
On 01/11/2011 08:25 AM, Tejun Heo wrote:
> Hello,
>
> On Mon, Jan 10, 2011 at 09:10:12AM +0100, Hannes Reinecke wrote:
>>> First, sorry for not posting something about this sooner - I'd
>>> pinged Kay on IRC about it, and I *promise* I had planned to
>>> forward it to the scsi/ati guys, but work has been hell this
>>> week. Anyway, here's the initial report we got about it, along
>>> with a lot of debugging by other folks (including the OP, who
>>> I think is 'resonance' in that thread):
>>> http://www.linuxquestions.org/questions/slackware-14/current-randomly-timed-kernel-oops-on-bootup-of-two-test-boxen-852843/
>>>
>> It's all Tejun's fault.
> Gees, Hannes. That's very kind of you. :-P
>
>> kernel crashing in ata_sff_data_xfer / ioread32 ...
>> Looks like we're trying a read to a page which wasn't
>> mapped/allocated properly.
>>
>> And yes, it definitely should be fixed in the kernel first.
> Yeah, definitely. It isn't clear from the thread.
>
> * Is it a regression?
>
> * Can this be triggered by simply running ata_id or does it need any
> other condition to trigger?
>
> I don't recall any related change in the area, at least in libata, so
> it's a bit surprising. If it's a regression, I think it's more likely
> to be something between userland and libata. The user buffer mapping
> code for sg commands is quite scary after all.
>
> Thanks.
>
^ permalink raw reply
* Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: John Stanley @ 2011-01-17 4:03 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D263BF6.6050305@verizon.net>
On looking at this issue a bit further (please note (and be foregiving),
I know very little about the kernel/SCSI implementation), it looks more
and more to be very similar to another kernel-panic issue posted some 6
months ago (http://www.spinics.net/lists/linux-scsi/msg44077.html).
The kernel-panic, which occurs at boot-time in udev/ata_id.c when
issuing an ioctl SG_IO sg3 SCSI ATA Pass-through Identify command,
appears to arise from DMA'ing into an incorrectly aligned user data
buffer pointed to by sg_io_hdr.dxferp .
My guess is that in the past, use of sg3 would not involve DMA by
default, but now, with libata ATA Pass-Through commands, it does (I also
may be totally wrong about that, just a thought). I recall documentaion
somewhere which emphasized that if direct I/O (DMA) is to used in sg,
one should page-align the SCSI response data buffer.. With sg using
indirect I/O this wouldn't be necessary, of course, but perhaps now with
libata, it is. Just guessing here.
If I patch ata_id.c to use a page-aligned *sg_io_hdr.dxferp, the
kernel-panic goes away.
The same kernel-panic (same traceback) also occurs in sg__sat_identify.c
(sg3-utils-1.30) once the system is running, issuing, eg,
sg__sat_identify -vv -p /dev/dvd
Patching sg__sat_identify.c in the same way eliminates the kernel-panic
here as well. The code in sg__sat_identify.c and ata_id.c implementing
the sg3 SCSI ATA Pass-through Identify command is more or less the same.
Here's the relevant (vanilla linux-2.6.37) kernel code path, beginning in
drivers/scsi/sg.c (@NNN = at line number):
sg_ioctl @772 in drivers/scsi/sg.c
sg_new_write @801 in drivers/scsi/sg.c
sg_common_write @708 in drivers/scsi/sg.c
sg_start_req @735 in drivers/scsi/sg.c
blk_rq_map_user @1707 in drivers/scsi/sg.c
__blk_rq_map_user @142 in block/blk-map.c
blk_rq_aligned @57 in block/blk-map.c
queue_dma_alignment @1060 in include/linux/blkdev.h
include/linux/blkdev.h
1057 static inline int blk_rq_aligned(struct request_queue *q, unsigned
long addr,
1058 unsigned int len)
1059 {
1060 unsigned int alignment = queue_dma_alignment(q) |
q->dma_pad_mask;
1061 return !(addr & alignment) && !(len & alignment);
1062 }
1052 static inline int queue_dma_alignment(struct request_queue *q)
1053 {
1054 return q ? q->dma_alignment : 511;
1055 }
In drivers/scsi/scsi_lib.c (request_queue @1609) we get a default 2-byte
alignment mask (possibly overridden later by the kernel or underlying
driver I assume), which is then used in queue_dma_alignment @1054 in
include/linux/blkdev.h
So, for the current drive(s) at hand, as noted in
http://www.spinics.net/lists/linux-scsi/msg44077.html),
if the driver (and/or kernel) does not override the default 2-byte
alignment mask, and such an alignment
is inappropriate, we may have problems when DMA-ing into the specified
user data buffer pointed to
by sg_io_hdr.dxferp .
In conclusion, then, it would seem that some cd drive/controllers either
incorrectly specify (or don't specify) DMA buffer alignment
requirements, or that the kernel uses inappropriate alignments in some
cases on its own.
I'm not sure where or how to fix this in the kernel, aside from using a
default page-alignemet in drivers/scsi/scsi_lib.c (rather than 2-byte)
(line 1648); this, however, is probably way too 'blunt' and may impact
other drivers and/or system performance ...:
drivers/scsi/scsi_lib.c
1609 struct request_queue *__scsi_alloc_queue(struct Scsi_Host *shost,
1610 request_fn_proc *request_fn)
1611 {
.
.
1643 /*
1644 * set a reasonable default alignment on word boundaries: the
1645 * host and device may alter it using
1646 * blk_queue_update_dma_alignment() later.
1647 */
1648 blk_queue_dma_alignment(q, 0x03); <--- Use PAGESIZE-1,
rather than 0x03 ?
.
.
Any thoughts ?
thanks much for everyone's time,
John
On 01/11/2011 08:25 AM, Tejun Heo wrote:
> Hello,
>
> On Mon, Jan 10, 2011 at 09:10:12AM +0100, Hannes Reinecke wrote:
>>> First, sorry for not posting something about this sooner - I'd
>>> pinged Kay on IRC about it, and I *promise* I had planned to
>>> forward it to the scsi/ati guys, but work has been hell this
>>> week. Anyway, here's the initial report we got about it, along
>>> with a lot of debugging by other folks (including the OP, who
>>> I think is 'resonance' in that thread):
>>> http://www.linuxquestions.org/questions/slackware-14/current-randomly-timed-kernel-oops-on-bootup-of-two-test-boxen-852843/
>>>
>> It's all Tejun's fault.
> Gees, Hannes. That's very kind of you. :-P
>
>> kernel crashing in ata_sff_data_xfer / ioread32 ...
>> Looks like we're trying a read to a page which wasn't
>> mapped/allocated properly.
>>
>> And yes, it definitely should be fixed in the kernel first.
> Yeah, definitely. It isn't clear from the thread.
>
> * Is it a regression?
>
> * Can this be triggered by simply running ata_id or does it need any
> other condition to trigger?
>
> I don't recall any related change in the area, at least in libata, so
> it's a bit surprising. If it's a regression, I think it's more likely
> to be something between userland and libata. The user buffer mapping
> code for sg commands is quite scary after all.
>
> Thanks.
>
^ permalink raw reply
* Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: John Stanley @ 2011-01-17 3:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D263BF6.6050305@verizon.net>
* Can this be triggered by simply running ata_id or does it need any
other condition to trigger?
Yes, once the system has booted, issuing
lib/udev/ata_id-unpatched /dev/dvd
produces the same kernel panic nearly every time. Also, as I mentioned
earlier, the sg__sat_identify utility from sg3-utils-1.30 does the same
on 1-3 attempts out of 10; i.e., issuing
sg__sat_identify -vv -p /dev/dvd
On 01/11/2011 08:25 AM, Tejun Heo wrote:
> Hello,
>
> On Mon, Jan 10, 2011 at 09:10:12AM +0100, Hannes Reinecke wrote:
>>> First, sorry for not posting something about this sooner - I'd
>>> pinged Kay on IRC about it, and I *promise* I had planned to
>>> forward it to the scsi/ati guys, but work has been hell this
>>> week. Anyway, here's the initial report we got about it, along
>>> with a lot of debugging by other folks (including the OP, who
>>> I think is 'resonance' in that thread):
>>> http://www.linuxquestions.org/questions/slackware-14/current-randomly-timed-kernel-oops-on-bootup-of-two-test-boxen-852843/
>>>
>> It's all Tejun's fault.
> Gees, Hannes. That's very kind of you. :-P
>
>> kernel crashing in ata_sff_data_xfer / ioread32 ...
>> Looks like we're trying a read to a page which wasn't
>> mapped/allocated properly.
>>
>> And yes, it definitely should be fixed in the kernel first.
> Yeah, definitely. It isn't clear from the thread.
>
> * Is it a regression?
>
> * Can this be triggered by simply running ata_id or does it need any
> other condition to trigger?
>
> I don't recall any related change in the area, at least in libata, so
> it's a bit surprising. If it's a regression, I think it's more likely
> to be something between userland and libata. The user buffer mapping
> code for sg commands is quite scary after all.
>
> Thanks.
>
^ permalink raw reply
* Proper way to get USB class codes
From: José Félix Ontañón @ 2011-01-15 18:26 UTC (permalink / raw)
To: linux-hotplug
Hello everybody,
I've got some doubts and problems getting USB class codes via udev and
i'll be very grateful if someone could clarify.
First of all, using udevadm i've realized some usb devices left the
class/subclass/protocol attributes with 00:
ATTR{bDeviceClass}="00"
ATTR{bDeviceSubClass}="00"
ATTR{bDeviceProtocol}="00"
Is that an issue on the usb device itself or an issue on udev reading
usb device/interface descriptor?
Second, i've some doubts about when should I use the
ID_USB_INTERFACES, TYPE or INTERFACE property: in which cases should I
use one or another? Why the TYPE property sometimes appear as 0/0/0
even when the ID_USB_INTERFACES and INTERFACE properties are filled?
Thanks for sharing your thoughs.
--
http://fontanon.org
^ permalink raw reply
* Re: [PATCH] tracing, perf : add cpu hotplug trace events
From: Frederic Weisbecker @ 2011-01-14 18:35 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-hotplug, Steven Rostedt, Ingo Molnar,
Rusty Russell, Amit Kucheria
In-Reply-To: <AANLkTi=L3=_2dzHH4Wu6QWXw=AUjxtrAu60xfM3-Qwn4@mail.gmail.com>
On Fri, Jan 07, 2011 at 07:25:08PM +0100, Vincent Guittot wrote:
> On 7 January 2011 16:12, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> >> +
> >> + TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
> >
> > I feel a bit uncomfortable with these opaque type and step.
> >
> > What about splitting the events:
> >
> > cpu_down_start
> > cpu_down_end
> >
> > cpu_up_start
> > cpu_up_end
> >
> > This ways they are much more self-explanatory.
> >
> > I also feel uncomfortable about exposing arch step details in core
> > tracepoints.
> >
> > But if we consider the following sequence:
> >
> > cpu_down() {
> > __cpu_disable() {
> > platform_cpu_disable();
> > }
> > }
> >
> > Then exposing start/end of cpu_disable() makes sense, by way of:
> >
> > cpu_arch_disable_start
> > cpu_arch_disable_end
> >
> > cpu_arch_enable_start
> > cpu_arch_enable_end
> >
> >
> > cpu_arch_die_start
> > cpu_arch_die_end
> >
> > cpu_arch_die_start
> > cpu_arch_die_end
> >
> > Because they are arch events that you can retrieve everywhere, the tracepoints
> > are still called from the code code.
> >
> > Now for the machine part, it's very highly arch specific, most notably for arm
> > so I wonder if it would make more sense to keep that seperate into arch
> > tracepoints.
> >
>
> May be we could find some event names that matches for all system and
> that can be kept in the same file ?
But that's only an ARM concern, right? So ARM can create its own
set of tracepoints for that. If that becomes more widely useful then
we can think about gathering the whole into a single file.
> > How does that all look? I hope I'm not overengineering.
> >
>
> that's could be ok for me, I can find almost the same kind of
> information with this solution. I just wonder what traces are the
> easiest to treat for extracting some latency measurement or to treat
> with other event like the power event.
Hmm, I'm not sure what you mean. You want to know which tracepoints
can be useful to measure latencies? Well, it depends on what kind
of latency you seek in general: scheduler, io, etc...
^ permalink raw reply
* Re: libudev and /sys/devices/system/cpu
From: Greg KH @ 2011-01-13 19:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <A0B1A1FD-CDA5-4333-B2CD-B686A8FBF3E9@gmail.com>
On Thu, Jan 13, 2011 at 08:21:02PM +0100, Martin Grund wrote:
> Hi,
>
> I try to access the info stored in /sys/devices/system/cpu to gather
> information about available CPUs and their architecture ( cache size,
> levels etc). However, when enumerating over devices and subsystems
> using udev_enumerate_scan_devices() and
> udev_enumerate_scan_subsystems() the result list does not contain any
> entry from /sys/devices/system.
That's because the entries there are not "real" devices as far as the
kernel is concerned.
It's a real problem, and Kay has some initial patches floating around
for the kernel to resolve this issue. I just need to get some spare
time to look them over and get them accepted into the kernel tree.
sorry,
greg k-h
^ permalink raw reply
* libudev and /sys/devices/system/cpu
From: Martin Grund @ 2011-01-13 19:21 UTC (permalink / raw)
To: linux-hotplug
Hi,
I try to access the info stored in /sys/devices/system/cpu to gather information about available CPUs and their architecture ( cache size, levels etc). However, when enumerating over devices and subsystems using udev_enumerate_scan_devices() and udev_enumerate_scan_subsystems() the result list does not contain any entry from /sys/devices/system.
In addition, I tried to get the device using udev_device_new_from_syspath() but this was unsuccessful as well.
What is the best way to read the contents from /sys/devices/system?
Thank you very much in advance,
Martin
^ permalink raw reply
* udev problem during system boot
From: Ulrich Leschinski @ 2011-01-12 19:00 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 842 bytes --]
Hi,
since Ubutuntu 10.04 my homeserver does not boot from time to time. It gets stuck with "ureadahead exits with status 4". The system has a 8GB IDE flash drive from TRANSCEND. I use it as system drive with one partition. Four other SATA HDs are configured as two RAID 1. Normally, the flash drive gets /dev/sde1 assigned, but sometimes it gets /dev/sda1 during booting. This is the case where it fails, as the others drive names are also different.
I attached two dmesg logs. You can easily see the differences. They start with udev. I hope that you can figure out what causes the different behaviour of udev when assigning the drive names. I also need a solution to this problem. There must be something wrong, as with previous Ubuntu versions I had no problems!
Thanks you in advance!
With best regards,
Ulrich Leschinski
[-- Attachment #2: dmesg.logs.gz --]
[-- Type: application/x-gzip, Size: 21473 bytes --]
^ permalink raw reply
* Re: sys-fs/udev-0151-r4 : there're a lot of borken symlinks in
From: Kay Sievers @ 2011-01-12 18:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201101121933.21982.toralf.foerster@gmx.de>
2011/1/12 Toralf Förster <toralf.foerster@gmx.de>:
> This command
> $> find -L /dev/.udev/db/ -type l -print0 | xargs -0 -n 1 ls -l > /tmp/broken.txt
> at my stable Gentoo gives 123 entries w/ current kernel. Situation is similar
> w/ older kernels. I'm wondering whether this is expected or not.
All fine. They don't point anywhere, they just store data.
Kay
^ permalink raw reply
* Re: sys-fs/udev-0151-r4 : there're a lot of borken symlinks in
From: Marco d'Itri @ 2011-01-12 18:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201101121933.21982.toralf.foerster@gmx.de>
On Jan 12, Toralf Förster <toralf.foerster@gmx.de> wrote:
> This command
> $> find -L /dev/.udev/db/ -type l -print0 | xargs -0 -n 1 ls -l > /tmp/broken.txt
> at my stable Gentoo gives 123 entries w/ current kernel. Situation is similar
> w/ older kernels. I'm wondering whether this is expected or not.
It is.
--
ciao,
Marco
^ permalink raw reply
* sys-fs/udev-0151-r4 : there're a lot of borken symlinks in
From: Toralf Förster @ 2011-01-12 18:33 UTC (permalink / raw)
To: linux-hotplug
This command
$> find -L /dev/.udev/db/ -type l -print0 | xargs -0 -n 1 ls -l > /tmp/broken.txt
at my stable Gentoo gives 123 entries w/ current kernel. Situation is similar
w/ older kernels. I'm wondering whether this is expected or not.
lrwxrwxrwx 1 root root 17 Jan 12 19:27 /dev/.udev/db/vc:vcsa12 -> vcsa12 char/7:140
lrwxrwxrwx 1 root root 15 Jan 12 19:27 /dev/.udev/db/vc:vcs12 -> vcs12 char/7:12
lrwxrwxrwx 1 root root 17 Jan 12 19:27 /dev/.udev/db/vc:vcsa11 -> vcsa11 char/7:139
lrwxrwxrwx 1 root root 15 Jan 12 19:27 /dev/.udev/db/vc:vcs11 -> vcs11 char/7:11
lrwxrwxrwx 1 root root 17 Jan 12 19:27 /dev/.udev/db/vc:vcsa10 -> vcsa10 char/7:138
lrwxrwxrwx 1 root root 15 Jan 12 19:27 /dev/.udev/db/vc:vcs10 -> vcs10 char/7:10
lrwxrwxrwx 1 root root 16 Jan 12 19:27 /dev/.udev/db/vc:vcsa9 -> vcsa9 char/7:137
lrwxrwxrwx 1 root root 13 Jan 12 19:27 /dev/.udev/db/vc:vcs9 -> vcs9 char/7:9
lrwxrwxrwx 1 root root 16 Jan 12 19:27 /dev/.udev/db/vc:vcsa8 -> vcsa8 char/7:136
lrwxrwxrwx 1 root root 13 Jan 12 19:27 /dev/.udev/db/vc:vcs8 -> vcs8 char/7:8
lrwxrwxrwx 1 root root 16 Jan 12 19:27 /dev/.udev/db/vc:vcsa7 -> vcsa7 char/7:135
lrwxrwxrwx 1 root root 13 Jan 12 19:27 /dev/.udev/db/vc:vcs7 -> vcs7 char/7:7
lrwxrwxrwx 1 root root 16 Jan 12 19:27 /dev/.udev/db/vc:vcsa6 -> vcsa6 char/7:134
lrwxrwxrwx 1 root root 13 Jan 12 19:27 /dev/.udev/db/vc:vcs6 -> vcs6 char/7:6
lrwxrwxrwx 1 root root 16 Jan 12 19:27 /dev/.udev/db/vc:vcsa5 -> vcsa5 char/7:133
lrwxrwxrwx 1 root root 13 Jan 12 19:27 /dev/.udev/db/vc:vcs5 -> vcs5 char/7:5
lrwxrwxrwx 1 root root 16 Jan 12 19:27 /dev/.udev/db/vc:vcsa4 -> vcsa4 char/7:132
lrwxrwxrwx 1 root root 13 Jan 12 19:27 /dev/.udev/db/vc:vcs4 -> vcs4 char/7:4
lrwxrwxrwx 1 root root 16 Jan 12 19:27 /dev/.udev/db/vc:vcsa3 -> vcsa3 char/7:131
lrwxrwxrwx 1 root root 13 Jan 12 19:27 /dev/.udev/db/vc:vcs3 -> vcs3 char/7:3
lrwxrwxrwx 1 root root 16 Jan 12 19:27 /dev/.udev/db/vc:vcsa2 -> vcsa2 char/7:130
lrwxrwxrwx 1 root root 13 Jan 12 19:27 /dev/.udev/db/vc:vcs2 -> vcs2 char/7:2
lrwxrwxrwx 1 root root 16 Jan 12 2011 /dev/.udev/db/misc:fuse -> fuse char/10:229
lrwxrwxrwx 1 root root 26 Jan 12 2011 /dev/.udev/db/misc:device-mapper -> mapper/control char/10:236
lrwxrwxrwx 1 root root 26 Jan 12 2011 /dev/.udev/db/drm:controlD64 -> dri/controlD64 char/226:64
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/graphics:fb0 -> fb0 char/29:0
lrwxrwxrwx 1 root root 25 Jan 12 2011 /dev/.udev/db/usb:lp0 -> usb/lp0 char/180:0 usblp0
lrwxrwxrwx 1 root root 19 Jan 12 2011 /dev/.udev/db/misc:agpgart -> agpgart char/10:175
lrwxrwxrwx 1 root root 21 Jan 12 2011 /dev/.udev/db/input:mice -> input/mice char/13:63
lrwxrwxrwx 1 root root 22 Jan 12 2011 /dev/.udev/db/bsg:1:0:0:0 -> bsg/1:0:0:0 char/254:1
lrwxrwxrwx 1 root root 17 Jan 12 2011 /dev/.udev/db/misc:rfkill -> rfkill char/10:59
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:ttyS0 -> ttyS0 char/4:64
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:ttyS3 -> ttyS3 char/4:67
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:ttyS2 -> ttyS2 char/4:66
lrwxrwxrwx 1 root root 17 Jan 12 2011 /dev/.udev/db/misc:nvram -> nvram char/10:144
lrwxrwxrwx 1 root root 16 Jan 12 2011 /dev/.udev/db/vc:vcsa1 -> vcsa1 char/7:129
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/vc:vcsa -> vcsa char/7:128
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/vc:vcs1 -> vcs1 char/7:1
lrwxrwxrwx 1 root root 12 Jan 12 2011 /dev/.udev/db/vc:vcs -> vcs char/7:0
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/tty:tty9 -> tty9 char/4:9
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/tty:tty8 -> tty8 char/4:8
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/tty:tty7 -> tty7 char/4:7
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty63 -> tty63 char/4:63
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty62 -> tty62 char/4:62
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty61 -> tty61 char/4:61
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty60 -> tty60 char/4:60
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/tty:tty6 -> tty6 char/4:6
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty59 -> tty59 char/4:59
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty58 -> tty58 char/4:58
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty57 -> tty57 char/4:57
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty56 -> tty56 char/4:56
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty55 -> tty55 char/4:55
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty54 -> tty54 char/4:54
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty53 -> tty53 char/4:53
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty52 -> tty52 char/4:52
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty51 -> tty51 char/4:51
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty50 -> tty50 char/4:50
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/tty:tty5 -> tty5 char/4:5
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty49 -> tty49 char/4:49
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty48 -> tty48 char/4:48
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty47 -> tty47 char/4:47
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty46 -> tty46 char/4:46
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty45 -> tty45 char/4:45
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty44 -> tty44 char/4:44
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty43 -> tty43 char/4:43
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty42 -> tty42 char/4:42
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty41 -> tty41 char/4:41
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty40 -> tty40 char/4:40
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/tty:tty4 -> tty4 char/4:4
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty39 -> tty39 char/4:39
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty38 -> tty38 char/4:38
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty37 -> tty37 char/4:37
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty36 -> tty36 char/4:36
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty35 -> tty35 char/4:35
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty34 -> tty34 char/4:34
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty33 -> tty33 char/4:33
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty32 -> tty32 char/4:32
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty31 -> tty31 char/4:31
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty30 -> tty30 char/4:30
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/tty:tty3 -> tty3 char/4:3
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty29 -> tty29 char/4:29
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty28 -> tty28 char/4:28
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty27 -> tty27 char/4:27
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty26 -> tty26 char/4:26
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty25 -> tty25 char/4:25
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty24 -> tty24 char/4:24
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty23 -> tty23 char/4:23
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty22 -> tty22 char/4:22
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty21 -> tty21 char/4:21
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty20 -> tty20 char/4:20
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/tty:tty2 -> tty2 char/4:2
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty19 -> tty19 char/4:19
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty18 -> tty18 char/4:18
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty17 -> tty17 char/4:17
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty16 -> tty16 char/4:16
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty15 -> tty15 char/4:15
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty14 -> tty14 char/4:14
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty13 -> tty13 char/4:13
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty12 -> tty12 char/4:12
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty11 -> tty11 char/4:11
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/tty:tty10 -> tty10 char/4:10
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/tty:tty1 -> tty1 char/4:1
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/tty:tty0 -> tty0 char/4:0
lrwxrwxrwx 1 root root 12 Jan 12 2011 /dev/.udev/db/tty:tty -> tty char/5:0
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/tty:ptmx -> ptmx char/5:2
lrwxrwxrwx 1 root root 16 Jan 12 2011 /dev/.udev/db/tty:console -> console char/5:1
lrwxrwxrwx 1 root root 22 Jan 12 2011 /dev/.udev/db/misc:vga_arbiter -> vga_arbiter char/10:63
lrwxrwxrwx 1 root root 20 Jan 12 2011 /dev/.udev/db/misc:snapshot -> snapshot char/10:231
lrwxrwxrwx 1 root root 29 Jan 12 2011 /dev/.udev/db/misc:network_throughput -> network_throughput char/10:60
lrwxrwxrwx 1 root root 26 Jan 12 2011 /dev/.udev/db/misc:network_latency -> network_latency char/10:61
lrwxrwxrwx 1 root root 18 Jan 12 2011 /dev/.udev/db/misc:mcelog -> mcelog char/10:227
lrwxrwxrwx 1 root root 16 Jan 12 2011 /dev/.udev/db/misc:hpet -> hpet char/10:228
lrwxrwxrwx 1 root root 26 Jan 12 2011 /dev/.udev/db/misc:cpu_dma_latency -> cpu_dma_latency char/10:62
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/mem:zero -> zero char/1:5
lrwxrwxrwx 1 root root 16 Jan 12 2011 /dev/.udev/db/mem:urandom -> urandom char/1:9
lrwxrwxrwx 1 root root 15 Jan 12 2011 /dev/.udev/db/mem:random -> random char/1:8
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/mem:port -> port char/1:4
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/mem:null -> null char/1:3
lrwxrwxrwx 1 root root 12 Jan 12 2011 /dev/.udev/db/mem:mem -> mem char/1:1
lrwxrwxrwx 1 root root 14 Jan 12 2011 /dev/.udev/db/mem:kmsg -> kmsg char/1:11
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/mem:kmem -> kmem char/1:2
lrwxrwxrwx 1 root root 13 Jan 12 2011 /dev/.udev/db/mem:full -> full char/1:7
lrwxrwxrwx 1 root root 22 Jan 12 2011 /dev/.udev/db/bsg:0:0:0:0 -> bsg/0:0:0:0 char/254:0
--
MfG/Kind regards
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply
* Any plan to restore path_id for SAS devices?
From: tomm @ 2011-01-11 20:32 UTC (permalink / raw)
To: linux-hotplug
This got removed some versions back during the conversion from script to C code.
There is an "unofficial" patch for udev-164 floating around, but it would be
nice to have this restored.
^ permalink raw reply
* Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: Tejun Heo @ 2011-01-11 13:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D263BF6.6050305@verizon.net>
Hello,
On Mon, Jan 10, 2011 at 09:10:12AM +0100, Hannes Reinecke wrote:
> > First, sorry for not posting something about this sooner - I'd
> > pinged Kay on IRC about it, and I *promise* I had planned to
> > forward it to the scsi/ati guys, but work has been hell this
> > week. Anyway, here's the initial report we got about it, along
> > with a lot of debugging by other folks (including the OP, who
> > I think is 'resonance' in that thread):
> > http://www.linuxquestions.org/questions/slackware-14/current-randomly-timed-kernel-oops-on-bootup-of-two-test-boxen-852843/
> >
> It's all Tejun's fault.
Gees, Hannes. That's very kind of you. :-P
> kernel crashing in ata_sff_data_xfer / ioread32 ...
> Looks like we're trying a read to a page which wasn't
> mapped/allocated properly.
>
> And yes, it definitely should be fixed in the kernel first.
Yeah, definitely. It isn't clear from the thread.
* Is it a regression?
* Can this be triggered by simply running ata_id or does it need any
other condition to trigger?
I don't recall any related change in the area, at least in libata, so
it's a bit surprising. If it's a regression, I think it's more likely
to be something between userland and libata. The user buffer mapping
code for sg commands is quite scary after all.
Thanks.
--
tejun
^ permalink raw reply
* RE: [PATCH] Export ACPI _DSM provided firmware instance number and
From: Narendra_K @ 2011-01-10 19:35 UTC (permalink / raw)
To: jbarnes
Cc: Matt_Domsch, linux-pci, linux-hotplug, netdev, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <20110110111300.58e6bbea@jbarnes-desktop>
> -----Original Message-----
> From: Jesse Barnes [mailto:jbarnes@virtuousgeek.org]
> Sent: Tuesday, January 11, 2011 12:43 AM
> To: K, Narendra
> Cc: Domsch, Matt; linux-pci@vger.kernel.org; linux-
> hotplug@vger.kernel.org; netdev@vger.kernel.org; Hargrave, Jordan;
> Rose, Charles; Nijhawan, Vijay
> Subject: Re: [PATCH] Export ACPI _DSM provided firmware instance number
> and string name to sysfs
>
> On Mon, 10 Jan 2011 10:48:26 -0800
> <Narendra_K@Dell.com> wrote:
> > > > > 'label' is fine for either case, with ACPI taking priority over
> > > > > SMBIOS if both happen to be present.
> > > > >
> > >
> > > Applied, thanks.
> >
> > Jesse,
> >
> > Thank you.
>
> Not sure if you saw it yet, but the patch caused a build breakage. Can
> you send me a replacement patch with a fix asap?
>
> Thanks,
Just saw it now. Sorry for the inconvenience. I took the patch against linux-2.6 where I did not see the failure. I am pulling the linux-next now, will get this resolved first thing tomorrow.
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH] Export ACPI _DSM provided firmware instance number and
From: Jesse Barnes @ 2011-01-10 19:13 UTC (permalink / raw)
To: Narendra_K
Cc: Matt_Domsch, linux-pci, linux-hotplug, netdev, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <E31FB011129F30488D5861F3839049151D10F8EF9D@BLRX7MCDC201.AMER.DELL.COM>
On Mon, 10 Jan 2011 10:48:26 -0800
<Narendra_K@Dell.com> wrote:
> > > > 'label' is fine for either case, with ACPI taking priority over
> > > > SMBIOS if both happen to be present.
> > > >
> >
> > Applied, thanks.
>
> Jesse,
>
> Thank you.
Not sure if you saw it yet, but the patch caused a build breakage. Can
you send me a replacement patch with a fix asap?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox