Re: [rtc-linux] state of GEN_RTC vs rtc subsystem
On Wed, 20 Feb 2008 18:03:25 +0100, Alessandro Zummo <[EMAIL PROTECTED]> wrote: > On Wed, 20 Feb 2008 10:11:23 -0600 > Kumar Gala <[EMAIL PROTECTED]> wrote: > > > > > Is the functionality provided by drivers/char/gen_rtc.c completely > > handled by the rtc subsystem in drivers/rtc? > > > > I ask for two reasons: > > 1. should we make it mutually exclusive in Kconfig > > 2. I've enabled both and get (we'll my defconfig did): > > They shouldn't be enabled at once. I think a patch > for Kconfig has been recently submitted to give a warning > in such a case. > > rtc-cmos should be able to handle the vast majority of x86 > rtcs out there. > In fact, you have 3 rtc implementations available. Please, can you take a look at this question also: http://marc.info/?l=linux-kernel=120355254713965=2 > The only real open issue is related to the ntp synchronization > mode and will be solved only when we can get rid of it :) > -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] state of GEN_RTC vs rtc subsystem
On Wed, 20 Feb 2008 18:03:25 +0100, Alessandro Zummo [EMAIL PROTECTED] wrote: On Wed, 20 Feb 2008 10:11:23 -0600 Kumar Gala [EMAIL PROTECTED] wrote: Is the functionality provided by drivers/char/gen_rtc.c completely handled by the rtc subsystem in drivers/rtc? I ask for two reasons: 1. should we make it mutually exclusive in Kconfig 2. I've enabled both and get (we'll my defconfig did): They shouldn't be enabled at once. I think a patch for Kconfig has been recently submitted to give a warning in such a case. rtc-cmos should be able to handle the vast majority of x86 rtcs out there. In fact, you have 3 rtc implementations available. Please, can you take a look at this question also: http://marc.info/?l=linux-kernelm=120355254713965w=2 The only real open issue is related to the ntp synchronization mode and will be solved only when we can get rid of it :) -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Questions on rtc drivers...
Hi all...
since some time ago I have noticed that mplayer can't use the RTC for
time accounting. Perhaps it is deprecated and should be migrated to
hrtimers, that is what every reference I found said, but the fact is
that nowadays it uses it.
I thought I was because a misbuild of my kernel, but now I have just
built a 2.6.24.2 with every rtc modular to test them (in my case,
just rtc, genrtc and rtc-cmos - I'm not aware of any other that can
work on my mobo, ICH5/i875P).
I use a trimmed down version of the test in Documentacion/rtc.txt.
Results vary:
genrtc fails
crw-r--r-- 1 root root 10, 135 Feb 21 00:53 /dev/rtc
Using /dev/rtc
RTC_IRQP_READ ioctl: Invalid argument
rtc works
crw-r--r-- 1 root root 10, 135 Feb 21 00:53 /dev/rtc
Using /dev/rtc
Initial PI rate: 1024Hz
2 Hz: ..
4 Hz: ..
8 Hz: ..
16 Hz: ..
32 Hz: ..
64 Hz: ..
Device or resource busy
and rtc-cmos behaves strangely. After modprobe, even when /dev/rtc*
are already present, I have to wait even 5 seconds to not have a 'Device or
resource busy' error on open(). And when it opens it just gets stuck
after the first dot:
Using /dev/rtc
Initial PI rate: 1024Hz
2 Hz: .
The loop is
for (i=0; i<10; i++)
{
res = read(rtc,,sizeof(unsigned long));
if (res<0)
{
perror("read");
exit(errno);
}
printf(".");
fflush(stdout);
}
They all give different info in /proc/driver/rtc and
/proc/sys/dev/rtc/max-user-freq:
genrtc
crw-r--r-- 1 root root 10, 135 Feb 21 01:03 /dev/rtc
rtc_time: 00:03:25
rtc_date: 2008-02-21
rtc_epoch : 1900
alarm : 00:00:00
DST_enable : no
BCD : yes
24hr: yes
square_wave : no
alarm_IRQ : no
update_IRQ : no
periodic_IRQ: no
periodic_freq : 0
batt_status : okay
cat: /proc/sys/dev/rtc/max-user-freq: No such file or directory
rtc
crw-r--r-- 1 root root 10, 135 Feb 21 01:03 /dev/rtc
rtc_time: 00:03:26
rtc_date: 2008-02-21
rtc_epoch : 1900
alarm : **:00:10
DST_enable : no
BCD : yes
24hr: yes
square_wave : no
alarm_IRQ : no
update_IRQ : no
periodic_IRQ: no
periodic_freq : 1024
batt_status : okay
64
rtc-cmos
lrwxrwxrwx 1 root root 4 Feb 21 01:03 /dev/rtc -> rtc0
crw-r--r-- 1 root root 254, 0 Feb 21 01:03 /dev/rtc0
rtc_time: 00:03:39
rtc_date: 2008-02-21
alrm_time : **:00:10
alrm_date : -**-**
alarm_IRQ : no
alrm_pending: no
24hr: yes
periodic_IRQ: no
update_IRQ : yes
DST_enable : no
periodic_freq : 1024
batt_status : okay
cat: /proc/sys/dev/rtc/max-user-freq: No such file or directory
So all of them are not completely interchangeable, the only one that works
as expected is 'rtc'.
What am I doing wrong ? Or is it a bug ?
--
J.A. Magallon \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Questions on rtc drivers...
Hi all...
since some time ago I have noticed that mplayer can't use the RTC for
time accounting. Perhaps it is deprecated and should be migrated to
hrtimers, that is what every reference I found said, but the fact is
that nowadays it uses it.
I thought I was because a misbuild of my kernel, but now I have just
built a 2.6.24.2 with every rtc modular to test them (in my case,
just rtc, genrtc and rtc-cmos - I'm not aware of any other that can
work on my mobo, ICH5/i875P).
I use a trimmed down version of the test in Documentacion/rtc.txt.
Results vary:
genrtc fails
crw-r--r-- 1 root root 10, 135 Feb 21 00:53 /dev/rtc
Using /dev/rtc
RTC_IRQP_READ ioctl: Invalid argument
rtc works
crw-r--r-- 1 root root 10, 135 Feb 21 00:53 /dev/rtc
Using /dev/rtc
Initial PI rate: 1024Hz
2 Hz: ..
4 Hz: ..
8 Hz: ..
16 Hz: ..
32 Hz: ..
64 Hz: ..
Device or resource busy
and rtc-cmos behaves strangely. After modprobe, even when /dev/rtc*
are already present, I have to wait even 5 seconds to not have a 'Device or
resource busy' error on open(). And when it opens it just gets stuck
after the first dot:
Using /dev/rtc
Initial PI rate: 1024Hz
2 Hz: .
The loop is
for (i=0; i10; i++)
{
res = read(rtc,data,sizeof(unsigned long));
if (res0)
{
perror(read);
exit(errno);
}
printf(.);
fflush(stdout);
}
They all give different info in /proc/driver/rtc and
/proc/sys/dev/rtc/max-user-freq:
genrtc
crw-r--r-- 1 root root 10, 135 Feb 21 01:03 /dev/rtc
rtc_time: 00:03:25
rtc_date: 2008-02-21
rtc_epoch : 1900
alarm : 00:00:00
DST_enable : no
BCD : yes
24hr: yes
square_wave : no
alarm_IRQ : no
update_IRQ : no
periodic_IRQ: no
periodic_freq : 0
batt_status : okay
cat: /proc/sys/dev/rtc/max-user-freq: No such file or directory
rtc
crw-r--r-- 1 root root 10, 135 Feb 21 01:03 /dev/rtc
rtc_time: 00:03:26
rtc_date: 2008-02-21
rtc_epoch : 1900
alarm : **:00:10
DST_enable : no
BCD : yes
24hr: yes
square_wave : no
alarm_IRQ : no
update_IRQ : no
periodic_IRQ: no
periodic_freq : 1024
batt_status : okay
64
rtc-cmos
lrwxrwxrwx 1 root root 4 Feb 21 01:03 /dev/rtc - rtc0
crw-r--r-- 1 root root 254, 0 Feb 21 01:03 /dev/rtc0
rtc_time: 00:03:39
rtc_date: 2008-02-21
alrm_time : **:00:10
alrm_date : -**-**
alarm_IRQ : no
alrm_pending: no
24hr: yes
periodic_IRQ: no
update_IRQ : yes
DST_enable : no
periodic_freq : 1024
batt_status : okay
cat: /proc/sys/dev/rtc/max-user-freq: No such file or directory
So all of them are not completely interchangeable, the only one that works
as expected is 'rtc'.
What am I doing wrong ? Or is it a bug ?
--
J.A. Magallon jamagallon()ono!com \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Why is the kfree() argument const?
On Fri, 18 Jan 2008 18:24:29 +0100, Olivier Galibert <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 18, 2008 at 08:53:44AM -0500, Andy Lutomirski wrote:
> > I'd say this implies the exact opposite. It almost sounds like the
> > compiler is free to change:
> >
> > void foo(const int *x);
> > foo(x);
> > printf("%d", x);
> >
> > to:
> >
> > void foo(const int *x);
> > printf("%d", x);
> > foo(x);
>
> That's only if neither function has side effects noticeable by the
> other. Invalidating the pointer in (k)free is rather noticeable.
>
That's what __attribute__ ((pure)) is for, but if none of the
functions is pure, the compiler can not be sure about side effects
and can not reorder things. Don't forget that functions can do
anything apart from mangling with their arguments.
And allocator/deallocator functions never can be pure, they must
change global data, the pool of free blocks.
--
J.A. Magallon \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Why is the kfree() argument const?
On Fri, 18 Jan 2008 18:24:29 +0100, Olivier Galibert [EMAIL PROTECTED] wrote: On Fri, Jan 18, 2008 at 08:53:44AM -0500, Andy Lutomirski wrote: I'd say this implies the exact opposite. It almost sounds like the compiler is free to change: void foo(const int *x); foo(x); printf(%d, x); to: void foo(const int *x); printf(%d, x); foo(x); That's only if neither function has side effects noticeable by the other. Invalidating the pointer in (k)free is rather noticeable. That's what __attribute__ ((pure)) is for, but if none of the functions is pure, the compiler can not be sure about side effects and can not reorder things. Don't forget that functions can do anything apart from mangling with their arguments. And allocator/deallocator functions never can be pure, they must change global data, the pool of free blocks. -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.24-rc7
On Mon, 14 Jan 2008 08:57:35 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > J.A. Magallón wrote: > > I'm still pending to pysically remove the disks (or at least unplug the > > cable...), but I have realized a cusious thing: after some errors, the > > kernel is lowering the disk speed (UDMA/133, then 100, then 33): > > That's the standard error handling behavior. Timeouts are likely to > indicate transmission problems so libata puts it into slower gear. > > > Perhaps this gives a clue. > > Or I just had bad luck and 2 of my 4 disks broke at the same time. > > As I said, the first thing I would try is to connect the drives to a > separate PSU and re-seating cables as you're seeing problems on two > drives simultaneously. > I finally found the bad drive (the most obvious one as I would expect, it was recycled from an older box...). I tried removing completely the drive from power and controller, and then running with it powered but not connected. No single error any more on any of the other 3 drives. I have been updating my distro, rebuilding the rpm database, moving big files between drives, even all at the same time. No error. I can't believe it, but a bad drive was causing timeouts on other drive _on other controller_, the bad one was attached to the Promise and the good ones on the ICH5 SATA (both integrated in motherboard). Or there is a strange interaction in my board (Asus PC-DL), or there is a nasty bug in the kernel... -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.24-rc7
On Mon, 14 Jan 2008 08:57:35 +0900, Tejun Heo [EMAIL PROTECTED] wrote: J.A. Magallón wrote: I'm still pending to pysically remove the disks (or at least unplug the cable...), but I have realized a cusious thing: after some errors, the kernel is lowering the disk speed (UDMA/133, then 100, then 33): That's the standard error handling behavior. Timeouts are likely to indicate transmission problems so libata puts it into slower gear. Perhaps this gives a clue. Or I just had bad luck and 2 of my 4 disks broke at the same time. As I said, the first thing I would try is to connect the drives to a separate PSU and re-seating cables as you're seeing problems on two drives simultaneously. I finally found the bad drive (the most obvious one as I would expect, it was recycled from an older box...). I tried removing completely the drive from power and controller, and then running with it powered but not connected. No single error any more on any of the other 3 drives. I have been updating my distro, rebuilding the rpm database, moving big files between drives, even all at the same time. No error. I can't believe it, but a bad drive was causing timeouts on other drive _on other controller_, the bad one was attached to the Promise and the good ones on the ICH5 SATA (both integrated in motherboard). Or there is a strange interaction in my board (Asus PC-DL), or there is a nasty bug in the kernel... -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.24-rc7
On Thu, 10 Jan 2008 22:10:08 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Hi,
>
> J.A. Magallón wrote:
> > It reproduces also with 2.6.23.13.
> > Finally I think the problematic disk is sdc:
>
> Okay, then, it's less likely a regression and more likely a newly
> developed hardware problem.
>
> > ICH5 PATA -> sda
> > ICH5 SATA0 -> sdb
> > ICH5 SATA1 -> sdc
> > Promise SATA -> sdd
> >
> > The problem is that even I have commented out the entry for sdc in fstab,
> > the system is still giving me errors. An my guess is that errors in sdc
> > makes
> > the ICH5 sata controller go nuts, and then I get errors also in sdb.
> > Just a couple questions...
>
> I've never seen ICHs or any other SATA controllers act that way.
>
> > - Can I say to ata_piix something like 'please, detect first SATA ports
> > before
> > ATA', so my system disk (sdb) becomes sda ?
>
> You do that using LABEL, UUID or device ID. Just run 'ls -l
> /dev/disk/by-*/' and see the result.
>
> > - Can I say 'plz, ignore port 1', so it does not try to detect/start/spin
> > sdc ?
> > So I ban be sure it is the one to blame, before start to remove
> > hardware...
>
> Unfortunately not but you can boot into single mode where there's
> nothing trying to access the disk without your explicit command and
> verify access to each hard disk.
>
> Hmm... You are seeing timeouts from multiple harddisks. The first thing
> I would try is to reseat the cables and connect the SATA hard drives to
> a separate power supply and see whether that changes anything.
>
I'm still pending to pysically remove the disks (or at least unplug the
cable...), but I have realized a cusious thing: after some errors, the
kernel is lowering the disk speed (UDMA/133, then 100, then 33):
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd c8/00:08:07:81:3f/00:00:00:00:00/e0 tag 0 dma 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/133
ata3: EH complete
...
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd c8/00:48:05:73:33/00:00:00:00:00/ef tag 0 dma 36864 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/133
ata3: EH complete
...
(one more 133)
...
ata3.00: limiting speed to UDMA/100:PIO4
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd c8/00:40:8d:9c:84/00:00:00:00:00/eb tag 0 dma 32768 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/100
...
(3 more 100)
...
ata3.00: limiting speed to UDMA/33:PIO4
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd ca/00:08:9f:00:1a/00:00:00:00:00/e2 tag 0 dma 4096 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33
...
Perhaps this gives a clue.
Or I just had bad luck and 2 of my 4 disks broke at the same time.
--
J.A. Magallon \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.24-rc7
On Thu, 10 Jan 2008 22:10:08 +0900, Tejun Heo [EMAIL PROTECTED] wrote:
Hi,
J.A. Magallón wrote:
It reproduces also with 2.6.23.13.
Finally I think the problematic disk is sdc:
Okay, then, it's less likely a regression and more likely a newly
developed hardware problem.
ICH5 PATA - sda
ICH5 SATA0 - sdb
ICH5 SATA1 - sdc
Promise SATA - sdd
The problem is that even I have commented out the entry for sdc in fstab,
the system is still giving me errors. An my guess is that errors in sdc
makes
the ICH5 sata controller go nuts, and then I get errors also in sdb.
Just a couple questions...
I've never seen ICHs or any other SATA controllers act that way.
- Can I say to ata_piix something like 'please, detect first SATA ports
before
ATA', so my system disk (sdb) becomes sda ?
You do that using LABEL, UUID or device ID. Just run 'ls -l
/dev/disk/by-*/' and see the result.
- Can I say 'plz, ignore port 1', so it does not try to detect/start/spin
sdc ?
So I ban be sure it is the one to blame, before start to remove
hardware...
Unfortunately not but you can boot into single mode where there's
nothing trying to access the disk without your explicit command and
verify access to each hard disk.
Hmm... You are seeing timeouts from multiple harddisks. The first thing
I would try is to reseat the cables and connect the SATA hard drives to
a separate power supply and see whether that changes anything.
I'm still pending to pysically remove the disks (or at least unplug the
cable...), but I have realized a cusious thing: after some errors, the
kernel is lowering the disk speed (UDMA/133, then 100, then 33):
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd c8/00:08:07:81:3f/00:00:00:00:00/e0 tag 0 dma 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/133
ata3: EH complete
...
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd c8/00:48:05:73:33/00:00:00:00:00/ef tag 0 dma 36864 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/133
ata3: EH complete
...
(one more 133)
...
ata3.00: limiting speed to UDMA/100:PIO4
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd c8/00:40:8d:9c:84/00:00:00:00:00/eb tag 0 dma 32768 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/100
...
(3 more 100)
...
ata3.00: limiting speed to UDMA/33:PIO4
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd ca/00:08:9f:00:1a/00:00:00:00:00/e2 tag 0 dma 4096 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/33
...
Perhaps this gives a clue.
Or I just had bad luck and 2 of my 4 disks broke at the same time.
--
J.A. Magallon jamagallon()ono!com \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.24-rc7
On Wed, 09 Jan 2008 10:56:02 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote:
> J.A. Magallón wrote:
> > HI all...
> >
> > On Sun, 6 Jan 2008 14:19:16 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]>
> > wrote:
> >
> >> It's been two weeks since rc6, but let's face it, with xmas and new years
> >> (and birthdays) in between, there hasn't actually been a lot of working
> >> days, and the incremental patch from -rc6 is about half the size of the
> >> one from rc5->rc6.
> >>
> >> And I'll be charitable and claim it's because it's all stabilizing, and
> >> not because we've all been in a drunken stupor over the holidays.
> >>
> >> The shortlog (appended below) is short and fairly informative. It's all
> >> really just a lot of rather small changes. The diffstat shows a lot of
> >> one- and two-liners, with just a few drivers (and the Cell platform)
> >> getting a bit more attention, and the SLUB support of /proc/slabinfo
> >> showing up as a blip.
> >>
> >
> > With this kernel I'm getting frequent temporary freezes (system comes
> > back responsive after a minute or so...). I see this in dmesg:
> >
> > ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> > ata3.00: cmd ca/00:08:67:10:18/00:00:00:00:00/e2 tag 0 dma 4096 out
> > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> > ata3.00: status: { DRDY }
> > ata3: soft resetting link
> > ata3.00: configured for UDMA/133
> > ata3: EH complete
> > sd 2:0:0:0: [sdb] 390721968 512-byte hardware sectors (200050 MB)
> > sd 2:0:0:0: [sdb] Write Protect is off
> > sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> > sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
> > support DPO or FUA
> >
> > ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> > ata4.00: cmd c8/00:08:ef:0b:c7/00:00:00:00:00/e7 tag 0 dma 4096 in
> > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> > ata4.00: status: { DRDY }
> > ata4: soft resetting link
> > ata4.00: configured for UDMA/133
> > ata4: EH complete
> > sd 3:0:0:0: [sdc] 625142448 512-byte hardware sectors (320073 MB)
> > sd 3:0:0:0: [sdc] Write Protect is off
> > sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
> > sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't
> > support DPO or FUA
> >
> > See this are two different drives, I doubt both drives have gone nuts
> > at the same time...
>
> That's weird. There hasn't been any related changes. Does going back
> to 2.6.24-rc6 fix the problem?
>
It reproduces also with 2.6.23.13.
Finally I think the problematic disk is sdc:
ICH5 PATA -> sda
ICH5 SATA0 -> sdb
ICH5 SATA1 -> sdc
Promise SATA -> sdd
The problem is that even I have commented out the entry for sdc in fstab,
the system is still giving me errors. An my guess is that errors in sdc makes
the ICH5 sata controller go nuts, and then I get errors also in sdb.
Just a couple questions...
- Can I say to ata_piix something like 'please, detect first SATA ports before
ATA', so my system disk (sdb) becomes sda ?
- Can I say 'plz, ignore port 1', so it does not try to detect/start/spin sdc ?
So I ban be sure it is the one to blame, before start to remove hardware...
TIA
--
J.A. Magallon \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.24-rc7
On Wed, 09 Jan 2008 10:56:02 +0900, Tejun Heo [EMAIL PROTECTED] wrote:
J.A. Magallón wrote:
HI all...
On Sun, 6 Jan 2008 14:19:16 -0800 (PST), Linus Torvalds [EMAIL PROTECTED]
wrote:
It's been two weeks since rc6, but let's face it, with xmas and new years
(and birthdays) in between, there hasn't actually been a lot of working
days, and the incremental patch from -rc6 is about half the size of the
one from rc5-rc6.
And I'll be charitable and claim it's because it's all stabilizing, and
not because we've all been in a drunken stupor over the holidays.
The shortlog (appended below) is short and fairly informative. It's all
really just a lot of rather small changes. The diffstat shows a lot of
one- and two-liners, with just a few drivers (and the Cell platform)
getting a bit more attention, and the SLUB support of /proc/slabinfo
showing up as a blip.
With this kernel I'm getting frequent temporary freezes (system comes
back responsive after a minute or so...). I see this in dmesg:
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd ca/00:08:67:10:18/00:00:00:00:00/e2 tag 0 dma 4096 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/133
ata3: EH complete
sd 2:0:0:0: [sdb] 390721968 512-byte hardware sectors (200050 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata4.00: cmd c8/00:08:ef:0b:c7/00:00:00:00:00/e7 tag 0 dma 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata4.00: status: { DRDY }
ata4: soft resetting link
ata4.00: configured for UDMA/133
ata4: EH complete
sd 3:0:0:0: [sdc] 625142448 512-byte hardware sectors (320073 MB)
sd 3:0:0:0: [sdc] Write Protect is off
sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
See this are two different drives, I doubt both drives have gone nuts
at the same time...
That's weird. There hasn't been any related changes. Does going back
to 2.6.24-rc6 fix the problem?
It reproduces also with 2.6.23.13.
Finally I think the problematic disk is sdc:
ICH5 PATA - sda
ICH5 SATA0 - sdb
ICH5 SATA1 - sdc
Promise SATA - sdd
The problem is that even I have commented out the entry for sdc in fstab,
the system is still giving me errors. An my guess is that errors in sdc makes
the ICH5 sata controller go nuts, and then I get errors also in sdb.
Just a couple questions...
- Can I say to ata_piix something like 'please, detect first SATA ports before
ATA', so my system disk (sdb) becomes sda ?
- Can I say 'plz, ignore port 1', so it does not try to detect/start/spin sdc ?
So I ban be sure it is the one to blame, before start to remove hardware...
TIA
--
J.A. Magallon jamagallon()ono!com \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: I/O scheduler problem with an 8 SATA disks raid 5 under heavy load ?
On Tue, 8 Jan 2008 15:52:35 +0100, Guillaume Laurès <[EMAIL PROTECTED]> wrote: > > ata5.00: exception Emask 0x0 SAct 0x1f02 SErr 0x0 action 0x2 frozen > > ata5.00: cmd 60/40:08:8f:eb:67/00:00:03:00:00/40 tag 1 cdb 0x0 data > > 32768 in > > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Perhaps it is a generic libata bug, I have similar problems without any array. See this message: http://marc.info/?l=linux-kernel=119975354031937=2 It's an ICH5 controller, not nv. This was rc7. I have now gone back to rc6 to see if problems persist. -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: I/O scheduler problem with an 8 SATA disks raid 5 under heavy load ?
On Tue, 8 Jan 2008 15:52:35 +0100, Guillaume Laurès [EMAIL PROTECTED] wrote: ata5.00: exception Emask 0x0 SAct 0x1f02 SErr 0x0 action 0x2 frozen ata5.00: cmd 60/40:08:8f:eb:67/00:00:03:00:00/40 tag 1 cdb 0x0 data 32768 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Perhaps it is a generic libata bug, I have similar problems without any array. See this message: http://marc.info/?l=linux-kernelm=119975354031937w=2 It's an ICH5 controller, not nv. This was rc7. I have now gone back to rc6 to see if problems persist. -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.24-rc7
HI all...
On Sun, 6 Jan 2008 14:19:16 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]>
wrote:
>
> It's been two weeks since rc6, but let's face it, with xmas and new years
> (and birthdays) in between, there hasn't actually been a lot of working
> days, and the incremental patch from -rc6 is about half the size of the
> one from rc5->rc6.
>
> And I'll be charitable and claim it's because it's all stabilizing, and
> not because we've all been in a drunken stupor over the holidays.
>
> The shortlog (appended below) is short and fairly informative. It's all
> really just a lot of rather small changes. The diffstat shows a lot of
> one- and two-liners, with just a few drivers (and the Cell platform)
> getting a bit more attention, and the SLUB support of /proc/slabinfo
> showing up as a blip.
>
With this kernel I'm getting frequent temporary freezes (system comes
back responsive after a minute or so...). I see this in dmesg:
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd ca/00:08:67:10:18/00:00:00:00:00/e2 tag 0 dma 4096 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/133
ata3: EH complete
sd 2:0:0:0: [sdb] 390721968 512-byte hardware sectors (200050 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata4.00: cmd c8/00:08:ef:0b:c7/00:00:00:00:00/e7 tag 0 dma 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata4.00: status: { DRDY }
ata4: soft resetting link
ata4.00: configured for UDMA/133
ata4: EH complete
sd 3:0:0:0: [sdc] 625142448 512-byte hardware sectors (320073 MB)
sd 3:0:0:0: [sdc] Write Protect is off
sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
See this are two different drives, I doubt both drives have gone nuts
at the same time...
Controllers:
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller
(rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02)
03:04.0 RAID bus controller: Promise Technology, Inc. PDC20378 (FastTrak
378/SATA 378) (rev 02)
Drives (sda is PATA, sd[bcd] are SATA,
werewolf:~> lsscsi
[0:0:0:0]diskATA ST3120022A 3.06 /dev/sda
[0:0:1:0]cd/dvd HL-DT-ST DVDRAM GSA-H10N JL12 /dev/sr0
[2:0:0:0]diskATA ST3200822AS 3.01 /dev/sdb
[3:0:0:0]diskATA MAXTOR STM332082 3.AA /dev/sdc
[4:0:0:0]diskATA Maxtor 7Y250M0 YAR5 /dev/sdd
werewolf:~> df
FilesystemTypeSize Used Avail Use% Mounted on
/dev/sdb1 ext3 30G 11G 18G 38% /
/dev/sdb2 ext3152G 71G 81G 47% /home
/dev/sdc1 ext3294G 67G 212G 24% /home/store/media/music
/dev/sdd1 ext3231G 42G 177G 20% /home/store/media/video
/dev/sda1 ext3111G 887M 104G 1% /scratch
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
ata_piix :00:1f.1: version 2.12
ACPI: PCI Interrupt :00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device :00:1f.1 to 64
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xf008 irq 15
Switched to high resolution mode on CPU 2
Switched to high resolution mode on CPU 3
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
ata1.00: ATA-6: ST3120022A, 3.06, max UDMA/100
ata1.00: 234441648 sectors, multi 16: LBA48
ata1.01: ATAPI: HL-DT-ST DVDRAM GSA-H10N, JL12, max UDMA/33
ata1.00: configured for UDMA/100
ata1.01: configured for UDMA/33
scsi 0:0:0:0: Direct-Access ATA ST3120022A 3.06 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI disk
scsi 0:0:1:0: CD-ROMHL-DT-ST DVDRAM GSA-H10N JL12 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 0:0:1:0: Attached scsi CD-ROM sr0
ata_piix :00:1f.2: MAP [ P0 -- P1 -- ]
ACPI: PCI Interrupt :00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device :00:1f.2 to 64
scsi2 : ata_piix
scsi3 : ata_piix
ata3: SATA max UDMA/133
Re: Linux 2.6.24-rc7
HI all...
On Sun, 6 Jan 2008 14:19:16 -0800 (PST), Linus Torvalds [EMAIL PROTECTED]
wrote:
It's been two weeks since rc6, but let's face it, with xmas and new years
(and birthdays) in between, there hasn't actually been a lot of working
days, and the incremental patch from -rc6 is about half the size of the
one from rc5-rc6.
And I'll be charitable and claim it's because it's all stabilizing, and
not because we've all been in a drunken stupor over the holidays.
The shortlog (appended below) is short and fairly informative. It's all
really just a lot of rather small changes. The diffstat shows a lot of
one- and two-liners, with just a few drivers (and the Cell platform)
getting a bit more attention, and the SLUB support of /proc/slabinfo
showing up as a blip.
With this kernel I'm getting frequent temporary freezes (system comes
back responsive after a minute or so...). I see this in dmesg:
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd ca/00:08:67:10:18/00:00:00:00:00/e2 tag 0 dma 4096 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/133
ata3: EH complete
sd 2:0:0:0: [sdb] 390721968 512-byte hardware sectors (200050 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata4.00: cmd c8/00:08:ef:0b:c7/00:00:00:00:00/e7 tag 0 dma 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata4.00: status: { DRDY }
ata4: soft resetting link
ata4.00: configured for UDMA/133
ata4: EH complete
sd 3:0:0:0: [sdc] 625142448 512-byte hardware sectors (320073 MB)
sd 3:0:0:0: [sdc] Write Protect is off
sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
See this are two different drives, I doubt both drives have gone nuts
at the same time...
Controllers:
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller
(rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02)
03:04.0 RAID bus controller: Promise Technology, Inc. PDC20378 (FastTrak
378/SATA 378) (rev 02)
Drives (sda is PATA, sd[bcd] are SATA,
werewolf:~ lsscsi
[0:0:0:0]diskATA ST3120022A 3.06 /dev/sda
[0:0:1:0]cd/dvd HL-DT-ST DVDRAM GSA-H10N JL12 /dev/sr0
[2:0:0:0]diskATA ST3200822AS 3.01 /dev/sdb
[3:0:0:0]diskATA MAXTOR STM332082 3.AA /dev/sdc
[4:0:0:0]diskATA Maxtor 7Y250M0 YAR5 /dev/sdd
werewolf:~ df
FilesystemTypeSize Used Avail Use% Mounted on
/dev/sdb1 ext3 30G 11G 18G 38% /
/dev/sdb2 ext3152G 71G 81G 47% /home
/dev/sdc1 ext3294G 67G 212G 24% /home/store/media/music
/dev/sdd1 ext3231G 42G 177G 20% /home/store/media/video
/dev/sda1 ext3111G 887M 104G 1% /scratch
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
ata_piix :00:1f.1: version 2.12
ACPI: PCI Interrupt :00:1f.1[A] - GSI 18 (level, low) - IRQ 16
PCI: Setting latency timer of device :00:1f.1 to 64
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xf008 irq 15
Switched to high resolution mode on CPU 2
Switched to high resolution mode on CPU 3
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
ata1.00: ATA-6: ST3120022A, 3.06, max UDMA/100
ata1.00: 234441648 sectors, multi 16: LBA48
ata1.01: ATAPI: HL-DT-ST DVDRAM GSA-H10N, JL12, max UDMA/33
ata1.00: configured for UDMA/100
ata1.01: configured for UDMA/33
scsi 0:0:0:0: Direct-Access ATA ST3120022A 3.06 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI disk
scsi 0:0:1:0: CD-ROMHL-DT-ST DVDRAM GSA-H10N JL12 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 0:0:1:0: Attached scsi CD-ROM sr0
ata_piix :00:1f.2: MAP [ P0 -- P1 -- ]
ACPI: PCI Interrupt :00:1f.2[A] - GSI 18 (level, low) - IRQ 16
PCI: Setting latency timer of device :00:1f.2 to 64
scsi2 : ata_piix
scsi3 : ata_piix
ata3: SATA max UDMA/133 cmd 0xc000 ctl 0xc400
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007 18:05:48 -0500, "linux-os (Dick Johnson)" <[EMAIL PROTECTED]> wrote: > > On Thu, 20 Dec 2007, Sam Ravnborg wrote: > > > On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: > >> > >> On Thu, 20 Dec 2007, Sam Ravnborg wrote: > >> > > It never gets to the printk(). You were right about the > compilation. Somebody changed the kernel to compile with > parameter passing in REGISTERS! This means that EVERYTHING > needs to be compiled the same way, 'C' calling conventions > were not good enough! > >>> > >>> How did you build the module. It reads like you failed to use > >>> kbuild to build your module which is why you did not pass > >>> correct options to gcc - correct? > >>> > >>> If you did not use kbuild - why not? > >>> Is there anything missing you need? > >>> > >> > >> I need to get rid of -mregparm=3 on gcc's command line. It > >> is completely incompatible with the standard calling conventions > >> used in all our assembly-language files in our drivers. We make > >> very high-speed number-crunching drivers that munge high-speed > >> data into images. We need to do that in assembly as we have > >> always done. > Just for curiosity... yep, I understand now you have everything written in assembler, but why not consider start writing it in C and stop doing the compiler work (such as pipelining, out of order reordering, loop unrolling for specific processor, and so on...) That's what everyone taught me, nowadays you won't be better than the compiler in anything longer than three lines... -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trailing periods in kernel messages
On Thu, 20 Dec 2007 22:08:53 +, Alan Cox <[EMAIL PROTECTED]> wrote: > > I believe though that printk messages are not sentences but are > > logging statements. Statements do not require full-stops. > > > > Opinions, of course, vary. > > I do not believe "opinions" are relevant here. Relevant would be cites > from respected style guides (Fowlers, Oxford Guide To Style et al.) to > show they do not need a full stop. > All those fine references you cite are sure written for read literate (literacy?) texts. Punctuation is something that is needed in (just forgive me 'cause I'm trying to think this in english, but spanish is my native language...) continous written text that needs some kind of symbol to show there is a pause half in a sentence (a comma), or that two statements are separate sentences and need to be declaimed specially. Nobody (someone?) has written a guide to declaim computer messages or source code. If you get so picky, this message [kajasldkjasl] Kernel OOPS: sdsdsdsdsd shoud read: At [kajasldkjasl], the kernel has tried to deliver an operation that resulted in an inconsistent state, so system operation has been stopped... >From my point of view: - Kernel messages are not read at loud... - If you are so worried about extra chars/mem usage in other areas, the dot at the end of a kernel message is just trash. - If some kernel message has two sentences, better to format them in two lines (ie, sed -e :.:\n:g:) If some kernel message needs grammatical corrections, it is not a kernel message, it was someone very bored when he wrote the code. The kernel messages are _not_ sentences, they are kernel messages. If not, you have a harder work assuring they all have a subject and a predicate than worrying about dots at the end... -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trailing periods in kernel messages
On Thu, 20 Dec 2007 22:08:53 +, Alan Cox [EMAIL PROTECTED] wrote: I believe though that printk messages are not sentences but are logging statements. Statements do not require full-stops. Opinions, of course, vary. I do not believe opinions are relevant here. Relevant would be cites from respected style guides (Fowlers, Oxford Guide To Style et al.) to show they do not need a full stop. All those fine references you cite are sure written for read literate (literacy?) texts. Punctuation is something that is needed in (just forgive me 'cause I'm trying to think this in english, but spanish is my native language...) continous written text that needs some kind of symbol to show there is a pause half in a sentence (a comma), or that two statements are separate sentences and need to be declaimed specially. Nobody (someone?) has written a guide to declaim computer messages or source code. If you get so picky, this message [kajasldkjasl] Kernel OOPS: sdsdsdsdsd shoud read: At [kajasldkjasl], the kernel has tried to deliver an operation that resulted in an inconsistent state, so system operation has been stopped... From my point of view: - Kernel messages are not read at loud... - If you are so worried about extra chars/mem usage in other areas, the dot at the end of a kernel message is just trash. - If some kernel message has two sentences, better to format them in two lines (ie, sed -e :.:\n:g:) If some kernel message needs grammatical corrections, it is not a kernel message, it was someone very bored when he wrote the code. The kernel messages are _not_ sentences, they are kernel messages. If not, you have a harder work assuring they all have a subject and a predicate than worrying about dots at the end... -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
On Thu, 20 Dec 2007 18:05:48 -0500, linux-os (Dick Johnson) [EMAIL PROTECTED] wrote: On Thu, 20 Dec 2007, Sam Ravnborg wrote: On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: On Thu, 20 Dec 2007, Sam Ravnborg wrote: It never gets to the printk(). You were right about the compilation. Somebody changed the kernel to compile with parameter passing in REGISTERS! This means that EVERYTHING needs to be compiled the same way, 'C' calling conventions were not good enough! How did you build the module. It reads like you failed to use kbuild to build your module which is why you did not pass correct options to gcc - correct? If you did not use kbuild - why not? Is there anything missing you need? I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Just for curiosity... yep, I understand now you have everything written in assembler, but why not consider start writing it in C and stop doing the compiler work (such as pipelining, out of order reordering, loop unrolling for specific processor, and so on...) That's what everyone taught me, nowadays you won't be better than the compiler in anything longer than three lines... -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development & Objective-C
On Mon, 3 Dec 2007 21:57:27 +, Alan Cox <[EMAIL PROTECTED]> wrote: > > You could write an equally effcient kernel in languages like C++, > > using C++ abstractions as a high level organization, where > > It's very very hard to generate good C code because of the numerous ways > objects get temporarily created, and the week aliasing rules (as with C). > That is what I like of C++, with good placement of high level features like const's and & (references) one can gain fine control over what gets copied or not. Try to write a Vector class that does ops with SSE without storing temporals on the stack. Its a good example of how one can get low level control, and gcc is pretty good simplifying things like u=v+2*w and not putting anything on the stack, all in xmm registers. The advantage is you onle has to be careful one time, when you write the class. > There are reasons that Fortran lives on (and no I'm not suggesting one > should rewrite the kernel in Fortran ;)) and the fact its not really got > pointer aliasing or "address of" operators and all the resulting > optimsation problems is one of the big ones. > -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam03 (gcc 4.2.2 (4.2.2-1mdv2008.1)) SMP Sat Nov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development & Objective-C
On Tue, 4 Dec 2007 12:54:13 -0500, [EMAIL PROTECTED] (Lennart Sorensen) wrote:
> On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote:
> > I think BeOS was C++ and OSX is C+ObjectiveC (and runs on an iPhone).
> > Original MacOS (fron 6 to 9) was Pascal (and a mac SE was very near
> > to embedded hardware :) ).
> >
> > I do not advocate to rewrite Linux in C++, but don't say a kernel written
> > in C++ can not be efficient.
>
> Well I am pretty sure the micro kernel of OS X is in C, and certainly
> the BSD layer is as well. So the only ObjC part would be the nextstep
> framework and other parts of the Mac GUI and other Mac APIs they
> provide, which all at some point probably end up calling down into the C
> stuff below.
>
Yup, thanks.
> > C++ (and for what I read on other answer, nor ObjectiveC) has no garbage
> > collection. It does not anything you did not it to do. It just allows
> > you to change this
> >
> > struct buffer *x;
> > x = kmalloc(...)
> > x->sz = 128
> > x->buff = kmalloc(...)
> > ...
> > kfree(x->buff)
> > kfree(x)
> >
> > to
> > struct buffer *x;
> > x = new buffer(128); (that does itself allocates x->buff,
> > because _you_ programmed it,
> > so you poor programmer don't forget)
> > ...
> > delete x;(that also was programmed to deallocate
> > x->buff itself, sou you have one less
> > memory leak to worry about)
>
> But kmalloc is implemented by the kernel. Who implements 'new'?
>
Help yourself... as kmalloc() is a replacement for userspace glibc's
malloc, you can write your replacements for functions/operators in
libstdc++ (operators are just cosmetic, as many other features in C++)
In fact, for someone who dared to write a kernel C++ framework, the
very first function he has to write could be something like:
void* operator new(size_t sz)
{
return kmalloc(sz,GPF_KERNEL);
}
And could write alternatives like
operator new(size_t sz,int flags) -> x = new(GPF_ATOMIC) X;
operator new(size_t sz,MemPool& pl) -> x = new(pool) X;
If you are curious, this page http://www.osdev.org/wiki/C_PlusPlus
has some clues about what should you implement to get rid of
libstdc++.
--
J.A. Magallon \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam03 (gcc 4.2.2 (4.2.2-1mdv2008.1)) SMP Sat Nov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development Objective-C
On Tue, 4 Dec 2007 12:54:13 -0500, [EMAIL PROTECTED] (Lennart Sorensen) wrote:
On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote:
I think BeOS was C++ and OSX is C+ObjectiveC (and runs on an iPhone).
Original MacOS (fron 6 to 9) was Pascal (and a mac SE was very near
to embedded hardware :) ).
I do not advocate to rewrite Linux in C++, but don't say a kernel written
in C++ can not be efficient.
Well I am pretty sure the micro kernel of OS X is in C, and certainly
the BSD layer is as well. So the only ObjC part would be the nextstep
framework and other parts of the Mac GUI and other Mac APIs they
provide, which all at some point probably end up calling down into the C
stuff below.
Yup, thanks.
C++ (and for what I read on other answer, nor ObjectiveC) has no garbage
collection. It does not anything you did not it to do. It just allows
you to change this
struct buffer *x;
x = kmalloc(...)
x-sz = 128
x-buff = kmalloc(...)
...
kfree(x-buff)
kfree(x)
to
struct buffer *x;
x = new buffer(128); (that does itself allocates x-buff,
because _you_ programmed it,
so you poor programmer don't forget)
...
delete x;(that also was programmed to deallocate
x-buff itself, sou you have one less
memory leak to worry about)
But kmalloc is implemented by the kernel. Who implements 'new'?
Help yourself... as kmalloc() is a replacement for userspace glibc's
malloc, you can write your replacements for functions/operators in
libstdc++ (operators are just cosmetic, as many other features in C++)
In fact, for someone who dared to write a kernel C++ framework, the
very first function he has to write could be something like:
void* operator new(size_t sz)
{
return kmalloc(sz,GPF_KERNEL);
}
And could write alternatives like
operator new(size_t sz,int flags) - x = new(GPF_ATOMIC) X;
operator new(size_t sz,MemPool pl) - x = new(pool) X;
If you are curious, this page http://www.osdev.org/wiki/C_PlusPlus
has some clues about what should you implement to get rid of
libstdc++.
--
J.A. Magallon jamagallon()ono!com \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam03 (gcc 4.2.2 (4.2.2-1mdv2008.1)) SMP Sat Nov
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development Objective-C
On Mon, 3 Dec 2007 21:57:27 +, Alan Cox [EMAIL PROTECTED] wrote: You could write an equally effcient kernel in languages like C++, using C++ abstractions as a high level organization, where It's very very hard to generate good C code because of the numerous ways objects get temporarily created, and the week aliasing rules (as with C). That is what I like of C++, with good placement of high level features like const's and (references) one can gain fine control over what gets copied or not. Try to write a Vector class that does ops with SSE without storing temporals on the stack. Its a good example of how one can get low level control, and gcc is pretty good simplifying things like u=v+2*w and not putting anything on the stack, all in xmm registers. The advantage is you onle has to be careful one time, when you write the class. There are reasons that Fortran lives on (and no I'm not suggesting one should rewrite the kernel in Fortran ;)) and the fact its not really got pointer aliasing or address of operators and all the resulting optimsation problems is one of the big ones. -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam03 (gcc 4.2.2 (4.2.2-1mdv2008.1)) SMP Sat Nov -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development & Objective-C
On Mon, 3 Dec 2007 22:13:53 +0100, Willy Tarreau <[EMAIL PROTECTED]> wrote:
...
>
> It just depends how many times a second it happens. For instance, consider
> this trivial loop (fct is a two-function array which just return 1 or 2) :
>
> i = 0;
> for (j = 0; j < (1 << 28); j++) {
> k = (j >> 8) & 1;
> i += fct[k]();
> }
>
> It takes 1.6 seconds to execute on my athlon-xp 1.5 GHz. If, instead of
> changing the function once every 256 calls, you change it to every call :
>
> i = 0;
> for (j = 0; j < (1 << 28); j++) {
> k = (j >> 0) & 1;
> i += fct[k]();
> }
>
> Then it only takes 4.3 seconds, which is about 3 times slower. The number
> of calls per function remains the same (128M calls each), it's just the
> branch prediction which is wrong every time. The very few nanoseconds added
> at each call are enough to slow down a program from 1.6 to 4.3 seconds while
> it executes the exact same code (it may even save one shift). If you have
> such stupid code, say, to compute the color or alpha of each pixel in an
> image, you will certainly notice the difference.
>
> And such poorly efficient code may happen very often when you blindly rely
> on function pointers instead of explicit calls.
>
...
>
> You are forgetting something very important : once you start stacking
> functions to perform the dirty work for you, you end up with so much
> abstraction that even new stupid code cannot be written at all without
> relying on them, and it's where the problem takes its roots, because
> when you need to write a fast function and you notice that you cannot
> touch a variable without passing through a slow pinhole, your fast
> function will remain slow whatever you do, and the worst of all is that
> you will think that it is normally fast and that it cannot be written
> faster.
>
But don't forget that OOP is just another way to organize your code,
and let the language/compiler do some things you shouldn't de doing,
like fill an vtable pointer, that are error prone.
And of course everything depends on what language you choose and how
you use it.
You could write an equally effcient kernel in languages like C++,
using C++ abstractions as a high level organization, where
the fast paths could be coded the right way; we are not talking about
C# or Java, where even a sum is a call to an overloaded method.
Its the difference between doing school-book push and pops to lists,
and suddenly inventing the splice operator...
--
J.A. Magallon \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam03 (gcc 4.2.2 (4.2.2-1mdv2008.1)) SMP Sat Nov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development Objective-C
On Mon, 3 Dec 2007 22:13:53 +0100, Willy Tarreau [EMAIL PROTECTED] wrote:
...
It just depends how many times a second it happens. For instance, consider
this trivial loop (fct is a two-function array which just return 1 or 2) :
i = 0;
for (j = 0; j (1 28); j++) {
k = (j 8) 1;
i += fct[k]();
}
It takes 1.6 seconds to execute on my athlon-xp 1.5 GHz. If, instead of
changing the function once every 256 calls, you change it to every call :
i = 0;
for (j = 0; j (1 28); j++) {
k = (j 0) 1;
i += fct[k]();
}
Then it only takes 4.3 seconds, which is about 3 times slower. The number
of calls per function remains the same (128M calls each), it's just the
branch prediction which is wrong every time. The very few nanoseconds added
at each call are enough to slow down a program from 1.6 to 4.3 seconds while
it executes the exact same code (it may even save one shift). If you have
such stupid code, say, to compute the color or alpha of each pixel in an
image, you will certainly notice the difference.
And such poorly efficient code may happen very often when you blindly rely
on function pointers instead of explicit calls.
...
You are forgetting something very important : once you start stacking
functions to perform the dirty work for you, you end up with so much
abstraction that even new stupid code cannot be written at all without
relying on them, and it's where the problem takes its roots, because
when you need to write a fast function and you notice that you cannot
touch a variable without passing through a slow pinhole, your fast
function will remain slow whatever you do, and the worst of all is that
you will think that it is normally fast and that it cannot be written
faster.
But don't forget that OOP is just another way to organize your code,
and let the language/compiler do some things you shouldn't de doing,
like fill an vtable pointer, that are error prone.
And of course everything depends on what language you choose and how
you use it.
You could write an equally effcient kernel in languages like C++,
using C++ abstractions as a high level organization, where
the fast paths could be coded the right way; we are not talking about
C# or Java, where even a sum is a call to an overloaded method.
Its the difference between doing school-book push and pops to lists,
and suddenly inventing the splice operator...
--
J.A. Magallon jamagallon()ono!com \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam03 (gcc 4.2.2 (4.2.2-1mdv2008.1)) SMP Sat Nov
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development & Objective-C
On Sat, 1 Dec 2007 00:31:19 +, Al Viro <[EMAIL PROTECTED]> wrote: > On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote: > > An vtable in C++ takes exactly the same space that the function > > table pointer present in every driver nowadays... and probably > > the virtual method call that C++ does itself with > > > > thing->do_something(with,this) > > > > like > > push thing > > push with > > push this > > call THING_vtable+indexof(do_something) // constants at compile time > > This is not what vtables are. Think for a minute - all codepaths arriving > to that point in your code will pick the address to call from the same > location. Either the contents of that location is constant (in which case > you could bloody well call it directly in the first place) *or* it has to > somehow be reassigned back and forth, according to the value of this. The > former is dumb, the latter - outright insane. > > The contents of vtables is constant. The whole point of that thing is > to deal with the situations where we _can't_ tell which derived class > this ->do_something() is from; if we could tell which vtable it is at > compile time, we wouldn't need to bother at all. > Yup, my mistake (that's why I said i will learn something). I was thinking on non-virtual methods. For virtual ones you have to fetch the vtable start address and index from it. > It's a tradeoff - we pay the extra memory access (fetch vtable pointer, then > fetch method from vtable) for not having to store a slew of method pointers > in each instance of base class. But the extra memory access is very much > there. It can be further optimized away if you have several method calls > for the same object next to each other (then vtable can be picked once), > but it's still done at runtime. -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam03 (gcc 4.2.2 (4.2.2-1mdv2008.1)) SMP Sat Nov 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development & Objective-C
On Fri, 30 Nov 2007 11:29:55 +0100, "Loïc Grenié" <[EMAIL PROTECTED]> wrote: > 2007/11/29, Ben Crowhurst <[EMAIL PROTECTED]>: > > Has Objective-C ever been considered for kernel development? > > > > regards, > > BPC > Well, I really would like to learn some things here, could we keep this off-topic thread alive just a bit, please ? (I know, I'm going to gain a troll's fame because I can't avoid this discussions, its one of my secret vices...) >No, it has not. Any language that looks remotely like an OO language > has not ever been considered for (Linux) kernel development and for > most, if not all, other operating systems kernels. > I think BeOS was C++ and OSX is C+ObjectiveC (and runs on an iPhone). Original MacOS (fron 6 to 9) was Pascal (and a mac SE was very near to embedded hardware :) ). I do not advocate to rewrite Linux in C++, but don't say a kernel written in C++ can not be efficient. > Various problems occur in an object oriented language. One of them > is garbage collection: it provokes asynchronous delays and, during > an interrupt or a system call for a real time task, the kernel cannot > wait. C++ (and for what I read on other answer, nor ObjectiveC) has no garbage collection. It does not anything you did not it to do. It just allows you to change this struct buffer *x; x = kmalloc(...) x->sz = 128 x->buff = kmalloc(...) ... kfree(x->buff) kfree(x) to struct buffer *x; x = new buffer(128); (that does itself allocates x->buff, because _you_ programmed it, so you poor programmer don't forget) ... delete x;(that also was programmed to deallocate x->buff itself, sou you have one less memory leak to worry about) > Another is memory overhead: all the magic that OO languages > provide take space in memory and Linux kernel is used in embedded > systems with very tight memory requirements. > An vtable in C++ takes exactly the same space that the function table pointer present in every driver nowadays... and probably the virtual method call that C++ does itself with thing->do_something(with,this) like push thing push with push this call THING_vtable+indexof(do_something) // constants at compile time is much more efficient that what gcc can mangle to do with thing->do_something(with,this,thing) push with push this push thing get thing+offsetof(do_something) // not constant at compile time dereference it call it (that is, get a generic field on a structure and use it as jump address) In short, the kernel is object oriented, implements OO programming by hand, but the compiler lacks the knowledge that it is object oriented programming so it could do some optimizations. > Lots of people will think of better reasons why ObjC is not used... People usually complains about RTTI or exceptions, but benefits versus memory space should be seriously considered (sure there is something in current drivers to ask 'are you a SATA or an IDE disk?'). -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam03 (gcc 4.2.2 (4.2.2-1mdv2008.1)) SMP Sat Nov 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development & Objective-C
On Fri, 30 Nov 2007 19:09:45 +0900, KOSAKI Motohiro <[EMAIL PROTECTED]> wrote: > > > Has Objective-C ever been considered for kernel development? > > > > Why not C# instead ? > > Why not Haskell nor Erlang instead ? :-D > Flash http://www.lagmonster.info/humor/windowsrg.html -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam03 (gcc 4.2.2 (4.2.2-1mdv2008.1)) SMP Sat Nov 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development Objective-C
On Fri, 30 Nov 2007 11:29:55 +0100, Loïc Grenié [EMAIL PROTECTED] wrote: 2007/11/29, Ben Crowhurst [EMAIL PROTECTED]: Has Objective-C ever been considered for kernel development? regards, BPC Well, I really would like to learn some things here, could we keep this off-topic thread alive just a bit, please ? (I know, I'm going to gain a troll's fame because I can't avoid this discussions, its one of my secret vices...) No, it has not. Any language that looks remotely like an OO language has not ever been considered for (Linux) kernel development and for most, if not all, other operating systems kernels. I think BeOS was C++ and OSX is C+ObjectiveC (and runs on an iPhone). Original MacOS (fron 6 to 9) was Pascal (and a mac SE was very near to embedded hardware :) ). I do not advocate to rewrite Linux in C++, but don't say a kernel written in C++ can not be efficient. Various problems occur in an object oriented language. One of them is garbage collection: it provokes asynchronous delays and, during an interrupt or a system call for a real time task, the kernel cannot wait. C++ (and for what I read on other answer, nor ObjectiveC) has no garbage collection. It does not anything you did not it to do. It just allows you to change this struct buffer *x; x = kmalloc(...) x-sz = 128 x-buff = kmalloc(...) ... kfree(x-buff) kfree(x) to struct buffer *x; x = new buffer(128); (that does itself allocates x-buff, because _you_ programmed it, so you poor programmer don't forget) ... delete x;(that also was programmed to deallocate x-buff itself, sou you have one less memory leak to worry about) Another is memory overhead: all the magic that OO languages provide take space in memory and Linux kernel is used in embedded systems with very tight memory requirements. An vtable in C++ takes exactly the same space that the function table pointer present in every driver nowadays... and probably the virtual method call that C++ does itself with thing-do_something(with,this) like push thing push with push this call THING_vtable+indexof(do_something) // constants at compile time is much more efficient that what gcc can mangle to do with thing-do_something(with,this,thing) push with push this push thing get thing+offsetof(do_something) // not constant at compile time dereference it call it (that is, get a generic field on a structure and use it as jump address) In short, the kernel is object oriented, implements OO programming by hand, but the compiler lacks the knowledge that it is object oriented programming so it could do some optimizations. Lots of people will think of better reasons why ObjC is not used... People usually complains about RTTI or exceptions, but benefits versus memory space should be seriously considered (sure there is something in current drivers to ask 'are you a SATA or an IDE disk?'). -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam03 (gcc 4.2.2 (4.2.2-1mdv2008.1)) SMP Sat Nov 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development Objective-C
On Sat, 1 Dec 2007 00:31:19 +, Al Viro [EMAIL PROTECTED] wrote: On Sat, Dec 01, 2007 at 12:19:50AM +0100, J.A. Magall??n wrote: An vtable in C++ takes exactly the same space that the function table pointer present in every driver nowadays... and probably the virtual method call that C++ does itself with thing-do_something(with,this) like push thing push with push this call THING_vtable+indexof(do_something) // constants at compile time This is not what vtables are. Think for a minute - all codepaths arriving to that point in your code will pick the address to call from the same location. Either the contents of that location is constant (in which case you could bloody well call it directly in the first place) *or* it has to somehow be reassigned back and forth, according to the value of this. The former is dumb, the latter - outright insane. The contents of vtables is constant. The whole point of that thing is to deal with the situations where we _can't_ tell which derived class this -do_something() is from; if we could tell which vtable it is at compile time, we wouldn't need to bother at all. Yup, my mistake (that's why I said i will learn something). I was thinking on non-virtual methods. For virtual ones you have to fetch the vtable start address and index from it. It's a tradeoff - we pay the extra memory access (fetch vtable pointer, then fetch method from vtable) for not having to store a slew of method pointers in each instance of base class. But the extra memory access is very much there. It can be further optimized away if you have several method calls for the same object next to each other (then vtable can be picked once), but it's still done at runtime. -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam03 (gcc 4.2.2 (4.2.2-1mdv2008.1)) SMP Sat Nov 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Development Objective-C
On Fri, 30 Nov 2007 19:09:45 +0900, KOSAKI Motohiro [EMAIL PROTECTED] wrote: Has Objective-C ever been considered for kernel development? Why not C# instead ? Why not Haskell nor Erlang instead ? :-D Flash http://www.lagmonster.info/humor/windowsrg.html -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam03 (gcc 4.2.2 (4.2.2-1mdv2008.1)) SMP Sat Nov 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
void* arithmnetic
Hi all...
Since begin of the ages the build of the nvidia driver says things like
this:
include/asm/compat.h:210: warning: pointer of type 'void *' used in arithmetic
There are several of this warnings. The code in question for this example
is:
static __inline__ void __user *compat_alloc_user_space(long len)
{
struct pt_regs *regs = task_pt_regs(current);
return (void __user *)regs->rsp - len;
}
As this is dealing with mem blocks, I suppose it's counting in bytes, so
we could do something like:
return (void __user *)((u8*)regs->rsp - len);
so the arithmetic knows how to inc/dec for each unity...
I think the warning is correct and that void* arithmetic is undefined in C,
isn't it ?
TIA
--
J.A. Magallon \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam01 (gcc 4.2.2 20070909 (4.2.2-0.RC.1mdv2008.0)) SMP PREEMPT
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
void* arithmnetic
Hi all...
Since begin of the ages the build of the nvidia driver says things like
this:
include/asm/compat.h:210: warning: pointer of type 'void *' used in arithmetic
There are several of this warnings. The code in question for this example
is:
static __inline__ void __user *compat_alloc_user_space(long len)
{
struct pt_regs *regs = task_pt_regs(current);
return (void __user *)regs-rsp - len;
}
As this is dealing with mem blocks, I suppose it's counting in bytes, so
we could do something like:
return (void __user *)((u8*)regs-rsp - len);
so the arithmetic knows how to inc/dec for each unity...
I think the warning is correct and that void* arithmetic is undefined in C,
isn't it ?
TIA
--
J.A. Magallon jamagallon()ono!com \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam01 (gcc 4.2.2 20070909 (4.2.2-0.RC.1mdv2008.0)) SMP PREEMPT
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Opteron box and 4Gb memory
On Mon, 5 Nov 2007 13:50:40 -0500, [EMAIL PROTECTED] (Lennart Sorensen) wrote: > On Mon, Nov 05, 2007 at 07:45:21PM +0100, J.A. Magall?n wrote: > > Well, problem solved... > > > > I'm going to kill all pc assemblers in the world... Someone should teach > > them > > to learn mauals before assembling anything but a power chord. > > > > The memory was not paired, so the motherboard was not interleaving the > > access. > > With no inter-node but with inter-module interleaving, and a couple 1Gb > > sticks > > for each processor now I get something like: > > > > cicely:~/bn> bn > > name: cicely.cps.unizar.es > > arch: x86-64 > > proc: 4 x x86_64 @ 2200 MHz > > ram: 3555 Mb > > os: unx, Linux, 2.6.23.1-desktop-1mdv > > cc: gcc-4.3.0 > > vector size : 8 x 1024 x 1024 > > allocation: 0.02 ms > > int scl add: .. 60.56 ms, 138.52 Mips | 62.96 Mips /GHz > > int scl mul: .. 59.34 ms, 141.36 Mips | 64.26 Mips /GHz > > flt scl add: .. 59.01 ms, 142.16 Mflops | 64.62 Mflops/GHz > > flt vec add: .. 14.79 ms, 567.06 Mflops | 257.75 Mflops/GHz > > flt scl mul: .. 59.02 ms, 142.12 Mflops | 64.60 Mflops/GHz > > flt vec mul: .. 14.82 ms, 566.19 Mflops | 257.36 Mflops/GHz > > total: 5019.86 ms > > > > Much better, but not like the other opteron box. > > > > My processors are higher than Rev E0, because the BIOS does not let me > > choose > > the 'software' hole. If I activate the 'hardware hole', I see al the memory > > I can: > > > > cicely:~/bn> free > > total used free sharedbuffers cached > > Mem: 3640628 2144963426132 0 21240 84184 > > -/+ buffers/cache: 1090723531556 > > Swap: 4200988 04200988 > > > > 3.64 Gb. The rest is eaten by the graphics card, as I could read in the > > AMD site. Don't know if mem=4096 to boot the kernel would help, even if it > > is possible (don't think so, as it looks like a BIOS mis-feature). > > The ram is DDR 400. > > The video card is stealing 300MB of ram? What for? What does the mtrr > and e820 map look like with the hardware hole enabled? > (correction, this was not AMD website but SuperMicro's) I just said the same... Board is a SuperMicro H8DCE. From the FAQ section at supermicro: Question I have an H8DCE motherboard with 4 x 1GB DIMMS installed but the amount of memory displayed in the BIOS is 3.865GB and in 64-bit XP is 3.76GB. I have the hardware memory hole option enabled in BIOS (rev 1.1a). How I can get the board to count the full 4GB of memory? Answer The total available size depends on the PCI-e card you are using; some high-end cards may occupy more memory. For example, with a Quadro FX4500 on the H8DCE with the memory hole enabled, 4GB memory will show up as 3728MB in BIOS and 3.64GB in Windows. For some low-end PCI-e VGA cards, it may show up as 4048MB in BIOS. Why ? Who knows... Chipset is all nVidia. I have a GeForce 8800GTX with 768 Mb. It eats up 400Mb. This are my settings: BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e6000 - 0010 (reserved) BIOS-e820: 0010 - 9ffd (usable) BIOS-e820: 9ffd - 9ffde000 (ACPI data) BIOS-e820: 9ffde000 - a000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ff78 - 0001 (reserved) BIOS-e820: 0001 - 00014700 (usable) cicely:~# cat /proc/mtrr reg00: base=0x1 (4096MB), size=1024MB: write-back, count=1 reg01: base=0x14000 (5120MB), size= 64MB: write-back, count=1 reg02: base=0x14400 (5184MB), size= 32MB: write-back, count=1 reg03: base=0x14600 (5216MB), size= 16MB: write-back, count=1 reg04: base=0x ( 0MB), size=2048MB: write-back, count=1 reg05: base=0x8000 (2048MB), size= 512MB: write-back, count=1 This is with BIOS set for MTRR=Discrete. With MTRR=Continuous, the mtrr's are simpler, a full range and a non-usable hole. Which is better for Linux ? Many separate usable zones or one big zone and an un-usable hole ? BTW, mtrr formatting should be set to 0x%013lx000, to get them aligned with nowadays memory amounts and similar to e820 map, 16 hex digits... > > Anyways, can I trust what dmidecode says ? I installed the ram as the board > > manual said in banks 1A+1B (not 2A+2B) for each processor, but this program > > says this: > > > > BANK0 64MbBANK4 64Mb > > BANK1 64MbBANK5 64Mb > > BANK2 1024MbBANK6 1024Mb > > BANK3 1024MbBANK7 1024Mb > > > > I would always have thought that BANK0 would be slot 1A in first processor, > > but it looks like not... > > And where do the 64 Mb
Re: Opteron box and 4Gb memory
On Mon, 5 Nov 2007 13:10:46 -0500, [EMAIL PROTECTED] (Lennart Sorensen) wrote: > On Mon, Nov 05, 2007 at 12:18:47AM +0100, J.A. Magall?n wrote: > > Well, I was able to get about 3 Gb with MTRR=discrete in the BIOS, > > but I'm still in the process to find the 'software hole' option to get > > the rest of the 4Gb... > > > > But now another (perhaps related) question has arised... > > I like all those 5-line progams to test system performance...;). > > I just wrote a simple program that sums/muls int/float vectors with > > scalar/sse operations. And my opteron box looks terribly slow. > > > > This is my MacPro, Xeon 5130: > > > > belly:~/bn> bn > > proc: 4 x MacPro1,1 @ 2000 MHz > > ram: 2048 Mb > > os: unx, Darwin, 9.0.0 > > cc: gcc-4.0.1 > > vector size : 8 x 1024 x 1024 > > allocation: 0.01 ms > > int scl add: .. 36.78 ms, 228.07 Mips | 114.03 Mips /GHz > > int scl mul: .. 34.30 ms, 244.60 Mips | 122.30 Mips /GHz > > flt scl add: .. 34.28 ms, 244.73 Mflops | 122.37 Mflops/GHz > > flt vec add: ..7.89 ms, 1063.15 Mflops | 531.58 Mflops/GHz > > flt scl mul: .. 34.20 ms, 245.28 Mflops | 122.64 Mflops/GHz > > flt vec mul: ..7.90 ms, 1061.77 Mflops | 530.89 Mflops/GHz > > total: 3322.19 ms > > > > This is a normal (I think) opteron box (Opteron 846): > > > > selene:~/bn> g > > proc: 4 x x86_64 @ 2004 MHz > > ram: 3496 Mb > > os: unx, Linux, 2.6.9-42.0.10.ELsmp > > cc: gcc-4.0.2 > > vector size : 8 x 1024 x 1024 > > allocation: 0.05 ms > > int scl add: .. 45.98 ms, 182.42 Mips | 91.03 Mips /GHz > > int scl mul: .. 44.31 ms, 189.30 Mips | 94.46 Mips /GHz > > flt scl add: .. 44.52 ms, 188.41 Mflops | 94.02 Mflops/GHz > > flt vec add: .. 10.03 ms, 836.70 Mflops | 417.52 Mflops/GHz > > flt scl mul: .. 43.32 ms, 193.63 Mflops | 96.62 Mflops/GHz > > flt vec mul: .. 10.02 ms, 836.98 Mflops | 417.65 Mflops/GHz > > total: 4705.07 ms > > > > And this is my opteron (Opteron 275) > > > > cicely:~/bn> g > > proc: 4 x x86_64 @ 2200 MHz > > ram: 2914 Mb > > os: unx, Linux, 2.6.23.1-desktop-1mdv > > cc: gcc-4.0.2 > > vector size : 8 x 1024 x 1024 > > allocation: 0.03 ms > > int scl add: .. 87.67 ms, 95.68 Mips | 43.49 Mips /GHz > > int scl mul: .. 85.48 ms, 98.13 Mips | 44.61 Mips /GHz > > flt scl add: .. 85.90 ms, 97.66 Mflops | 44.39 Mflops/GHz > > flt vec add: .. 19.51 ms, 429.96 Mflops | 195.44 Mflops/GHz > > flt scl mul: .. 85.86 ms, 97.70 Mflops | 44.41 Mflops/GHz > > flt vec mul: .. 19.50 ms, 430.11 Mflops | 195.50 Mflops/GHz > > total: 6334.96 ms > > > > As I read in AMD site, the only difference that matters in models is > > the xx5 vx xx6, related to fequency, but the processors should be just > > the same. > > > > As this only does intensive memory/fp operations, I'm not going to blame > > gcc nor kernel versions here (I have compared gcc 3.4, 4.0, 4.1, and 4.2 > > on one of the boxes and results are very similar, the code is really > > stupid and not very suitable for compiler smartness...). > > I suspect it is a memory problem. It can be hardware or caused by > > incorrect BIOS/kernel-mtrr setup: > > > > selene:~> cat /proc/mtrr > > reg00: base=0x ( 0MB), size=16384MB: write-back, count=1 > > reg01: base=0xf000 (3840MB), size= 256MB: uncachable, count=1 > > > > cicely:~> cat /proc/mtrr > > reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 > > reg01: base=0x8000 (2048MB), size= 512MB: write-back, count=1 > > reg02: base=0xa000 (2560MB), size= 256MB: write-back, count=1 > > reg03: base=0xb000 (2816MB), size= 128MB: write-back, count=1 > > reg04: base=0xb800 (2944MB), size= 16MB: write-back, count=1 > > > > > > Any idea on what can be going on here ? I have asked the 'good opteron' > > admin info about the mobo an memory of the box. > > > > Any help will be _very_ appreciated. > > Well what revisions are the two opterons? Is one running dual channel > memory while the other isn't perhaps? What speed and type is the ram on > the two opterons? > Well, problem solved... I'm going to kill all pc assemblers in the world... Someone should teach them to learn mauals before assembling anything but a power chord. The memory was not paired, so the motherboard was not interleaving the access. With no inter-node but with inter-module interleaving, and a couple 1Gb sticks for each processor now I get something like: cicely:~/bn> bn name: cicely.cps.unizar.es arch: x86-64 proc: 4 x x86_64 @ 2200 MHz ram: 3555 Mb os: unx, Linux, 2.6.23.1-desktop-1mdv cc: gcc-4.3.0 vector size : 8 x 1024 x 1024 allocation: 0.02 ms int scl add: .. 60.56 ms, 138.52
Re: Opteron box and 4Gb memory
On Mon, 5 Nov 2007 13:10:46 -0500, [EMAIL PROTECTED] (Lennart Sorensen) wrote: On Mon, Nov 05, 2007 at 12:18:47AM +0100, J.A. Magall?n wrote: Well, I was able to get about 3 Gb with MTRR=discrete in the BIOS, but I'm still in the process to find the 'software hole' option to get the rest of the 4Gb... But now another (perhaps related) question has arised... I like all those 5-line progams to test system performance...;). I just wrote a simple program that sums/muls int/float vectors with scalar/sse operations. And my opteron box looks terribly slow. This is my MacPro, Xeon 5130: belly:~/bn bn proc: 4 x MacPro1,1 @ 2000 MHz ram: 2048 Mb os: unx, Darwin, 9.0.0 cc: gcc-4.0.1 vector size : 8 x 1024 x 1024 allocation: 0.01 ms int scl add: .. 36.78 ms, 228.07 Mips | 114.03 Mips /GHz int scl mul: .. 34.30 ms, 244.60 Mips | 122.30 Mips /GHz flt scl add: .. 34.28 ms, 244.73 Mflops | 122.37 Mflops/GHz flt vec add: ..7.89 ms, 1063.15 Mflops | 531.58 Mflops/GHz flt scl mul: .. 34.20 ms, 245.28 Mflops | 122.64 Mflops/GHz flt vec mul: ..7.90 ms, 1061.77 Mflops | 530.89 Mflops/GHz total: 3322.19 ms This is a normal (I think) opteron box (Opteron 846): selene:~/bn g proc: 4 x x86_64 @ 2004 MHz ram: 3496 Mb os: unx, Linux, 2.6.9-42.0.10.ELsmp cc: gcc-4.0.2 vector size : 8 x 1024 x 1024 allocation: 0.05 ms int scl add: .. 45.98 ms, 182.42 Mips | 91.03 Mips /GHz int scl mul: .. 44.31 ms, 189.30 Mips | 94.46 Mips /GHz flt scl add: .. 44.52 ms, 188.41 Mflops | 94.02 Mflops/GHz flt vec add: .. 10.03 ms, 836.70 Mflops | 417.52 Mflops/GHz flt scl mul: .. 43.32 ms, 193.63 Mflops | 96.62 Mflops/GHz flt vec mul: .. 10.02 ms, 836.98 Mflops | 417.65 Mflops/GHz total: 4705.07 ms And this is my opteron (Opteron 275) cicely:~/bn g proc: 4 x x86_64 @ 2200 MHz ram: 2914 Mb os: unx, Linux, 2.6.23.1-desktop-1mdv cc: gcc-4.0.2 vector size : 8 x 1024 x 1024 allocation: 0.03 ms int scl add: .. 87.67 ms, 95.68 Mips | 43.49 Mips /GHz int scl mul: .. 85.48 ms, 98.13 Mips | 44.61 Mips /GHz flt scl add: .. 85.90 ms, 97.66 Mflops | 44.39 Mflops/GHz flt vec add: .. 19.51 ms, 429.96 Mflops | 195.44 Mflops/GHz flt scl mul: .. 85.86 ms, 97.70 Mflops | 44.41 Mflops/GHz flt vec mul: .. 19.50 ms, 430.11 Mflops | 195.50 Mflops/GHz total: 6334.96 ms As I read in AMD site, the only difference that matters in models is the xx5 vx xx6, related to fequency, but the processors should be just the same. As this only does intensive memory/fp operations, I'm not going to blame gcc nor kernel versions here (I have compared gcc 3.4, 4.0, 4.1, and 4.2 on one of the boxes and results are very similar, the code is really stupid and not very suitable for compiler smartness...). I suspect it is a memory problem. It can be hardware or caused by incorrect BIOS/kernel-mtrr setup: selene:~ cat /proc/mtrr reg00: base=0x ( 0MB), size=16384MB: write-back, count=1 reg01: base=0xf000 (3840MB), size= 256MB: uncachable, count=1 cicely:~ cat /proc/mtrr reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size= 512MB: write-back, count=1 reg02: base=0xa000 (2560MB), size= 256MB: write-back, count=1 reg03: base=0xb000 (2816MB), size= 128MB: write-back, count=1 reg04: base=0xb800 (2944MB), size= 16MB: write-back, count=1 Any idea on what can be going on here ? I have asked the 'good opteron' admin info about the mobo an memory of the box. Any help will be _very_ appreciated. Well what revisions are the two opterons? Is one running dual channel memory while the other isn't perhaps? What speed and type is the ram on the two opterons? Well, problem solved... I'm going to kill all pc assemblers in the world... Someone should teach them to learn mauals before assembling anything but a power chord. The memory was not paired, so the motherboard was not interleaving the access. With no inter-node but with inter-module interleaving, and a couple 1Gb sticks for each processor now I get something like: cicely:~/bn bn name: cicely.cps.unizar.es arch: x86-64 proc: 4 x x86_64 @ 2200 MHz ram: 3555 Mb os: unx, Linux, 2.6.23.1-desktop-1mdv cc: gcc-4.3.0 vector size : 8 x 1024 x 1024 allocation: 0.02 ms int scl add: .. 60.56 ms, 138.52 Mips | 62.96 Mips /GHz int scl mul: .. 59.34 ms, 141.36 Mips | 64.26 Mips /GHz flt scl add: .. 59.01 ms, 142.16 Mflops | 64.62 Mflops/GHz flt vec add:
Re: Opteron box and 4Gb memory
On Mon, 5 Nov 2007 13:50:40 -0500, [EMAIL PROTECTED] (Lennart Sorensen) wrote: On Mon, Nov 05, 2007 at 07:45:21PM +0100, J.A. Magall?n wrote: Well, problem solved... I'm going to kill all pc assemblers in the world... Someone should teach them to learn mauals before assembling anything but a power chord. The memory was not paired, so the motherboard was not interleaving the access. With no inter-node but with inter-module interleaving, and a couple 1Gb sticks for each processor now I get something like: cicely:~/bn bn name: cicely.cps.unizar.es arch: x86-64 proc: 4 x x86_64 @ 2200 MHz ram: 3555 Mb os: unx, Linux, 2.6.23.1-desktop-1mdv cc: gcc-4.3.0 vector size : 8 x 1024 x 1024 allocation: 0.02 ms int scl add: .. 60.56 ms, 138.52 Mips | 62.96 Mips /GHz int scl mul: .. 59.34 ms, 141.36 Mips | 64.26 Mips /GHz flt scl add: .. 59.01 ms, 142.16 Mflops | 64.62 Mflops/GHz flt vec add: .. 14.79 ms, 567.06 Mflops | 257.75 Mflops/GHz flt scl mul: .. 59.02 ms, 142.12 Mflops | 64.60 Mflops/GHz flt vec mul: .. 14.82 ms, 566.19 Mflops | 257.36 Mflops/GHz total: 5019.86 ms Much better, but not like the other opteron box. My processors are higher than Rev E0, because the BIOS does not let me choose the 'software' hole. If I activate the 'hardware hole', I see al the memory I can: cicely:~/bn free total used free sharedbuffers cached Mem: 3640628 2144963426132 0 21240 84184 -/+ buffers/cache: 1090723531556 Swap: 4200988 04200988 3.64 Gb. The rest is eaten by the graphics card, as I could read in the AMD site. Don't know if mem=4096 to boot the kernel would help, even if it is possible (don't think so, as it looks like a BIOS mis-feature). The ram is DDR 400. The video card is stealing 300MB of ram? What for? What does the mtrr and e820 map look like with the hardware hole enabled? (correction, this was not AMD website but SuperMicro's) I just said the same... Board is a SuperMicro H8DCE. From the FAQ section at supermicro: Question I have an H8DCE motherboard with 4 x 1GB DIMMS installed but the amount of memory displayed in the BIOS is 3.865GB and in 64-bit XP is 3.76GB. I have the hardware memory hole option enabled in BIOS (rev 1.1a). How I can get the board to count the full 4GB of memory? Answer The total available size depends on the PCI-e card you are using; some high-end cards may occupy more memory. For example, with a Quadro FX4500 on the H8DCE with the memory hole enabled, 4GB memory will show up as 3728MB in BIOS and 3.64GB in Windows. For some low-end PCI-e VGA cards, it may show up as 4048MB in BIOS. Why ? Who knows... Chipset is all nVidia. I have a GeForce 8800GTX with 768 Mb. It eats up 400Mb. This are my settings: BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e6000 - 0010 (reserved) BIOS-e820: 0010 - 9ffd (usable) BIOS-e820: 9ffd - 9ffde000 (ACPI data) BIOS-e820: 9ffde000 - a000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ff78 - 0001 (reserved) BIOS-e820: 0001 - 00014700 (usable) cicely:~# cat /proc/mtrr reg00: base=0x1 (4096MB), size=1024MB: write-back, count=1 reg01: base=0x14000 (5120MB), size= 64MB: write-back, count=1 reg02: base=0x14400 (5184MB), size= 32MB: write-back, count=1 reg03: base=0x14600 (5216MB), size= 16MB: write-back, count=1 reg04: base=0x ( 0MB), size=2048MB: write-back, count=1 reg05: base=0x8000 (2048MB), size= 512MB: write-back, count=1 This is with BIOS set for MTRR=Discrete. With MTRR=Continuous, the mtrr's are simpler, a full range and a non-usable hole. Which is better for Linux ? Many separate usable zones or one big zone and an un-usable hole ? BTW, mtrr formatting should be set to 0x%013lx000, to get them aligned with nowadays memory amounts and similar to e820 map, 16 hex digits... Anyways, can I trust what dmidecode says ? I installed the ram as the board manual said in banks 1A+1B (not 2A+2B) for each processor, but this program says this: BANK0 64MbBANK4 64Mb BANK1 64MbBANK5 64Mb BANK2 1024MbBANK6 1024Mb BANK3 1024MbBANK7 1024Mb I would always have thought that BANK0 would be slot 1A in first processor, but it looks like not... And where do the 64 Mb blocks come from ? Well if you ahve 4 sticks of 1GB, then I would hope they are installed as a pair for each CPU so
Re: Opteron box and 4Gb memory
On Thu, 25 Oct 2007 14:58:10 -0700, "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > J.A. Magallon wrote: > > Hi... > > > > I have some Quad-Opteron boxes with 4Gb memory and two of them are > > running two different Linux distros. > > > > Box one sees 4Gb of memory, but box two just sees 3. > > Their mtrr setups are different: > > > > Why ? Is it a bios setup problem ? A kernel problem ? > > grep HIGHMEN in configs for both kernels does not give anything, so > > I still understand less this thing... > > > > It would depend on how the BIOS programmed the memory controllers. For > 32-bit (and lots of device) compatibility, a memory hole is required > below 4 GB. Not all memory controllers can remap memory in the 3-4 GB > range above the 4 GB memory; I'm not sure if that varies with the > different Opteron processors. > Well, I was able to get about 3 Gb with MTRR=discrete in the BIOS, but I'm still in the process to find the 'software hole' option to get the rest of the 4Gb... But now another (perhaps related) question has arised... I like all those 5-line progams to test system performance...;). I just wrote a simple program that sums/muls int/float vectors with scalar/sse operations. And my opteron box looks terribly slow. This is my MacPro, Xeon 5130: belly:~/bn> bn proc: 4 x MacPro1,1 @ 2000 MHz ram: 2048 Mb os: unx, Darwin, 9.0.0 cc: gcc-4.0.1 vector size : 8 x 1024 x 1024 allocation: 0.01 ms int scl add: .. 36.78 ms, 228.07 Mips | 114.03 Mips /GHz int scl mul: .. 34.30 ms, 244.60 Mips | 122.30 Mips /GHz flt scl add: .. 34.28 ms, 244.73 Mflops | 122.37 Mflops/GHz flt vec add: ..7.89 ms, 1063.15 Mflops | 531.58 Mflops/GHz flt scl mul: .. 34.20 ms, 245.28 Mflops | 122.64 Mflops/GHz flt vec mul: ..7.90 ms, 1061.77 Mflops | 530.89 Mflops/GHz total: 3322.19 ms This is a normal (I think) opteron box (Opteron 846): selene:~/bn> g proc: 4 x x86_64 @ 2004 MHz ram: 3496 Mb os: unx, Linux, 2.6.9-42.0.10.ELsmp cc: gcc-4.0.2 vector size : 8 x 1024 x 1024 allocation: 0.05 ms int scl add: .. 45.98 ms, 182.42 Mips | 91.03 Mips /GHz int scl mul: .. 44.31 ms, 189.30 Mips | 94.46 Mips /GHz flt scl add: .. 44.52 ms, 188.41 Mflops | 94.02 Mflops/GHz flt vec add: .. 10.03 ms, 836.70 Mflops | 417.52 Mflops/GHz flt scl mul: .. 43.32 ms, 193.63 Mflops | 96.62 Mflops/GHz flt vec mul: .. 10.02 ms, 836.98 Mflops | 417.65 Mflops/GHz total: 4705.07 ms And this is my opteron (Opteron 275) cicely:~/bn> g proc: 4 x x86_64 @ 2200 MHz ram: 2914 Mb os: unx, Linux, 2.6.23.1-desktop-1mdv cc: gcc-4.0.2 vector size : 8 x 1024 x 1024 allocation: 0.03 ms int scl add: .. 87.67 ms, 95.68 Mips | 43.49 Mips /GHz int scl mul: .. 85.48 ms, 98.13 Mips | 44.61 Mips /GHz flt scl add: .. 85.90 ms, 97.66 Mflops | 44.39 Mflops/GHz flt vec add: .. 19.51 ms, 429.96 Mflops | 195.44 Mflops/GHz flt scl mul: .. 85.86 ms, 97.70 Mflops | 44.41 Mflops/GHz flt vec mul: .. 19.50 ms, 430.11 Mflops | 195.50 Mflops/GHz total: 6334.96 ms As I read in AMD site, the only difference that matters in models is the xx5 vx xx6, related to fequency, but the processors should be just the same. As this only does intensive memory/fp operations, I'm not going to blame gcc nor kernel versions here (I have compared gcc 3.4, 4.0, 4.1, and 4.2 on one of the boxes and results are very similar, the code is really stupid and not very suitable for compiler smartness...). I suspect it is a memory problem. It can be hardware or caused by incorrect BIOS/kernel-mtrr setup: selene:~> cat /proc/mtrr reg00: base=0x ( 0MB), size=16384MB: write-back, count=1 reg01: base=0xf000 (3840MB), size= 256MB: uncachable, count=1 cicely:~> cat /proc/mtrr reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size= 512MB: write-back, count=1 reg02: base=0xa000 (2560MB), size= 256MB: write-back, count=1 reg03: base=0xb000 (2816MB), size= 128MB: write-back, count=1 reg04: base=0xb800 (2944MB), size= 16MB: write-back, count=1 Any idea on what can be going on here ? I have asked the 'good opteron' admin info about the mobo an memory of the box. Any help will be _very_ appreciated. TIA -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam01 (gcc 4.2.2 20070909 (4.2.2-0.RC.1mdv2008.0)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo
Re: Opteron box and 4Gb memory
On Thu, 25 Oct 2007 14:58:10 -0700, H. Peter Anvin [EMAIL PROTECTED] wrote: J.A. Magallon wrote: Hi... I have some Quad-Opteron boxes with 4Gb memory and two of them are running two different Linux distros. Box one sees 4Gb of memory, but box two just sees 3. Their mtrr setups are different: Why ? Is it a bios setup problem ? A kernel problem ? grep HIGHMEN in configs for both kernels does not give anything, so I still understand less this thing... It would depend on how the BIOS programmed the memory controllers. For 32-bit (and lots of device) compatibility, a memory hole is required below 4 GB. Not all memory controllers can remap memory in the 3-4 GB range above the 4 GB memory; I'm not sure if that varies with the different Opteron processors. Well, I was able to get about 3 Gb with MTRR=discrete in the BIOS, but I'm still in the process to find the 'software hole' option to get the rest of the 4Gb... But now another (perhaps related) question has arised... I like all those 5-line progams to test system performance...;). I just wrote a simple program that sums/muls int/float vectors with scalar/sse operations. And my opteron box looks terribly slow. This is my MacPro, Xeon 5130: belly:~/bn bn proc: 4 x MacPro1,1 @ 2000 MHz ram: 2048 Mb os: unx, Darwin, 9.0.0 cc: gcc-4.0.1 vector size : 8 x 1024 x 1024 allocation: 0.01 ms int scl add: .. 36.78 ms, 228.07 Mips | 114.03 Mips /GHz int scl mul: .. 34.30 ms, 244.60 Mips | 122.30 Mips /GHz flt scl add: .. 34.28 ms, 244.73 Mflops | 122.37 Mflops/GHz flt vec add: ..7.89 ms, 1063.15 Mflops | 531.58 Mflops/GHz flt scl mul: .. 34.20 ms, 245.28 Mflops | 122.64 Mflops/GHz flt vec mul: ..7.90 ms, 1061.77 Mflops | 530.89 Mflops/GHz total: 3322.19 ms This is a normal (I think) opteron box (Opteron 846): selene:~/bn g proc: 4 x x86_64 @ 2004 MHz ram: 3496 Mb os: unx, Linux, 2.6.9-42.0.10.ELsmp cc: gcc-4.0.2 vector size : 8 x 1024 x 1024 allocation: 0.05 ms int scl add: .. 45.98 ms, 182.42 Mips | 91.03 Mips /GHz int scl mul: .. 44.31 ms, 189.30 Mips | 94.46 Mips /GHz flt scl add: .. 44.52 ms, 188.41 Mflops | 94.02 Mflops/GHz flt vec add: .. 10.03 ms, 836.70 Mflops | 417.52 Mflops/GHz flt scl mul: .. 43.32 ms, 193.63 Mflops | 96.62 Mflops/GHz flt vec mul: .. 10.02 ms, 836.98 Mflops | 417.65 Mflops/GHz total: 4705.07 ms And this is my opteron (Opteron 275) cicely:~/bn g proc: 4 x x86_64 @ 2200 MHz ram: 2914 Mb os: unx, Linux, 2.6.23.1-desktop-1mdv cc: gcc-4.0.2 vector size : 8 x 1024 x 1024 allocation: 0.03 ms int scl add: .. 87.67 ms, 95.68 Mips | 43.49 Mips /GHz int scl mul: .. 85.48 ms, 98.13 Mips | 44.61 Mips /GHz flt scl add: .. 85.90 ms, 97.66 Mflops | 44.39 Mflops/GHz flt vec add: .. 19.51 ms, 429.96 Mflops | 195.44 Mflops/GHz flt scl mul: .. 85.86 ms, 97.70 Mflops | 44.41 Mflops/GHz flt vec mul: .. 19.50 ms, 430.11 Mflops | 195.50 Mflops/GHz total: 6334.96 ms As I read in AMD site, the only difference that matters in models is the xx5 vx xx6, related to fequency, but the processors should be just the same. As this only does intensive memory/fp operations, I'm not going to blame gcc nor kernel versions here (I have compared gcc 3.4, 4.0, 4.1, and 4.2 on one of the boxes and results are very similar, the code is really stupid and not very suitable for compiler smartness...). I suspect it is a memory problem. It can be hardware or caused by incorrect BIOS/kernel-mtrr setup: selene:~ cat /proc/mtrr reg00: base=0x ( 0MB), size=16384MB: write-back, count=1 reg01: base=0xf000 (3840MB), size= 256MB: uncachable, count=1 cicely:~ cat /proc/mtrr reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x8000 (2048MB), size= 512MB: write-back, count=1 reg02: base=0xa000 (2560MB), size= 256MB: write-back, count=1 reg03: base=0xb000 (2816MB), size= 128MB: write-back, count=1 reg04: base=0xb800 (2944MB), size= 16MB: write-back, count=1 Any idea on what can be going on here ? I have asked the 'good opteron' admin info about the mobo an memory of the box. Any help will be _very_ appreciated. TIA -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam01 (gcc 4.2.2 20070909 (4.2.2-0.RC.1mdv2008.0)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at
Re: Opteron box and 4Gb memory
On Thu, 25 Oct 2007 14:58:10 -0700, "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > J.A. Magallon wrote: > > Hi... > > > > I have some Quad-Opteron boxes with 4Gb memory and two of them are > > running two different Linux distros. > > > > Box one sees 4Gb of memory, but box two just sees 3. > > Their mtrr setups are different: > > > > Why ? Is it a bios setup problem ? A kernel problem ? > > grep HIGHMEN in configs for both kernels does not give anything, so > > I still understand less this thing... > > > > It would depend on how the BIOS programmed the memory controllers. For > 32-bit (and lots of device) compatibility, a memory hole is required > below 4 GB. Not all memory controllers can remap memory in the 3-4 GB > range above the 4 GB memory; I'm not sure if that varies with the > different Opteron processors. I have collected several pieces of info around the internet... - Some people uses this options in the BIOS: Node interleave: off Bank interleave: auto SW memory hole: disable HW memory hole: enable MTRR: Continuous - Node Memory Interleaving DISABLES NUMA and generally is a bad thing - MTRR setting -should be set to "discrete" for Linux, and probably for Windows too. - This is what SuperMicro's tech support said about 2.96GB vs. 4GB. "This is as expected, as soon as you set "software memory hole" to disabled, you also disable option ROM remapping functionality, this option normally remaps used option rom (option rom= raid bios, lan pxe ; usb legacy, bioses on add-on cards, etc) in the 4GB region, so no basis memory is lost, while this feature is now disabled the option rom space occupies the space between 3 and 4 GB which results in lower main memory availability. There is no solution or work around for this phenomenon" so software memory hole enabled might be needed to get all 4GB to show up >From mobo manual: Software Memory Hole When "Enabled", allows software memory remapping around the memory hole. Options are Enabled and Disabled. Hardware Memory Hole When "Enabled", allows software memory remapping around the memory hole. Options are Enabled and Disabled. Note: this is only supported by Rev E0 processors and above. ( I have two Opteron 275 processors, no idea about revision) So _my_ conclussion is: Node interleave: off(numa mode) Bank interleave: auto SW memory hole: disable | HW memory hole: enable | allow remapping MTRR: Discrete | But then, do I need to enable NUMA options in the kernel ? > > Also, if you run a 32-bit distribution, you need to have HIGHMEM_64G > enabled in the kernel. > I run a 64 bit one, then I don't need anything, isn't it ? That's why I don't see any _HIGHMEM in the kernel configs... Some day I will understand this crappy BIOS thing (or burn a photo of its inventor...). Why can't we have OpenFirmware PC's, like my MacPro and Sparcs ? -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam01 (gcc 4.2.2 20070909 (4.2.2-0.RC.1mdv2008.0)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Opteron box and 4Gb memory
On Thu, 25 Oct 2007 14:58:10 -0700, H. Peter Anvin [EMAIL PROTECTED] wrote: J.A. Magallon wrote: Hi... I have some Quad-Opteron boxes with 4Gb memory and two of them are running two different Linux distros. Box one sees 4Gb of memory, but box two just sees 3. Their mtrr setups are different: Why ? Is it a bios setup problem ? A kernel problem ? grep HIGHMEN in configs for both kernels does not give anything, so I still understand less this thing... It would depend on how the BIOS programmed the memory controllers. For 32-bit (and lots of device) compatibility, a memory hole is required below 4 GB. Not all memory controllers can remap memory in the 3-4 GB range above the 4 GB memory; I'm not sure if that varies with the different Opteron processors. I have collected several pieces of info around the internet... - Some people uses this options in the BIOS: Node interleave: off Bank interleave: auto SW memory hole: disable HW memory hole: enable MTRR: Continuous - Node Memory Interleaving DISABLES NUMA and generally is a bad thing - MTRR setting -should be set to discrete for Linux, and probably for Windows too. - This is what SuperMicro's tech support said about 2.96GB vs. 4GB. This is as expected, as soon as you set software memory hole to disabled, you also disable option ROM remapping functionality, this option normally remaps used option rom (option rom= raid bios, lan pxe ; usb legacy, bioses on add-on cards, etc) in the 4GB region, so no basis memory is lost, while this feature is now disabled the option rom space occupies the space between 3 and 4 GB which results in lower main memory availability. There is no solution or work around for this phenomenon so software memory hole enabled might be needed to get all 4GB to show up From mobo manual: Software Memory Hole When Enabled, allows software memory remapping around the memory hole. Options are Enabled and Disabled. Hardware Memory Hole When Enabled, allows software memory remapping around the memory hole. Options are Enabled and Disabled. Note: this is only supported by Rev E0 processors and above. ( I have two Opteron 275 processors, no idea about revision) So _my_ conclussion is: Node interleave: off(numa mode) Bank interleave: auto SW memory hole: disable | HW memory hole: enable | allow remapping MTRR: Discrete | But then, do I need to enable NUMA options in the kernel ? Also, if you run a 32-bit distribution, you need to have HIGHMEM_64G enabled in the kernel. I run a 64 bit one, then I don't need anything, isn't it ? That's why I don't see any _HIGHMEM in the kernel configs... Some day I will understand this crappy BIOS thing (or burn a photo of its inventor...). Why can't we have OpenFirmware PC's, like my MacPro and Sparcs ? -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam01 (gcc 4.2.2 20070909 (4.2.2-0.RC.1mdv2008.0)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] debloat aic7xxx and aic79xx drivers
On Sun, 14 Oct 2007 15:58:26 +0100, Denys Vlasenko <[EMAIL PROTECTED]> wrote: > Hi, > > Following patches debloat drivers/scsi/aic7xxx/*. > I also had to add prototypes for ahc_lookup_scb > and ahd_lookup_scb to .h files. > Sorry for the late replay, but.. working fine on annwn:~# lspci | grep Adap 03:02.0 SCSI storage controller: Adaptec ASC-29320 U320 (rev 03) 03:02.1 SCSI storage controller: Adaptec ASC-29320 U320 (rev 03) annwn:~# lsscsi -H [1]aic79xx [2]aic79xx with annwn:~# lsscsi [2:0:0:0]diskSEAGATE ST336807LW 0C01 /dev/sdb [2:0:1:0]diskSEAGATE ST336807LW 0C01 /dev/sdc [2:0:2:0]diskSEAGATE ST336807LW 0C01 /dev/sdd [2:0:3:0]diskSEAGATE ST336807LW 0C01 /dev/sde and giving up to 200Mb/s on a pretty old mobo (see cached reads) with raid5: annwn:~# hdparm -tT /dev/sd[bcde] /dev/sdb: Timing cached reads: 950 MB in 2.00 seconds = 474.23 MB/sec Timing buffered disk reads: 228 MB in 3.00 seconds = 75.93 MB/sec /dev/sdc: Timing cached reads: 1020 MB in 2.00 seconds = 510.01 MB/sec Timing buffered disk reads: 228 MB in 3.01 seconds = 75.76 MB/sec /dev/sdd: Timing cached reads: 1022 MB in 2.00 seconds = 510.69 MB/sec Timing buffered disk reads: 228 MB in 3.01 seconds = 75.79 MB/sec /dev/sde: Timing cached reads: 1016 MB in 2.00 seconds = 507.92 MB/sec Timing buffered disk reads: 228 MB in 3.02 seconds = 75.48 MB/sec annwn:~# hdparm -tT /dev/md0 /dev/md0: Timing cached reads: 1020 MB in 2.00 seconds = 509.96 MB/sec Timing buffered disk reads: 602 MB in 3.01 seconds = 199.84 MB/sec -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam01 (gcc 4.2.2 20070909 (4.2.2-0.RC.1mdv2008.0)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] debloat aic7xxx and aic79xx drivers
On Sun, 14 Oct 2007 15:58:26 +0100, Denys Vlasenko [EMAIL PROTECTED] wrote: Hi, Following patches debloat drivers/scsi/aic7xxx/*. I also had to add prototypes for ahc_lookup_scb and ahd_lookup_scb to .h files. Sorry for the late replay, but.. working fine on annwn:~# lspci | grep Adap 03:02.0 SCSI storage controller: Adaptec ASC-29320 U320 (rev 03) 03:02.1 SCSI storage controller: Adaptec ASC-29320 U320 (rev 03) annwn:~# lsscsi -H [1]aic79xx [2]aic79xx with annwn:~# lsscsi [2:0:0:0]diskSEAGATE ST336807LW 0C01 /dev/sdb [2:0:1:0]diskSEAGATE ST336807LW 0C01 /dev/sdc [2:0:2:0]diskSEAGATE ST336807LW 0C01 /dev/sdd [2:0:3:0]diskSEAGATE ST336807LW 0C01 /dev/sde and giving up to 200Mb/s on a pretty old mobo (see cached reads) with raid5: annwn:~# hdparm -tT /dev/sd[bcde] /dev/sdb: Timing cached reads: 950 MB in 2.00 seconds = 474.23 MB/sec Timing buffered disk reads: 228 MB in 3.00 seconds = 75.93 MB/sec /dev/sdc: Timing cached reads: 1020 MB in 2.00 seconds = 510.01 MB/sec Timing buffered disk reads: 228 MB in 3.01 seconds = 75.76 MB/sec /dev/sdd: Timing cached reads: 1022 MB in 2.00 seconds = 510.69 MB/sec Timing buffered disk reads: 228 MB in 3.01 seconds = 75.79 MB/sec /dev/sde: Timing cached reads: 1016 MB in 2.00 seconds = 507.92 MB/sec Timing buffered disk reads: 228 MB in 3.02 seconds = 75.48 MB/sec annwn:~# hdparm -tT /dev/md0 /dev/md0: Timing cached reads: 1020 MB in 2.00 seconds = 509.96 MB/sec Timing buffered disk reads: 602 MB in 3.01 seconds = 199.84 MB/sec -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.1 (Cooker) for i586 Linux 2.6.23-jam01 (gcc 4.2.2 20070909 (4.2.2-0.RC.1mdv2008.0)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops with touch and unknown uid [was Re: 2.6.22-rc6-mm1]
On Thu, 28 Jun 2007 03:43:21 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/
>
I have noticed a funny problem.
Lets say 666 is not an uid used on you system. This oopses:
rm -f dummy
touch dummy
chown 666 dummy
touch dummy
Oops:
BUG: unable to handle kernel NULL pointer dereference at virtual address
006a
printing eip:
c0165281
*pde =
Oops: [#2]
PREEMPT SMP
Modules linked in: w83627hf hwmon_vid hwmon i2c_dev loop floppy udf microcode
snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm nvidia(P) snd_timer
3c59x snd_page_alloc snd_util_mem snd_hwdep snd usblp ohci1394 e1000 ieee1394
sata_promise emu10k1_gp gameport intel_agp i2c_i801 agpgart evdev sg
CPU:3
EIP:0060:[]Tainted: P D VLI
EFLAGS: 00210297 (2.6.21-jam12 #1)
EIP is at permission+0x4/0xa1
eax: ebx: c5785aa0 ecx: c43a1f04 edx: 0002
esi: edi: ebp: c3442c00 esp: c43a1ef0
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process touch (pid: 8401, ti=c43a1000 task=c25d69b0 task.ti=c43a1000)
Stack: c5785aa0 fff3 c017ba84 c43e9c50 c55c52a8 c43e9c50 c344ab7c 00c9
c3442c00 b7f14f70 c4f574d0 c2ea5400 c03ef580
0004 b7f14f70 c0125cac c4f574d0
Call Trace:
[] do_utimes+0x174/0x1b9
[] __atomic_notifier_call_chain+0x27/0x4d
[] do_page_fault+0x523/0x68d
[] sys_utimensat+0x22/0x92
[] do_page_fault+0x0/0x68d
[] sysenter_past_esp+0x5f/0x85
[] packet_setsockopt+0x279/0x325
===
Code: eb b1 66 c1 ee 06 8d 74 26 00 eb 8c 83 e7 02 75 c5 b8 02 00 00 00 8d 74
26 00 e8 16 bf fb ff 85 c0 74 b3 31 c0 eb c9 56 53 89 c6 <0f> b7 58 6a f6 c2 02
74 31 8b 80 a4 00 00 00 f6 40 30 01 74 1c
EIP: [] permission+0x4/0xa1 SS:ESP 0068:c43a1ef0
Any ideas ?
--
J.A. Magallon \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.0 (Cooker) for i586
Linux 2.6.21-jam12 (gcc 4.2.1 20070704 (4.2.1-3mdv2008.0)) SMP PREEMPT
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Oops with touch and unknown uid [was Re: 2.6.22-rc6-mm1]
On Thu, 28 Jun 2007 03:43:21 -0700, Andrew Morton [EMAIL PROTECTED] wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/
I have noticed a funny problem.
Lets say 666 is not an uid used on you system. This oopses:
rm -f dummy
touch dummy
chown 666 dummy
touch dummy
Oops:
BUG: unable to handle kernel NULL pointer dereference at virtual address
006a
printing eip:
c0165281
*pde =
Oops: [#2]
PREEMPT SMP
Modules linked in: w83627hf hwmon_vid hwmon i2c_dev loop floppy udf microcode
snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm nvidia(P) snd_timer
3c59x snd_page_alloc snd_util_mem snd_hwdep snd usblp ohci1394 e1000 ieee1394
sata_promise emu10k1_gp gameport intel_agp i2c_i801 agpgart evdev sg
CPU:3
EIP:0060:[c0165281]Tainted: P D VLI
EFLAGS: 00210297 (2.6.21-jam12 #1)
EIP is at permission+0x4/0xa1
eax: ebx: c5785aa0 ecx: c43a1f04 edx: 0002
esi: edi: ebp: c3442c00 esp: c43a1ef0
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process touch (pid: 8401, ti=c43a1000 task=c25d69b0 task.ti=c43a1000)
Stack: c5785aa0 fff3 c017ba84 c43e9c50 c55c52a8 c43e9c50 c344ab7c 00c9
c3442c00 b7f14f70 c4f574d0 c2ea5400 c03ef580
0004 b7f14f70 c0125cac c4f574d0
Call Trace:
[c017ba84] do_utimes+0x174/0x1b9
[c0125cac] __atomic_notifier_call_chain+0x27/0x4d
[c0111a06] do_page_fault+0x523/0x68d
[c017bbb3] sys_utimensat+0x22/0x92
[c01114e3] do_page_fault+0x0/0x68d
[c0102902] sysenter_past_esp+0x5f/0x85
[c030] packet_setsockopt+0x279/0x325
===
Code: eb b1 66 c1 ee 06 8d 74 26 00 eb 8c 83 e7 02 75 c5 b8 02 00 00 00 8d 74
26 00 e8 16 bf fb ff 85 c0 74 b3 31 c0 eb c9 56 53 89 c6 0f b7 58 6a f6 c2 02
74 31 8b 80 a4 00 00 00 f6 40 30 01 74 1c
EIP: [c0165281] permission+0x4/0xa1 SS:ESP 0068:c43a1ef0
Any ideas ?
--
J.A. Magallon jamagallon()ono!com \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.0 (Cooker) for i586
Linux 2.6.21-jam12 (gcc 4.2.1 20070704 (4.2.1-3mdv2008.0)) SMP PREEMPT
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Slow Soft-RAID 5 performance
On Wed, 18 Jul 2007 10:56:11 +0100, Rui Santos <[EMAIL PROTECTED]> wrote: > Hi, > > I'm getting a strange slow performance behavior on a recently installed > Server. Here are the details: > ... > > I can get a write throughput of 60 MB/sec on each HD by issuing the > command 'time `dd if=/dev/zero of=test.raw bs=4k count=$(( 1024 * 1024 / > 4 )); sync`' > ... > > The RAID device I'm testing on is /dev/md2. Now, by issuing the same > command 'dd if=/dev/zero of=test.raw bs=4k count=$(( 1024 * 1024 / 4 )); > sync`' on the raid device mount point, I get the following speeds: > With stripe_cache_size at default '265': 51 MB/sec > With stripe_cache_size at '8192': 73 MB/sec > I know many people consider this stupid, but can you post some hdparm -tT data ? The culprit can be the filesystem+pagecache, the md driver or the disk driver, so I think trying just hdparm will show if the disk o md are going nuts... In my case, I have a box with 2 raids, one with SCSI disks and one with IDE ones. Some results: lsscsi: [0:0:0:0]diskIBM DDYS-T18350N S96H /dev/sda [2:0:0:0]diskSEAGATE ST336807LW 0C01 /dev/sdb [2:0:1:0]diskSEAGATE ST336807LW 0C01 /dev/sdc [2:0:2:0]diskSEAGATE ST336807LW 0C01 /dev/sdd [2:0:3:0]diskSEAGATE ST336807LW 0C01 /dev/sde [3:0:0:0]diskATA ST3120022A 3.06 /dev/sdf [3:0:1:0]cd/dvd HL-DT-ST DVDRAM GSA-4040B A300 /dev/sr0 [4:0:0:0]diskATA ST3120022A 3.76 /dev/sdg /dev/md0: Version : 00.90.03 Creation Time : Mon Jun 18 13:40:57 2007 Raid Level : raid5 Array Size : 107522304 (102.54 GiB 110.10 GB) Used Dev Size : 35840768 (34.18 GiB 36.70 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Wed Jul 18 13:31:22 2007 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 256K UUID : 51ad72a7:a4d20d15:0f3ea3a1:5ccb49a0 Events : 0.2 Number Major Minor RaidDevice State 0 8 170 active sync /dev/sdb1 1 8 331 active sync /dev/sdc1 2 8 492 active sync /dev/sdd1 3 8 653 active sync /dev/sde1 This is, four scsi disks on a Adaptec U320, doing raid5: /dev/sdb: Timing cached reads: 904 MB in 2.00 seconds = 451.84 MB/sec Timing buffered disk reads: 228 MB in 3.00 seconds = 75.90 MB/sec /dev/sdc: Timing buffered disk reads: 226 MB in 3.01 seconds = 75.01 MB/sec /dev/sdd: Timing buffered disk reads: 228 MB in 3.00 seconds = 75.88 MB/sec /dev/sde: Timing buffered disk reads: 226 MB in 3.00 seconds = 75.31 MB/sec /dev/md0: Timing buffered disk reads: 562 MB in 3.01 seconds = 186.88 MB/sec Nearly 75x3 = 215 Mb/s. And this looks like a small regression, I remember to have seen 200Mb on this setup on previous kernels. Performance is like 186/215 = 86%. And /dev/md1, raid0 on 2 IDE disks: /dev/sdf: Timing buffered disk reads: 148 MB in 3.02 seconds = 48.93 MB/sec /dev/sdg: Timing buffered disk reads: 124 MB in 3.00 seconds = 41.33 MB/sec /dev/md1: Timing buffered disk reads: 204 MB in 3.01 seconds = 67.68 MB/sec Performance: 67 / 90 = 75%, more or less...not too good. Now that I read the hdparm man page, perhaps would be better to repeat the tests with hdparm --direct. -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam12 (gcc 4.2.1 20070704 (4.2.1-3mdv2008.0)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Slow Soft-RAID 5 performance
On Wed, 18 Jul 2007 10:56:11 +0100, Rui Santos [EMAIL PROTECTED] wrote: Hi, I'm getting a strange slow performance behavior on a recently installed Server. Here are the details: ... I can get a write throughput of 60 MB/sec on each HD by issuing the command 'time `dd if=/dev/zero of=test.raw bs=4k count=$(( 1024 * 1024 / 4 )); sync`' ... The RAID device I'm testing on is /dev/md2. Now, by issuing the same command 'dd if=/dev/zero of=test.raw bs=4k count=$(( 1024 * 1024 / 4 )); sync`' on the raid device mount point, I get the following speeds: With stripe_cache_size at default '265': 51 MB/sec With stripe_cache_size at '8192': 73 MB/sec I know many people consider this stupid, but can you post some hdparm -tT data ? The culprit can be the filesystem+pagecache, the md driver or the disk driver, so I think trying just hdparm will show if the disk o md are going nuts... In my case, I have a box with 2 raids, one with SCSI disks and one with IDE ones. Some results: lsscsi: [0:0:0:0]diskIBM DDYS-T18350N S96H /dev/sda [2:0:0:0]diskSEAGATE ST336807LW 0C01 /dev/sdb [2:0:1:0]diskSEAGATE ST336807LW 0C01 /dev/sdc [2:0:2:0]diskSEAGATE ST336807LW 0C01 /dev/sdd [2:0:3:0]diskSEAGATE ST336807LW 0C01 /dev/sde [3:0:0:0]diskATA ST3120022A 3.06 /dev/sdf [3:0:1:0]cd/dvd HL-DT-ST DVDRAM GSA-4040B A300 /dev/sr0 [4:0:0:0]diskATA ST3120022A 3.76 /dev/sdg /dev/md0: Version : 00.90.03 Creation Time : Mon Jun 18 13:40:57 2007 Raid Level : raid5 Array Size : 107522304 (102.54 GiB 110.10 GB) Used Dev Size : 35840768 (34.18 GiB 36.70 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Wed Jul 18 13:31:22 2007 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 256K UUID : 51ad72a7:a4d20d15:0f3ea3a1:5ccb49a0 Events : 0.2 Number Major Minor RaidDevice State 0 8 170 active sync /dev/sdb1 1 8 331 active sync /dev/sdc1 2 8 492 active sync /dev/sdd1 3 8 653 active sync /dev/sde1 This is, four scsi disks on a Adaptec U320, doing raid5: /dev/sdb: Timing cached reads: 904 MB in 2.00 seconds = 451.84 MB/sec Timing buffered disk reads: 228 MB in 3.00 seconds = 75.90 MB/sec /dev/sdc: Timing buffered disk reads: 226 MB in 3.01 seconds = 75.01 MB/sec /dev/sdd: Timing buffered disk reads: 228 MB in 3.00 seconds = 75.88 MB/sec /dev/sde: Timing buffered disk reads: 226 MB in 3.00 seconds = 75.31 MB/sec /dev/md0: Timing buffered disk reads: 562 MB in 3.01 seconds = 186.88 MB/sec Nearly 75x3 = 215 Mb/s. And this looks like a small regression, I remember to have seen 200Mb on this setup on previous kernels. Performance is like 186/215 = 86%. And /dev/md1, raid0 on 2 IDE disks: /dev/sdf: Timing buffered disk reads: 148 MB in 3.02 seconds = 48.93 MB/sec /dev/sdg: Timing buffered disk reads: 124 MB in 3.00 seconds = 41.33 MB/sec /dev/md1: Timing buffered disk reads: 204 MB in 3.01 seconds = 67.68 MB/sec Performance: 67 / 90 = 75%, more or less...not too good. Now that I read the hdparm man page, perhaps would be better to repeat the tests with hdparm --direct. -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam12 (gcc 4.2.1 20070704 (4.2.1-3mdv2008.0)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: md device files missing at boot time
On Wed, 04 Jul 2007 15:32:55 +0200, Ingo Freund <[EMAIL PROTECTED]> wrote: > Hi folks, > > one of the systems I'm working with was changed (copied) from single (scsi - > sda1) > to multiple disk (raid1) (sdb1,sdc1 --> md0). > When I try to boot from the new created md-device it stops with: > ... > loading reiserfs > "Waiting for device /dev/md0 to appear: not found -- Exiting to > /bin/sh > > A > # ls -la /dev/md* > shows nothing, so I understand why the "/" cannot be mounted, but > where are the /dev/md* files (I found them in "/lib/udev/devices")? > > The kernel is vanilla 2.6.21.5, the (I think) needed hardware and filesystem > drivers are built in modules and put into an initrd file for loading at boot > time. > > Does anyone have an idea what I might do wrong? > Stupid question, I suppose... Are you sdb1,sdc1 partitions "Linux RAID _autodetect_" ? All my raids use the md+raid modules builtin, no initrd, so I don't know if you have to force load of md on the initrd, or kernel will autoload if you use root=/dev/md0. Could you post your dmesg ? -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam10 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: md device files missing at boot time
On Wed, 04 Jul 2007 15:32:55 +0200, Ingo Freund [EMAIL PROTECTED] wrote: Hi folks, one of the systems I'm working with was changed (copied) from single (scsi - sda1) to multiple disk (raid1) (sdb1,sdc1 -- md0). When I try to boot from the new created md-device it stops with: ... loading reiserfs Waiting for device /dev/md0 to appear: not found -- Exiting to /bin/sh A # ls -la /dev/md* shows nothing, so I understand why the / cannot be mounted, but where are the /dev/md* files (I found them in /lib/udev/devices)? The kernel is vanilla 2.6.21.5, the (I think) needed hardware and filesystem drivers are built in modules and put into an initrd file for loading at boot time. Does anyone have an idea what I might do wrong? Stupid question, I suppose... Are you sdb1,sdc1 partitions Linux RAID _autodetect_ ? All my raids use the md+raid modules builtin, no initrd, so I don't know if you have to force load of md on the initrd, or kernel will autoload if you use root=/dev/md0. Could you post your dmesg ? -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam10 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problems with fb console [was Re: 2.6.12-rc4-mm2]
On Mon, 16 May 2005 02:13:02 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc4/2.6.12-rc4-mm2/ > > Hi... I have a (stupid, I suppose) problem with framebuffer console. I have builtin VESAFB in this kernel, so: werewolf:/boot# grep _FB config-2.6.21-jam09 | grep =y CONFIG_FB=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_DEFERRED_IO=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_VESA=y werewolf:/boot# grep CONSO config-2.6.21-jam09 # CONFIG_NETCONSOLE is not set CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set I put this line in grub's menu.lst: kernel /boot/vmlinuz video=vesafb:mtrr,ywrap vga=0x31A ro root=/dev/sdc1 (tried both with hex and decimal). but grub keeps telling me it can't set that video mode, and I have no /dev/fb0 device to try with fbset. I have a '29 fb' line in /proc/devices. Any ideas about why the device is missing ? udev is 113... I have followed al the info I could get (linux/Documentation/fb/, Google ;) ) and all say that what I'm doing should work. What am I doing wrong ? TIA -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam09 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problems with fb console [was Re: 2.6.12-rc4-mm2]
On Mon, 16 May 2005 02:13:02 -0700, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc4/2.6.12-rc4-mm2/ Hi... I have a (stupid, I suppose) problem with framebuffer console. I have builtin VESAFB in this kernel, so: werewolf:/boot# grep _FB config-2.6.21-jam09 | grep =y CONFIG_FB=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_DEFERRED_IO=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_VESA=y werewolf:/boot# grep CONSO config-2.6.21-jam09 # CONFIG_NETCONSOLE is not set CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set I put this line in grub's menu.lst: kernel /boot/vmlinuz video=vesafb:mtrr,ywrap vga=0x31A ro root=/dev/sdc1 (tried both with hex and decimal). but grub keeps telling me it can't set that video mode, and I have no /dev/fb0 device to try with fbset. I have a '29 fb' line in /proc/devices. Any ideas about why the device is missing ? udev is 113... I have followed al the info I could get (linux/Documentation/fb/, Google ;) ) and all say that what I'm doing should work. What am I doing wrong ? TIA -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam09 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc4-mm2
On Wed, 20 Jun 2007 09:23:07 +0200, Jiri Slaby <[EMAIL PROTECTED]> wrote: > J.A. Magallón napsal(a): > > On Tue, 19 Jun 2007 15:53:57 +0200, "J.A. Magallón" <[EMAIL PROTECTED]> > > wrote: > > > >> On Wed, 6 Jun 2007 22:03:13 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > >> > >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ > >>> > >>> - Basically a bugfixed version of 2.6.22-rc4-mm1. None of the subsystem > >>> trees were repulled, several bad patches were dropped, a few were fixed. > >>> > >> I get this warning when I plug a USB stick: > >> > > > > Oops, forgot to say that this is not plain -rc4-mm2, but with CFS scheduler > > v17. > > CC'ing Ingo for if it is related... > > > >> Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new high speed USB device > >> using ehci_hcd and address 4 > >> Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new device found, > >> idVendor=090c, idProduct=1000 > >> Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new device strings: Mfr=1, > >> Product=2, SerialNumber=3 > >> Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: Product: USBDrive > >> Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: Manufacturer: LG > >> Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: SerialNumber: AA04012700012034 > >> Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: configuration #1 chosen from > >> 1 choice > >> Jun 19 15:50:53 werewolf-wl kernel: scsi7 : SCSI emulation for USB Mass > >> Storage devices > >> Jun 19 15:50:53 werewolf-wl kernel: usb-storage: device found at 4 > >> Jun 19 15:50:53 werewolf-wl kernel: usb-storage: waiting for device to > >> settle before scanning > >> Jun 19 15:50:58 werewolf-wl kernel: WARNING: at drivers/usb/core/urb.c:293 > >> usb_submit_urb() > > Does this help? > http://lkml.org/lkml/2007/6/7/197 > > regards, Yep, thanks !!! Oops gone. -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam08 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc4-mm2
On Wed, 20 Jun 2007 09:23:07 +0200, Jiri Slaby [EMAIL PROTECTED] wrote: J.A. Magallón napsal(a): On Tue, 19 Jun 2007 15:53:57 +0200, J.A. Magallón [EMAIL PROTECTED] wrote: On Wed, 6 Jun 2007 22:03:13 -0700, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ - Basically a bugfixed version of 2.6.22-rc4-mm1. None of the subsystem trees were repulled, several bad patches were dropped, a few were fixed. I get this warning when I plug a USB stick: Oops, forgot to say that this is not plain -rc4-mm2, but with CFS scheduler v17. CC'ing Ingo for if it is related... Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new high speed USB device using ehci_hcd and address 4 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new device found, idVendor=090c, idProduct=1000 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new device strings: Mfr=1, Product=2, SerialNumber=3 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: Product: USBDrive Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: Manufacturer: LG Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: SerialNumber: AA04012700012034 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: configuration #1 chosen from 1 choice Jun 19 15:50:53 werewolf-wl kernel: scsi7 : SCSI emulation for USB Mass Storage devices Jun 19 15:50:53 werewolf-wl kernel: usb-storage: device found at 4 Jun 19 15:50:53 werewolf-wl kernel: usb-storage: waiting for device to settle before scanning Jun 19 15:50:58 werewolf-wl kernel: WARNING: at drivers/usb/core/urb.c:293 usb_submit_urb() Does this help? http://lkml.org/lkml/2007/6/7/197 regards, Yep, thanks !!! Oops gone. -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam08 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc4-mm2
On Tue, 19 Jun 2007 15:53:57 +0200, "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > On Wed, 6 Jun 2007 22:03:13 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ > > > > - Basically a bugfixed version of 2.6.22-rc4-mm1. None of the subsystem > > trees were repulled, several bad patches were dropped, a few were fixed. > > > > I get this warning when I plug a USB stick: > Oops, forgot to say that this is not plain -rc4-mm2, but with CFS scheduler v17. CC'ing Ingo for if it is related... > Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new high speed USB device using > ehci_hcd and address 4 > Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new device found, idVendor=090c, > idProduct=1000 > Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new device strings: Mfr=1, > Product=2, SerialNumber=3 > Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: Product: USBDrive > Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: Manufacturer: LG > Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: SerialNumber: AA04012700012034 > Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: configuration #1 chosen from 1 > choice > Jun 19 15:50:53 werewolf-wl kernel: scsi7 : SCSI emulation for USB Mass > Storage devices > Jun 19 15:50:53 werewolf-wl kernel: usb-storage: device found at 4 > Jun 19 15:50:53 werewolf-wl kernel: usb-storage: waiting for device to settle > before scanning > Jun 19 15:50:58 werewolf-wl kernel: WARNING: at drivers/usb/core/urb.c:293 > usb_submit_urb() > Jun 19 15:50:58 werewolf-wl kernel: [usb_submit_urb+491/513] > usb_submit_urb+0x1eb/0x201 > Jun 19 15:50:58 werewolf-wl kernel: [] usb_submit_urb+0x1eb/0x201 > Jun 19 15:50:58 werewolf-wl kernel: [usb_sg_init+580/609] > usb_sg_init+0x244/0x261 > Jun 19 15:50:58 werewolf-wl kernel: [] usb_sg_init+0x244/0x261 > Jun 19 15:50:58 werewolf-wl kernel: [usb_sg_wait+175/326] > usb_sg_wait+0xaf/0x146 > Jun 19 15:50:58 werewolf-wl kernel: [] usb_sg_wait+0xaf/0x146 > Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_bulk_transfer_sg+149/220] > usb_stor_bulk_transfer_sg+0x95/0xdc > Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_bulk_transfer_buf+71/114] > usb_stor_bulk_transfer_buf+0x47/0x72 > Jun 19 15:50:58 werewolf-wl kernel: [] > usb_stor_bulk_transfer_buf+0x47/0x72 > Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_Bulk_transport+293/617] > usb_stor_Bulk_transport+0x125/0x269 > Jun 19 15:50:58 werewolf-wl kernel: [] > usb_stor_Bulk_transport+0x125/0x269 > Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] > usb_stor_control_thread+0x0/0x1a9 > Jun 19 15:50:58 werewolf-wl kernel: [] > usb_stor_control_thread+0x0/0x1a9 > Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_invoke_transport+21/659] > usb_stor_invoke_transport+0x15/0x293 > Jun 19 15:50:58 werewolf-wl kernel: [] > usb_stor_invoke_transport+0x15/0x293 > Jun 19 15:50:58 werewolf-wl kernel: [__wake_up_locked+31/33] > __wake_up_locked+0x1f/0x21 > Jun 19 15:50:58 werewolf-wl kernel: [] __wake_up_locked+0x1f/0x21 > Jun 19 15:50:58 werewolf-wl kernel: [__down_interruptible+236/270] > __down_interruptible+0xec/0x10e > Jun 19 15:50:58 werewolf-wl kernel: [] > __down_interruptible+0xec/0x10e > Jun 19 15:50:58 werewolf-wl kernel: [default_wake_function+0/12] > default_wake_function+0x0/0xc > Jun 19 15:50:58 werewolf-wl kernel: [] > default_wake_function+0x0/0xc > Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] > usb_stor_control_thread+0x0/0x1a9 > Jun 19 15:50:58 werewolf-wl kernel: [] > usb_stor_control_thread+0x0/0x1a9 > Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] > usb_stor_control_thread+0x0/0x1a9 > Jun 19 15:50:58 werewolf-wl kernel: [] > usb_stor_control_thread+0x0/0x1a9 > Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+315/425] > usb_stor_control_thread+0x13b/0x1a9 > Jun 19 15:50:58 werewolf-wl kernel: [] > usb_stor_control_thread+0x13b/0x1a9 > Jun 19 15:50:58 werewolf-wl kernel: [kthread+0/86] kthread+0x0/0x56 > Jun 19 15:50:58 werewolf-wl kernel: [] kthread+0x0/0x56 > Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] > usb_stor_control_thread+0x0/0x1a9 > Jun 19 15:50:58 werewolf-wl kernel: [] > usb_stor_control_thread+0x0/0x1a9 > Jun 19 15:50:58 werewolf-wl kernel: [kthread+52/86] kthread+0x34/0x56 > Jun 19 15:50:58 werewolf-wl kernel: [] kthread+0x34/0x56 > Jun 19 15:50:58 werewolf-wl kernel: [kthread+0/86] kthread+0x0/0x56 > Jun 19 15:50:58 werewolf-wl kernel: [] kthread+0x0/0x56 > Jun 19 15:50:58 werewolf-wl kernel: [kernel_thread_helper+7/20] > kernel_thread_helper+0x7/0x14 >
Re: 2.6.22-rc4-mm2
On Wed, 6 Jun 2007 22:03:13 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ > > - Basically a bugfixed version of 2.6.22-rc4-mm1. None of the subsystem > trees were repulled, several bad patches were dropped, a few were fixed. > I get this warning when I plug a USB stick: Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new high speed USB device using ehci_hcd and address 4 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new device found, idVendor=090c, idProduct=1000 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new device strings: Mfr=1, Product=2, SerialNumber=3 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: Product: USBDrive Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: Manufacturer: LG Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: SerialNumber: AA04012700012034 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: configuration #1 chosen from 1 choice Jun 19 15:50:53 werewolf-wl kernel: scsi7 : SCSI emulation for USB Mass Storage devices Jun 19 15:50:53 werewolf-wl kernel: usb-storage: device found at 4 Jun 19 15:50:53 werewolf-wl kernel: usb-storage: waiting for device to settle before scanning Jun 19 15:50:58 werewolf-wl kernel: WARNING: at drivers/usb/core/urb.c:293 usb_submit_urb() Jun 19 15:50:58 werewolf-wl kernel: [usb_submit_urb+491/513] usb_submit_urb+0x1eb/0x201 Jun 19 15:50:58 werewolf-wl kernel: [] usb_submit_urb+0x1eb/0x201 Jun 19 15:50:58 werewolf-wl kernel: [usb_sg_init+580/609] usb_sg_init+0x244/0x261 Jun 19 15:50:58 werewolf-wl kernel: [] usb_sg_init+0x244/0x261 Jun 19 15:50:58 werewolf-wl kernel: [usb_sg_wait+175/326] usb_sg_wait+0xaf/0x146 Jun 19 15:50:58 werewolf-wl kernel: [] usb_sg_wait+0xaf/0x146 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_bulk_transfer_sg+149/220] usb_stor_bulk_transfer_sg+0x95/0xdc Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_bulk_transfer_buf+71/114] usb_stor_bulk_transfer_buf+0x47/0x72 Jun 19 15:50:58 werewolf-wl kernel: [] usb_stor_bulk_transfer_buf+0x47/0x72 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_Bulk_transport+293/617] usb_stor_Bulk_transport+0x125/0x269 Jun 19 15:50:58 werewolf-wl kernel: [] usb_stor_Bulk_transport+0x125/0x269 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_invoke_transport+21/659] usb_stor_invoke_transport+0x15/0x293 Jun 19 15:50:58 werewolf-wl kernel: [] usb_stor_invoke_transport+0x15/0x293 Jun 19 15:50:58 werewolf-wl kernel: [__wake_up_locked+31/33] __wake_up_locked+0x1f/0x21 Jun 19 15:50:58 werewolf-wl kernel: [] __wake_up_locked+0x1f/0x21 Jun 19 15:50:58 werewolf-wl kernel: [__down_interruptible+236/270] __down_interruptible+0xec/0x10e Jun 19 15:50:58 werewolf-wl kernel: [] __down_interruptible+0xec/0x10e Jun 19 15:50:58 werewolf-wl kernel: [default_wake_function+0/12] default_wake_function+0x0/0xc Jun 19 15:50:58 werewolf-wl kernel: [] default_wake_function+0x0/0xc Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+315/425] usb_stor_control_thread+0x13b/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [] usb_stor_control_thread+0x13b/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [kthread+0/86] kthread+0x0/0x56 Jun 19 15:50:58 werewolf-wl kernel: [] kthread+0x0/0x56 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [kthread+52/86] kthread+0x34/0x56 Jun 19 15:50:58 werewolf-wl kernel: [] kthread+0x34/0x56 Jun 19 15:50:58 werewolf-wl kernel: [kthread+0/86] kthread+0x0/0x56 Jun 19 15:50:58 werewolf-wl kernel: [] kthread+0x0/0x56 Jun 19 15:50:58 werewolf-wl kernel: [kernel_thread_helper+7/20] kernel_thread_helper+0x7/0x14 Jun 19 15:50:58 werewolf-wl kernel: [] kernel_thread_helper+0x7/0x14 Jun 19 15:50:58 werewolf-wl kernel: === -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam07 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc4-mm2
On Wed, 6 Jun 2007 22:03:13 -0700, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ - Basically a bugfixed version of 2.6.22-rc4-mm1. None of the subsystem trees were repulled, several bad patches were dropped, a few were fixed. I get this warning when I plug a USB stick: Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new high speed USB device using ehci_hcd and address 4 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new device found, idVendor=090c, idProduct=1000 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new device strings: Mfr=1, Product=2, SerialNumber=3 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: Product: USBDrive Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: Manufacturer: LG Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: SerialNumber: AA04012700012034 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: configuration #1 chosen from 1 choice Jun 19 15:50:53 werewolf-wl kernel: scsi7 : SCSI emulation for USB Mass Storage devices Jun 19 15:50:53 werewolf-wl kernel: usb-storage: device found at 4 Jun 19 15:50:53 werewolf-wl kernel: usb-storage: waiting for device to settle before scanning Jun 19 15:50:58 werewolf-wl kernel: WARNING: at drivers/usb/core/urb.c:293 usb_submit_urb() Jun 19 15:50:58 werewolf-wl kernel: [usb_submit_urb+491/513] usb_submit_urb+0x1eb/0x201 Jun 19 15:50:58 werewolf-wl kernel: [c02724be] usb_submit_urb+0x1eb/0x201 Jun 19 15:50:58 werewolf-wl kernel: [usb_sg_init+580/609] usb_sg_init+0x244/0x261 Jun 19 15:50:58 werewolf-wl kernel: [c027408b] usb_sg_init+0x244/0x261 Jun 19 15:50:58 werewolf-wl kernel: [usb_sg_wait+175/326] usb_sg_wait+0xaf/0x146 Jun 19 15:50:58 werewolf-wl kernel: [c0273c12] usb_sg_wait+0xaf/0x146 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_bulk_transfer_sg+149/220] usb_stor_bulk_transfer_sg+0x95/0xdc Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_bulk_transfer_buf+71/114] usb_stor_bulk_transfer_buf+0x47/0x72 Jun 19 15:50:58 werewolf-wl kernel: [c0285afe] usb_stor_bulk_transfer_buf+0x47/0x72 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_Bulk_transport+293/617] usb_stor_Bulk_transport+0x125/0x269 Jun 19 15:50:58 werewolf-wl kernel: [c02860a9] usb_stor_Bulk_transport+0x125/0x269 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [c0286d5f] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_invoke_transport+21/659] usb_stor_invoke_transport+0x15/0x293 Jun 19 15:50:58 werewolf-wl kernel: [c0286202] usb_stor_invoke_transport+0x15/0x293 Jun 19 15:50:58 werewolf-wl kernel: [__wake_up_locked+31/33] __wake_up_locked+0x1f/0x21 Jun 19 15:50:58 werewolf-wl kernel: [c0113a23] __wake_up_locked+0x1f/0x21 Jun 19 15:50:58 werewolf-wl kernel: [__down_interruptible+236/270] __down_interruptible+0xec/0x10e Jun 19 15:50:58 werewolf-wl kernel: [c02f682a] __down_interruptible+0xec/0x10e Jun 19 15:50:58 werewolf-wl kernel: [default_wake_function+0/12] default_wake_function+0x0/0xc Jun 19 15:50:58 werewolf-wl kernel: [c0116d65] default_wake_function+0x0/0xc Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [c0286d5f] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [c0286d5f] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+315/425] usb_stor_control_thread+0x13b/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [c0286e9a] usb_stor_control_thread+0x13b/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [kthread+0/86] kthread+0x0/0x56 Jun 19 15:50:58 werewolf-wl kernel: [c012de72] kthread+0x0/0x56 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [c0286d5f] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [kthread+52/86] kthread+0x34/0x56 Jun 19 15:50:58 werewolf-wl kernel: [c012dea6] kthread+0x34/0x56 Jun 19 15:50:58 werewolf-wl kernel: [kthread+0/86] kthread+0x0/0x56 Jun 19 15:50:58 werewolf-wl kernel: [c012de72] kthread+0x0/0x56 Jun 19 15:50:58 werewolf-wl kernel: [kernel_thread_helper+7/20] kernel_thread_helper+0x7/0x14 Jun 19 15:50:58 werewolf-wl kernel: [c01033e3] kernel_thread_helper+0x7/0x14 Jun 19 15:50:58 werewolf-wl kernel: === -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam07 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL
Re: 2.6.22-rc4-mm2
On Tue, 19 Jun 2007 15:53:57 +0200, J.A. Magallón [EMAIL PROTECTED] wrote: On Wed, 6 Jun 2007 22:03:13 -0700, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ - Basically a bugfixed version of 2.6.22-rc4-mm1. None of the subsystem trees were repulled, several bad patches were dropped, a few were fixed. I get this warning when I plug a USB stick: Oops, forgot to say that this is not plain -rc4-mm2, but with CFS scheduler v17. CC'ing Ingo for if it is related... Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new high speed USB device using ehci_hcd and address 4 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new device found, idVendor=090c, idProduct=1000 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: new device strings: Mfr=1, Product=2, SerialNumber=3 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: Product: USBDrive Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: Manufacturer: LG Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: SerialNumber: AA04012700012034 Jun 19 15:50:53 werewolf-wl kernel: usb 1-8: configuration #1 chosen from 1 choice Jun 19 15:50:53 werewolf-wl kernel: scsi7 : SCSI emulation for USB Mass Storage devices Jun 19 15:50:53 werewolf-wl kernel: usb-storage: device found at 4 Jun 19 15:50:53 werewolf-wl kernel: usb-storage: waiting for device to settle before scanning Jun 19 15:50:58 werewolf-wl kernel: WARNING: at drivers/usb/core/urb.c:293 usb_submit_urb() Jun 19 15:50:58 werewolf-wl kernel: [usb_submit_urb+491/513] usb_submit_urb+0x1eb/0x201 Jun 19 15:50:58 werewolf-wl kernel: [c02724be] usb_submit_urb+0x1eb/0x201 Jun 19 15:50:58 werewolf-wl kernel: [usb_sg_init+580/609] usb_sg_init+0x244/0x261 Jun 19 15:50:58 werewolf-wl kernel: [c027408b] usb_sg_init+0x244/0x261 Jun 19 15:50:58 werewolf-wl kernel: [usb_sg_wait+175/326] usb_sg_wait+0xaf/0x146 Jun 19 15:50:58 werewolf-wl kernel: [c0273c12] usb_sg_wait+0xaf/0x146 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_bulk_transfer_sg+149/220] usb_stor_bulk_transfer_sg+0x95/0xdc Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_bulk_transfer_buf+71/114] usb_stor_bulk_transfer_buf+0x47/0x72 Jun 19 15:50:58 werewolf-wl kernel: [c0285afe] usb_stor_bulk_transfer_buf+0x47/0x72 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_Bulk_transport+293/617] usb_stor_Bulk_transport+0x125/0x269 Jun 19 15:50:58 werewolf-wl kernel: [c02860a9] usb_stor_Bulk_transport+0x125/0x269 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [c0286d5f] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_invoke_transport+21/659] usb_stor_invoke_transport+0x15/0x293 Jun 19 15:50:58 werewolf-wl kernel: [c0286202] usb_stor_invoke_transport+0x15/0x293 Jun 19 15:50:58 werewolf-wl kernel: [__wake_up_locked+31/33] __wake_up_locked+0x1f/0x21 Jun 19 15:50:58 werewolf-wl kernel: [c0113a23] __wake_up_locked+0x1f/0x21 Jun 19 15:50:58 werewolf-wl kernel: [__down_interruptible+236/270] __down_interruptible+0xec/0x10e Jun 19 15:50:58 werewolf-wl kernel: [c02f682a] __down_interruptible+0xec/0x10e Jun 19 15:50:58 werewolf-wl kernel: [default_wake_function+0/12] default_wake_function+0x0/0xc Jun 19 15:50:58 werewolf-wl kernel: [c0116d65] default_wake_function+0x0/0xc Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [c0286d5f] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [c0286d5f] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+315/425] usb_stor_control_thread+0x13b/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [c0286e9a] usb_stor_control_thread+0x13b/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [kthread+0/86] kthread+0x0/0x56 Jun 19 15:50:58 werewolf-wl kernel: [c012de72] kthread+0x0/0x56 Jun 19 15:50:58 werewolf-wl kernel: [usb_stor_control_thread+0/425] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [c0286d5f] usb_stor_control_thread+0x0/0x1a9 Jun 19 15:50:58 werewolf-wl kernel: [kthread+52/86] kthread+0x34/0x56 Jun 19 15:50:58 werewolf-wl kernel: [c012dea6] kthread+0x34/0x56 Jun 19 15:50:58 werewolf-wl kernel: [kthread+0/86] kthread+0x0/0x56 Jun 19 15:50:58 werewolf-wl kernel: [c012de72] kthread+0x0/0x56 Jun 19 15:50:58 werewolf-wl kernel: [kernel_thread_helper+7/20] kernel_thread_helper+0x7/0x14 Jun 19 15:50:58 werewolf-wl kernel: [c01033e3] kernel_thread_helper+0x7/0x14 Jun 19 15:50:58 werewolf-wl kernel: === -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's
idle=poll burns my box [was Re: 2.6.22-rc2-mm1]
On Wed, 23 May 2007 00:42:33 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/ > Don't know if it's specific to this kernel, but as I have realized it now... I booted with idle=poll to check some issues (with nvidia driver, btw). And suddenly I noticed my box was running near 80ºC hot. I pulled out the lid, an try to see what happened. In short, idle=poll rises the temperature about 20ºC. I have an ASUS PC-DL mobo, with a couple Xeon Northwood with HypertThreading at 2.4 GHz, for a total of 4 threads. If I boot the box with idle=poll, and let it doing _nothing_ but staring at the gnome desktop, I get this temperatures: (Time,VRM,CPU0,CPU1) (wihtout the side cover, remember...) 15:46 64 56 54 15:55 70 60 56 16:02 71 62 57 If I reboot without idle=poll, the box colds quickly: 16:07 58 52 48 16:12 50 43 42 16:15 49 42 41 I I put the box to do some multithreaded render, so all four cores stay above 98% usage, the box warms again: 16:17 51 43 42 16:24 67 57 54 16:28 70 60 56 16:30 72 61 57 16:37 72 61 56 And as soon as I stop the work, it colds again: 16:41 71 60 56 16:42 64 56 52 16:43 60 54 50 16:45 55 48 46 16:46 53 46 44 Left alone for awhile, it stays at 46 39 39 (for VRM and both CPUs, as I said). Is idle=poll a quick and dirty way to burn your box in flames ? To warm your cpu doing nothing ? Summer is coming, but this... Any ideas ? -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam03 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
idle=poll burns my box [was Re: 2.6.22-rc2-mm1]
On Wed, 23 May 2007 00:42:33 -0700, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/ Don't know if it's specific to this kernel, but as I have realized it now... I booted with idle=poll to check some issues (with nvidia driver, btw). And suddenly I noticed my box was running near 80ºC hot. I pulled out the lid, an try to see what happened. In short, idle=poll rises the temperature about 20ºC. I have an ASUS PC-DL mobo, with a couple Xeon Northwood with HypertThreading at 2.4 GHz, for a total of 4 threads. If I boot the box with idle=poll, and let it doing _nothing_ but staring at the gnome desktop, I get this temperatures: (Time,VRM,CPU0,CPU1) (wihtout the side cover, remember...) 15:46 64 56 54 15:55 70 60 56 16:02 71 62 57 If I reboot without idle=poll, the box colds quickly: 16:07 58 52 48 16:12 50 43 42 16:15 49 42 41 I I put the box to do some multithreaded render, so all four cores stay above 98% usage, the box warms again: 16:17 51 43 42 16:24 67 57 54 16:28 70 60 56 16:30 72 61 57 16:37 72 61 56 And as soon as I stop the work, it colds again: 16:41 71 60 56 16:42 64 56 52 16:43 60 54 50 16:45 55 48 46 16:46 53 46 44 Left alone for awhile, it stays at 46 39 39 (for VRM and both CPUs, as I said). Is idle=poll a quick and dirty way to burn your box in flames ? To warm your cpu doing nothing ? Summer is coming, but this... Any ideas ? -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam03 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1
On Sat, 5 May 2007 01:49:55 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ > ... > - The staircase CPU scheduler was dropped > Sorry, perhaps I missed the thread in LKML, but... why ? -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.20-jam11 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1
On Sat, 5 May 2007 01:49:55 -0700, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ ... - The staircase CPU scheduler was dropped Sorry, perhaps I missed the thread in LKML, but... why ? -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.20-jam11 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: start_udev and devpts [Re: 2.6.21-rc6-mm1]
On Wed, 25 Apr 2007 23:39:54 +0200, "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > On Wed, 25 Apr 2007 22:50:39 +0200, "J.A. Magallón" <[EMAIL PROTECTED]> wrote: ... > > But I think I found the problem. > In short, in /dev/pts is mounted before /dev. I remounted it and ssh worked > fine again. > I'll dig mandrivas rc's to check this... > > Anyways, I see no plain 'mount' command in /sbin/start_udev, all are > 'mount --move' commands. So I think it supposes is already mounted and > tries to move it. > As a (in)famous last work, I think Unix98 PTYs really don't like mount --move for /dev/pts. If I mount it manually after boot, everything works fine. -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
start_udev and devpts [Re: 2.6.21-rc6-mm1]
On Wed, 25 Apr 2007 22:50:39 +0200, "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > On Tue, 24 Apr 2007 10:22:50 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Tue, 24 Apr 2007 15:43:21 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> > > wrote: > > > > > On Tue, 24 Apr 2007 04:58:01 -0700, Andrew Morton <[EMAIL PROTECTED]> > > > wrote: > > > > > > > On Tue, 24 Apr 2007 10:10:41 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]> > > > > > wrote: > > > > > > > > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/ > > > > > > > > > > > > > > > > > > - Lots of x86 updates > > > > > > > > > > > > > > > > Has somthing related with PTY's changed in this kernel ? > > > > > > > > Not as far as I know, but there were some kobject_uevent changes which > > > > might have caused udev upcalls to break. Perhaps. > > > > > > > > > I have to enable legacy PTY handling in a couple boxes to get ssh > > > > > working. > > > > > If not, I had openpty() errors and nor sshd nor virtual terminals > > > > > (aterm) were > > > > > able to get a terminal. > > > > > > > > I have CONFIG_PM_LEGACY unset in at least one of my test configs and it > > > > works OK here. > > > > > > > > > User space (udev) is the same in three boxes and one works and two > > > > > fail. > > > > > I had /dev/ptmx everywhere and /dev/pts mounted > > > > > > > > > > Any idea ? > > > > > > > > Nope. Can you please check 2.6.21-rc7-mm1, see if that fixed it? If > > > > so, > > > > it might have been the kobject_uevent thing. > > > > > > > > > > I will, thanks. > > > > > > A couple questions (as far as udev behaviour is sooo distro > > > dependent): > > > - What should I have in /dev if I don't use legacy ptys ? As I understand > > > it, only /dev/ptmx and /dev/pts/*, no /dev/tty* nor /dev/pty* ? > > > > My FC5 CONFIG_LEGACY_PTYS=n box has no /dev/ptmx, /dev/pts/*, all of > > /dev/tty0 through /dev/tty63 and no /dev/pty*. > > > > I'm not sure where all the /dev/tty*'s came from - perhaps a static udev > > rule? > > > > Uh ? > From the Kconfig help fot UNIX98_PTYS: > > Linux has traditionally used the BSD-like names /dev/ptyxx for > masters and /dev/ttyxx for slaves of pseudo terminals. This scheme > has a number of problems. The GNU C library glibc 2.1 and later, > however, supports the Unix98 naming standard: in order to acquire a > pseudo terminal, a process opens /dev/ptmx; the number of the pseudo > terminal is then made available to the process and the pseudo > terminal slave can be accessed as /dev/pts/. What was > traditionally /dev/ttyp2 will then be /dev/pts/2, for example. > > So if all userspace is Unix98-aware, you just would be done with > /dev/ptmx and /dev/pts/*. In your setup it looks like you are not able > to use Unix98 PTYs, but as udev has created tty* things work. > Or not ? > > > > - If my setup, for whatever strange reasons has /dev/tty* stored anyware > > > (/dev/.udev, links.conf...) and they get created, I supose that opening > > > /dev/tty will give a ENODEV ? > > > > well, /dev/tty is attached to your current tty and /dev/tty2 will get you > > talking to the second VT. I can't immediately thing what /dev/tty22 is > > attached to. > > > > I supposed it was something like you always opened /dev/tty but kernel+glibc > redirect you to /dev/ttyXX, that is your _real_ terminal. > I will try to check docs... > Oops, no, /dev/tty?? are for virtual consoles. But I think I found the problem. In short, in /dev/pts is mounted before /dev. I remounted it and ssh worked fine again. I'll dig mandrivas rc's to check this... Anyways, I see no plain 'mount' command in /sbin/start_udev, all are 'mount --move' commands. So I think it supposes is already mounted and tries to move it. -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc6-mm1
On Tue, 24 Apr 2007 10:22:50 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Tue, 24 Apr 2007 15:43:21 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > > > On Tue, 24 Apr 2007 04:58:01 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > On Tue, 24 Apr 2007 10:10:41 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> > > > wrote: > > > > > > > On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/ > > > > > > > > > > > > > > > - Lots of x86 updates > > > > > > > > > > > > > Has somthing related with PTY's changed in this kernel ? > > > > > > Not as far as I know, but there were some kobject_uevent changes which > > > might have caused udev upcalls to break. Perhaps. > > > > > > > I have to enable legacy PTY handling in a couple boxes to get ssh > > > > working. > > > > If not, I had openpty() errors and nor sshd nor virtual terminals > > > > (aterm) were > > > > able to get a terminal. > > > > > > I have CONFIG_PM_LEGACY unset in at least one of my test configs and it > > > works OK here. > > > > > > > User space (udev) is the same in three boxes and one works and two fail. > > > > I had /dev/ptmx everywhere and /dev/pts mounted > > > > > > > > Any idea ? > > > > > > Nope. Can you please check 2.6.21-rc7-mm1, see if that fixed it? If so, > > > it might have been the kobject_uevent thing. > > > > > > > I will, thanks. > > > > A couple questions (as far as udev behaviour is sooo distro dependent): > > - What should I have in /dev if I don't use legacy ptys ? As I understand > > it, only /dev/ptmx and /dev/pts/*, no /dev/tty* nor /dev/pty* ? > > My FC5 CONFIG_LEGACY_PTYS=n box has no /dev/ptmx, /dev/pts/*, all of > /dev/tty0 through /dev/tty63 and no /dev/pty*. > > I'm not sure where all the /dev/tty*'s came from - perhaps a static udev > rule? > Uh ? >From the Kconfig help fot UNIX98_PTYS: Linux has traditionally used the BSD-like names /dev/ptyxx for masters and /dev/ttyxx for slaves of pseudo terminals. This scheme has a number of problems. The GNU C library glibc 2.1 and later, however, supports the Unix98 naming standard: in order to acquire a pseudo terminal, a process opens /dev/ptmx; the number of the pseudo terminal is then made available to the process and the pseudo terminal slave can be accessed as /dev/pts/. What was traditionally /dev/ttyp2 will then be /dev/pts/2, for example. So if all userspace is Unix98-aware, you just would be done with /dev/ptmx and /dev/pts/*. In your setup it looks like you are not able to use Unix98 PTYs, but as udev has created tty* things work. Or not ? > > - If my setup, for whatever strange reasons has /dev/tty* stored anyware > > (/dev/.udev, links.conf...) and they get created, I supose that opening > > /dev/tty will give a ENODEV ? > > well, /dev/tty is attached to your current tty and /dev/tty2 will get you > talking to the second VT. I can't immediately thing what /dev/tty22 is > attached to. > I supposed it was something like you always opened /dev/tty but kernel+glibc redirect you to /dev/ttyXX, that is your _real_ terminal. I will try to check docs... -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc6-mm1
On Tue, 24 Apr 2007 10:22:50 -0700, Andrew Morton [EMAIL PROTECTED] wrote: On Tue, 24 Apr 2007 15:43:21 +0200 J.A. Magallón [EMAIL PROTECTED] wrote: On Tue, 24 Apr 2007 04:58:01 -0700, Andrew Morton [EMAIL PROTECTED] wrote: On Tue, 24 Apr 2007 10:10:41 +0200 J.A. Magallón [EMAIL PROTECTED] wrote: On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/ - Lots of x86 updates Has somthing related with PTY's changed in this kernel ? Not as far as I know, but there were some kobject_uevent changes which might have caused udev upcalls to break. Perhaps. I have to enable legacy PTY handling in a couple boxes to get ssh working. If not, I had openpty() errors and nor sshd nor virtual terminals (aterm) were able to get a terminal. I have CONFIG_PM_LEGACY unset in at least one of my test configs and it works OK here. User space (udev) is the same in three boxes and one works and two fail. I had /dev/ptmx everywhere and /dev/pts mounted Any idea ? Nope. Can you please check 2.6.21-rc7-mm1, see if that fixed it? If so, it might have been the kobject_uevent thing. I will, thanks. A couple questions (as far as udev behaviour is sooo distro dependent): - What should I have in /dev if I don't use legacy ptys ? As I understand it, only /dev/ptmx and /dev/pts/*, no /dev/tty* nor /dev/pty* ? My FC5 CONFIG_LEGACY_PTYS=n box has no /dev/ptmx, /dev/pts/*, all of /dev/tty0 through /dev/tty63 and no /dev/pty*. I'm not sure where all the /dev/tty*'s came from - perhaps a static udev rule? Uh ? From the Kconfig help fot UNIX98_PTYS: Linux has traditionally used the BSD-like names /dev/ptyxx for masters and /dev/ttyxx for slaves of pseudo terminals. This scheme has a number of problems. The GNU C library glibc 2.1 and later, however, supports the Unix98 naming standard: in order to acquire a pseudo terminal, a process opens /dev/ptmx; the number of the pseudo terminal is then made available to the process and the pseudo terminal slave can be accessed as /dev/pts/number. What was traditionally /dev/ttyp2 will then be /dev/pts/2, for example. So if all userspace is Unix98-aware, you just would be done with /dev/ptmx and /dev/pts/*. In your setup it looks like you are not able to use Unix98 PTYs, but as udev has created tty* things work. Or not ? - If my setup, for whatever strange reasons has /dev/tty* stored anyware (/dev/.udev, links.conf...) and they get created, I supose that opening /dev/tty will give a ENODEV ? well, /dev/tty is attached to your current tty and /dev/tty2 will get you talking to the second VT. I can't immediately thing what /dev/tty22 is attached to. I supposed it was something like you always opened /dev/tty but kernel+glibc redirect you to /dev/ttyXX, that is your _real_ terminal. I will try to check docs... -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
start_udev and devpts [Re: 2.6.21-rc6-mm1]
On Wed, 25 Apr 2007 22:50:39 +0200, J.A. Magallón [EMAIL PROTECTED] wrote: On Tue, 24 Apr 2007 10:22:50 -0700, Andrew Morton [EMAIL PROTECTED] wrote: On Tue, 24 Apr 2007 15:43:21 +0200 J.A. Magallón [EMAIL PROTECTED] wrote: On Tue, 24 Apr 2007 04:58:01 -0700, Andrew Morton [EMAIL PROTECTED] wrote: On Tue, 24 Apr 2007 10:10:41 +0200 J.A. Magallón [EMAIL PROTECTED] wrote: On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/ - Lots of x86 updates Has somthing related with PTY's changed in this kernel ? Not as far as I know, but there were some kobject_uevent changes which might have caused udev upcalls to break. Perhaps. I have to enable legacy PTY handling in a couple boxes to get ssh working. If not, I had openpty() errors and nor sshd nor virtual terminals (aterm) were able to get a terminal. I have CONFIG_PM_LEGACY unset in at least one of my test configs and it works OK here. User space (udev) is the same in three boxes and one works and two fail. I had /dev/ptmx everywhere and /dev/pts mounted Any idea ? Nope. Can you please check 2.6.21-rc7-mm1, see if that fixed it? If so, it might have been the kobject_uevent thing. I will, thanks. A couple questions (as far as udev behaviour is sooo distro dependent): - What should I have in /dev if I don't use legacy ptys ? As I understand it, only /dev/ptmx and /dev/pts/*, no /dev/tty* nor /dev/pty* ? My FC5 CONFIG_LEGACY_PTYS=n box has no /dev/ptmx, /dev/pts/*, all of /dev/tty0 through /dev/tty63 and no /dev/pty*. I'm not sure where all the /dev/tty*'s came from - perhaps a static udev rule? Uh ? From the Kconfig help fot UNIX98_PTYS: Linux has traditionally used the BSD-like names /dev/ptyxx for masters and /dev/ttyxx for slaves of pseudo terminals. This scheme has a number of problems. The GNU C library glibc 2.1 and later, however, supports the Unix98 naming standard: in order to acquire a pseudo terminal, a process opens /dev/ptmx; the number of the pseudo terminal is then made available to the process and the pseudo terminal slave can be accessed as /dev/pts/number. What was traditionally /dev/ttyp2 will then be /dev/pts/2, for example. So if all userspace is Unix98-aware, you just would be done with /dev/ptmx and /dev/pts/*. In your setup it looks like you are not able to use Unix98 PTYs, but as udev has created tty* things work. Or not ? - If my setup, for whatever strange reasons has /dev/tty* stored anyware (/dev/.udev, links.conf...) and they get created, I supose that opening /dev/tty will give a ENODEV ? well, /dev/tty is attached to your current tty and /dev/tty2 will get you talking to the second VT. I can't immediately thing what /dev/tty22 is attached to. I supposed it was something like you always opened /dev/tty but kernel+glibc redirect you to /dev/ttyXX, that is your _real_ terminal. I will try to check docs... Oops, no, /dev/tty?? are for virtual consoles. But I think I found the problem. In short, in /dev/pts is mounted before /dev. I remounted it and ssh worked fine again. I'll dig mandrivas rc's to check this... Anyways, I see no plain 'mount' command in /sbin/start_udev, all are 'mount --move' commands. So I think it supposes is already mounted and tries to move it. -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: start_udev and devpts [Re: 2.6.21-rc6-mm1]
On Wed, 25 Apr 2007 23:39:54 +0200, J.A. Magallón [EMAIL PROTECTED] wrote: On Wed, 25 Apr 2007 22:50:39 +0200, J.A. Magallón [EMAIL PROTECTED] wrote: ... But I think I found the problem. In short, in /dev/pts is mounted before /dev. I remounted it and ssh worked fine again. I'll dig mandrivas rc's to check this... Anyways, I see no plain 'mount' command in /sbin/start_udev, all are 'mount --move' commands. So I think it supposes is already mounted and tries to move it. As a (in)famous last work, I think Unix98 PTYs really don't like mount --move for /dev/pts. If I mount it manually after boot, everything works fine. -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc6-mm1
On Tue, 24 Apr 2007 04:58:01 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Tue, 24 Apr 2007 10:10:41 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > > > On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/ > > > > > > > > > - Lots of x86 updates > > > > > > > Has somthing related with PTY's changed in this kernel ? > > Not as far as I know, but there were some kobject_uevent changes which > might have caused udev upcalls to break. Perhaps. > > > I have to enable legacy PTY handling in a couple boxes to get ssh working. > > If not, I had openpty() errors and nor sshd nor virtual terminals (aterm) > > were > > able to get a terminal. > > I have CONFIG_PM_LEGACY unset in at least one of my test configs and it > works OK here. > > > User space (udev) is the same in three boxes and one works and two fail. > > I had /dev/ptmx everywhere and /dev/pts mounted > > > > Any idea ? > > Nope. Can you please check 2.6.21-rc7-mm1, see if that fixed it? If so, > it might have been the kobject_uevent thing. > I will, thanks. A couple questions (as far as udev behaviour is sooo distro dependent): - What should I have in /dev if I don't use legacy ptys ? As I understand it, only /dev/ptmx and /dev/pts/*, no /dev/tty* nor /dev/pty* ? - If my setup, for whatever strange reasons has /dev/tty* stored anyware (/dev/.udev, links.conf...) and they get created, I supose that opening /dev/tty will give a ENODEV ? TIA -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc6-mm1
On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/ > > > - Lots of x86 updates > Has somthing related with PTY's changed in this kernel ? I have to enable legacy PTY handling in a couple boxes to get ssh working. If not, I had openpty() errors and nor sshd nor virtual terminals (aterm) were able to get a terminal. User space (udev) is the same in three boxes and one works and two fail. I had /dev/ptmx everywhere and /dev/pts mounted Any idea ? TIA -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc6-mm1
On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/ - Lots of x86 updates Has somthing related with PTY's changed in this kernel ? I have to enable legacy PTY handling in a couple boxes to get ssh working. If not, I had openpty() errors and nor sshd nor virtual terminals (aterm) were able to get a terminal. User space (udev) is the same in three boxes and one works and two fail. I had /dev/ptmx everywhere and /dev/pts mounted Any idea ? TIA -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc6-mm1
On Tue, 24 Apr 2007 04:58:01 -0700, Andrew Morton [EMAIL PROTECTED] wrote: On Tue, 24 Apr 2007 10:10:41 +0200 J.A. Magallón [EMAIL PROTECTED] wrote: On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/ - Lots of x86 updates Has somthing related with PTY's changed in this kernel ? Not as far as I know, but there were some kobject_uevent changes which might have caused udev upcalls to break. Perhaps. I have to enable legacy PTY handling in a couple boxes to get ssh working. If not, I had openpty() errors and nor sshd nor virtual terminals (aterm) were able to get a terminal. I have CONFIG_PM_LEGACY unset in at least one of my test configs and it works OK here. User space (udev) is the same in three boxes and one works and two fail. I had /dev/ptmx everywhere and /dev/pts mounted Any idea ? Nope. Can you please check 2.6.21-rc7-mm1, see if that fixed it? If so, it might have been the kobject_uevent thing. I will, thanks. A couple questions (as far as udev behaviour is sooo distro dependent): - What should I have in /dev if I don't use legacy ptys ? As I understand it, only /dev/ptmx and /dev/pts/*, no /dev/tty* nor /dev/pty* ? - If my setup, for whatever strange reasons has /dev/tty* stored anyware (/dev/.udev, links.conf...) and they get created, I supose that opening /dev/tty will give a ENODEV ? TIA -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/proc/sef/fd/0 is a socket ?!
Hi all... After a big update in my systems, two of them just does not let me ssh into it. It says that stdin is not a terminal. The same hapens if I try to open any terminal emulator, like aterm. It finally let me do somathing like ssh [EMAIL PROTECTED] /bin/bash -i, to get a terminal, and I saw this: nada:/etc/rc.d# ll /proc/self/fd/ total 0 lrwx-- 1 root root 64 2007.04.21 00:13 0 -> socket:[23705] lrwx-- 1 root root 64 2007.04.21 00:13 1 -> socket:[23705] lrwx-- 1 root root 64 2007.04.21 00:13 2 -> socket:[23707] lr-x-- 1 root root 64 2007.04.21 00:13 3 -> /proc/6814/fd/ whats that ? udev really messed something ? One other box is working just fine. Any ideas ? -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/proc/sef/fd/0 is a socket ?!
Hi all... After a big update in my systems, two of them just does not let me ssh into it. It says that stdin is not a terminal. The same hapens if I try to open any terminal emulator, like aterm. It finally let me do somathing like ssh [EMAIL PROTECTED] /bin/bash -i, to get a terminal, and I saw this: nada:/etc/rc.d# ll /proc/self/fd/ total 0 lrwx-- 1 root root 64 2007.04.21 00:13 0 - socket:[23705] lrwx-- 1 root root 64 2007.04.21 00:13 1 - socket:[23705] lrwx-- 1 root root 64 2007.04.21 00:13 2 - socket:[23707] lr-x-- 1 root root 64 2007.04.21 00:13 3 - /proc/6814/fd/ whats that ? udev really messed something ? One other box is working just fine. Any ideas ? -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm4
On Tue, 03 Apr 2007 19:22:47 -0400, [EMAIL PROTECTED] wrote: > On Wed, 04 Apr 2007 00:58:26 +0200, "J.A. =?UTF-8?B?TWFnYWxsw7Nu?=" said: > > > Anyways, I have just remembered I use the (in)famous nVidia driver. > > Will try to reproduce without it. This was more like a probe to see if > > somebody else is suffering it... > > The nVidia driver will get some truly astounding indigestion if you > accidentally > upgrade your xorg userspace libraries and forget to re-install the nVidia > userspace. Is that what's biting you? > No, in my distro (mandriva), libraries and drivers from ndivia are in different places so they don't get overriden in xorg reinstall. Use is controlled with ld.so.conf and ModulePath. In fact, X works fine until the saver plays on... -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam08 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: getting processor numbers
On Tue, 3 Apr 2007 22:13:07 +0200, Ingo Oeser <[EMAIL PROTECTED]> wrote:
> Hi Ulrich,
>
> On Tuesday 03 April 2007, Ulrich Drepper wrote:
> > So, anybody else has a proposal? This is a pressing issue and cannot
> > wait until someday in the distant future NUMA topology information is
> > easily and speedily accessible.
>
> Since for now you just need a fast and dirty hack, which will be replaced
> with better interfaces, I suggest creating a directory with some files in it.
> These should just contain, what you need to handle your most pressing cases.
>
> I propose /sys/devices/system/topology_counters/ for that.
> These can contain "online_cpu", "proped_cpu", "max_cpu"
> and maybe the same for nodes. All that as a simple file with an integer
> value.
>
> Since sysfs-attribute files are pollable (if the owners notifies sysfs
> on changes), you also have the notification system you need
> (select, poll, epoll etc.).
>
> If you promise to just keep the slow code around, than one day when the shiny
> NUMA topology stuff is ready, this directory can be completely removed and
> glibc (plus all their users) keeps working. It will then even work better
> with a
> new glibc version, which supports the shiny new NUMA topology stuff.
>
> The kernel can create these counters quiete easy, since most of them are
> the hamming weight (or population count) of some bitmaps.
>
> Does this sound like a proper hacky solution? :-)
>
Just a point of view from someone who has to parse /proc/cpuinfo.
That sort of file tree thing is useful to work from the command line but its
a kick in the a** to use from a program.
This makes you just to re-parse the tree each time you have to get the info
(open, read, atoi, close...) to fill your internal variables.
I don't know if its possible, but I would like something like:
__packt_it_tight_please struct cpumap_t {
u16 ncpus;
u16 ncpus_onln;
u16 ncpus_inmyset; // for procsets
// Here possibly more info about topology, pack-core-thread structure...
// in simple arrays...
};
struct cpumap_t *cpumap = mmap("/proc/sys/hw/cpumap",sizeof(struct cpumap_t));
for (...cpumap->ncpus_inmyset ) //
As I said, I don't know if its possible. I vaguely remember some comments
against binary info in /proc...
Even it could be simplified if you realize some things:
- Usually people dont worry about if cpus are all the online ones or I'm
running in a proc set. Just want to know how many can I use.
- Don't care if they are hyper-threaded, cores os independent processors.
To adjust processing for hyper-threaded cpus, one needs to tie processes
to processors, and you need to be root for that.
Really, anything dependent on topology is not usable for normal programs,
because you need to be root to control that.
So topology is not so important.
Some (probably stupid) ideas...
--
J.A. Magallon \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.1 (Cooker) for i586
Linux 2.6.20-jam08 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP
PREEMPT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm4
On Tue, 3 Apr 2007 15:51:35 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 4 Apr 2007 00:40:05 +0200 > "J.A. Magall__n" <[EMAIL PROTECTED]> wrote: > > > On Mon, 2 Apr 2007 22:47:45 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm4/ > > > > > > - The oops in git-net.patch has been fixed, so that tree has been > > > restored. > > > It is huge. > > > > > > - Added the device-mapper development tree to the -mm lineup (Alasdair > > > Kergon). It is a quilt tree, living at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/. > > > > > > - Added davidel's signalfd stuff. > > > > > > > Something strange happens to me with this kernel. > > Gnome Screensaver hangs the box. Locked solid, no atl-sysrq-raw, > > no ssh. Nada. > > Do not know if it's itself, or something in X dpms. > > > > Somebody else ? > > > > Do you know what the particualr screensaver is trying to do? Does it do > whizzy 3d graphics, or does it just blank the screen, or... ? Just the 'Floating Feet', I love it ;) (just 2D, not linked to any libGL...). Anyways, I have just remembered I use the (in)famous nVidia driver. Will try to reproduce without it. This was more like a probe to see if somebody else is suffering it... -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam08 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm4
On Mon, 2 Apr 2007 22:47:45 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm4/ > > - The oops in git-net.patch has been fixed, so that tree has been restored. > It is huge. > > - Added the device-mapper development tree to the -mm lineup (Alasdair > Kergon). It is a quilt tree, living at > ftp://ftp.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/. > > - Added davidel's signalfd stuff. > Something strange happens to me with this kernel. Gnome Screensaver hangs the box. Locked solid, no atl-sysrq-raw, no ssh. Nada. Do not know if it's itself, or something in X dpms. Somebody else ? -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam08 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm4
On Mon, 2 Apr 2007 22:47:45 -0700, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm4/ - The oops in git-net.patch has been fixed, so that tree has been restored. It is huge. - Added the device-mapper development tree to the -mm lineup (Alasdair Kergon). It is a quilt tree, living at ftp://ftp.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/. - Added davidel's signalfd stuff. Something strange happens to me with this kernel. Gnome Screensaver hangs the box. Locked solid, no atl-sysrq-raw, no ssh. Nada. Do not know if it's itself, or something in X dpms. Somebody else ? -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam08 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm4
On Tue, 3 Apr 2007 15:51:35 -0700, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 4 Apr 2007 00:40:05 +0200 J.A. Magall__n [EMAIL PROTECTED] wrote: On Mon, 2 Apr 2007 22:47:45 -0700, Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm4/ - The oops in git-net.patch has been fixed, so that tree has been restored. It is huge. - Added the device-mapper development tree to the -mm lineup (Alasdair Kergon). It is a quilt tree, living at ftp://ftp.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/. - Added davidel's signalfd stuff. Something strange happens to me with this kernel. Gnome Screensaver hangs the box. Locked solid, no atl-sysrq-raw, no ssh. Nada. Do not know if it's itself, or something in X dpms. Somebody else ? Do you know what the particualr screensaver is trying to do? Does it do whizzy 3d graphics, or does it just blank the screen, or... ? Just the 'Floating Feet', I love it ;) (just 2D, not linked to any libGL...). Anyways, I have just remembered I use the (in)famous nVidia driver. Will try to reproduce without it. This was more like a probe to see if somebody else is suffering it... -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam08 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: getting processor numbers
On Tue, 3 Apr 2007 22:13:07 +0200, Ingo Oeser [EMAIL PROTECTED] wrote:
Hi Ulrich,
On Tuesday 03 April 2007, Ulrich Drepper wrote:
So, anybody else has a proposal? This is a pressing issue and cannot
wait until someday in the distant future NUMA topology information is
easily and speedily accessible.
Since for now you just need a fast and dirty hack, which will be replaced
with better interfaces, I suggest creating a directory with some files in it.
These should just contain, what you need to handle your most pressing cases.
I propose /sys/devices/system/topology_counters/ for that.
These can contain online_cpu, proped_cpu, max_cpu
and maybe the same for nodes. All that as a simple file with an integer
value.
Since sysfs-attribute files are pollable (if the owners notifies sysfs
on changes), you also have the notification system you need
(select, poll, epoll etc.).
If you promise to just keep the slow code around, than one day when the shiny
NUMA topology stuff is ready, this directory can be completely removed and
glibc (plus all their users) keeps working. It will then even work better
with a
new glibc version, which supports the shiny new NUMA topology stuff.
The kernel can create these counters quiete easy, since most of them are
the hamming weight (or population count) of some bitmaps.
Does this sound like a proper hacky solution? :-)
Just a point of view from someone who has to parse /proc/cpuinfo.
That sort of file tree thing is useful to work from the command line but its
a kick in the a** to use from a program.
This makes you just to re-parse the tree each time you have to get the info
(open, read, atoi, close...) to fill your internal variables.
I don't know if its possible, but I would like something like:
__packt_it_tight_please struct cpumap_t {
u16 ncpus;
u16 ncpus_onln;
u16 ncpus_inmyset; // for procsets
// Here possibly more info about topology, pack-core-thread structure...
// in simple arrays...
};
struct cpumap_t *cpumap = mmap(/proc/sys/hw/cpumap,sizeof(struct cpumap_t));
for (...cpumap-ncpus_inmyset ) //
As I said, I don't know if its possible. I vaguely remember some comments
against binary info in /proc...
Even it could be simplified if you realize some things:
- Usually people dont worry about if cpus are all the online ones or I'm
running in a proc set. Just want to know how many can I use.
- Don't care if they are hyper-threaded, cores os independent processors.
To adjust processing for hyper-threaded cpus, one needs to tie processes
to processors, and you need to be root for that.
Really, anything dependent on topology is not usable for normal programs,
because you need to be root to control that.
So topology is not so important.
Some (probably stupid) ideas...
--
J.A. Magallon jamagallon()ono!com \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.1 (Cooker) for i586
Linux 2.6.20-jam08 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP
PREEMPT
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5-mm4
On Tue, 03 Apr 2007 19:22:47 -0400, [EMAIL PROTECTED] wrote: On Wed, 04 Apr 2007 00:58:26 +0200, J.A. =?UTF-8?B?TWFnYWxsw7Nu?= said: Anyways, I have just remembered I use the (in)famous nVidia driver. Will try to reproduce without it. This was more like a probe to see if somebody else is suffering it... The nVidia driver will get some truly astounding indigestion if you accidentally upgrade your xorg userspace libraries and forget to re-install the nVidia userspace. Is that what's biting you? No, in my distro (mandriva), libraries and drivers from ndivia are in different places so they don't get overriden in xorg reinstall. Use is controlled with ld.so.conf and ModulePath. In fact, X works fine until the saver plays on... -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam08 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Inlining can be _very_bad...
On Thu, 29 Mar 2007 19:52:54 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Thu, Mar 29, 2007 at 01:18:38AM +0200, J.A. Magallón wrote: > > Hi all... > > > > I post this here as it can be of direct interest for kernel development > > (as I recall many discussions about inlining yes or no...). > > > > Testing other problems, I finally got this this issue: the same short > > and stupid loop lasted from 3 to 5 times more if it was in main() than > > if it was in an out-of-line function. The same (bad thing) happens if > > the function is inlined. > >... > > It looks like is updating the stack on each iteration...This is > > -march=opteron > > code, the -march=pentium4 is similar. Same behaviour with gcc3 and gcc4. > > > > tst.c and Makefile attached. > > > > Nice, isn't it ? Please, probe where is my fault... > > The only fault is to post this issue here instead of the gcc Bugzilla. > Sorry, my intention was just something like 'take a look at your reduction-like code, perhaps its slw', something like checksum funtions in tcp or raid that are inlined expecting to be faster and in fact they are slower... > In your example the compiler should produce code not slower than with > the out-of-line version when inlining. If it doesn't the bug in the > compiler resulting in this should be fixed. > That's what I expected, but... Going to gcc bugzilla... -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam06 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Inlining can be _very_bad...
On Thu, 29 Mar 2007 19:52:54 +0200, Adrian Bunk [EMAIL PROTECTED] wrote: On Thu, Mar 29, 2007 at 01:18:38AM +0200, J.A. Magallón wrote: Hi all... I post this here as it can be of direct interest for kernel development (as I recall many discussions about inlining yes or no...). Testing other problems, I finally got this this issue: the same short and stupid loop lasted from 3 to 5 times more if it was in main() than if it was in an out-of-line function. The same (bad thing) happens if the function is inlined. ... It looks like is updating the stack on each iteration...This is -march=opteron code, the -march=pentium4 is similar. Same behaviour with gcc3 and gcc4. tst.c and Makefile attached. Nice, isn't it ? Please, probe where is my fault... The only fault is to post this issue here instead of the gcc Bugzilla. Sorry, my intention was just something like 'take a look at your reduction-like code, perhaps its slw', something like checksum funtions in tcp or raid that are inlined expecting to be faster and in fact they are slower... In your example the compiler should produce code not slower than with the out-of-line version when inlining. If it doesn't the bug in the compiler resulting in this should be fixed. That's what I expected, but... Going to gcc bugzilla... -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam06 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Inlining can be _very_bad...
Hi all...
I post this here as it can be of direct interest for kernel development
(as I recall many discussions about inlining yes or no...).
Testing other problems, I finally got this this issue: the same short
and stupid loop lasted from 3 to 5 times more if it was in main() than
if it was in an out-of-line function. The same (bad thing) happens if
the function is inlined.
The basic code is like this:
float data[];
[inline] double one()
{
double sum;
sum = 0;
for (i=0; i tst
T0: 1145.12 ms
S0: 268435456.00
T1: 457.19 ms
S1: 268435456.00
With one() inlined:
apolo:~/e4> tst
T0: 1200.52 ms
S0: 268435456.00
T1: 1200.14 ms
S1: 268435456.00
Looking at the assembler, the non-inlined version does:
.L2:
cvtss2sd(%rdx,%rax,4), %xmm0
incq%rax
cmpq$268435456, %rax
addsd %xmm0, %xmm1
jne .L2
and the inlined
.L13:
cvtss2sd(%rdx,%rax,4), %xmm0
incq%rax
cmpq$268435456, %rax
addsd 8(%rsp), %xmm0
movsd %xmm0, 8(%rsp)
jne .L13
It looks like is updating the stack on each iteration...This is -march=opteron
code, the -march=pentium4 is similar. Same behaviour with gcc3 and gcc4.
tst.c and Makefile attached.
Nice, isn't it ? Please, probe where is my fault...
--
J.A. Magallon \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.1 (Cooker) for i586
Linux 2.6.20-jam06 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP
PREEMPT
Makefile
Description: Binary data
#include
#include
#include
#define SIZE 256*1024*1024
#define elap(t0,t1) \
((1000*t1.tv_sec+0.001*t1.tv_usec) - (1000*t0.tv_sec+0.001*t0.tv_usec))
double one();
float *data;
#ifdef INLINE
inline
#endif
double one()
{
int i;
double sum;
sum = 0;
asm("#FBGN");
for (i=0; i
Inlining can be _very_bad...
Hi all...
I post this here as it can be of direct interest for kernel development
(as I recall many discussions about inlining yes or no...).
Testing other problems, I finally got this this issue: the same short
and stupid loop lasted from 3 to 5 times more if it was in main() than
if it was in an out-of-line function. The same (bad thing) happens if
the function is inlined.
The basic code is like this:
float data[];
[inline] double one()
{
double sum;
sum = 0;
for (i=0; iSIZE; i++) sum += data[i];
return sum;
}
int main()
{
gettimeofday(tv0,0);
for (i=0; iSIZE; i++)
s0 += data[i];
gettimeofday(tv1,0);
printf(T0: %6.2f ms\n,elap(tv0,tv1));
gettimeofday(tv0,0);
s1 = one();
gettimeofday(tv1,0);
printf(T1: %6.2f ms\n,elap(tv0,tv1));
}
The times if one() is not inlined (emt64, 2.33GHz):
apolo:~/e4 tst
T0: 1145.12 ms
S0: 268435456.00
T1: 457.19 ms
S1: 268435456.00
With one() inlined:
apolo:~/e4 tst
T0: 1200.52 ms
S0: 268435456.00
T1: 1200.14 ms
S1: 268435456.00
Looking at the assembler, the non-inlined version does:
.L2:
cvtss2sd(%rdx,%rax,4), %xmm0
incq%rax
cmpq$268435456, %rax
addsd %xmm0, %xmm1
jne .L2
and the inlined
.L13:
cvtss2sd(%rdx,%rax,4), %xmm0
incq%rax
cmpq$268435456, %rax
addsd 8(%rsp), %xmm0
movsd %xmm0, 8(%rsp)
jne .L13
It looks like is updating the stack on each iteration...This is -march=opteron
code, the -march=pentium4 is similar. Same behaviour with gcc3 and gcc4.
tst.c and Makefile attached.
Nice, isn't it ? Please, probe where is my fault...
--
J.A. Magallon jamagallon()ono!com \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.1 (Cooker) for i586
Linux 2.6.20-jam06 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP
PREEMPT
Makefile
Description: Binary data
#include stdio.h
#include stdlib.h
#include sys/time.h
#define SIZE 256*1024*1024
#define elap(t0,t1) \
((1000*t1.tv_sec+0.001*t1.tv_usec) - (1000*t0.tv_sec+0.001*t0.tv_usec))
double one();
float *data;
#ifdef INLINE
inline
#endif
double one()
{
int i;
double sum;
sum = 0;
asm(#FBGN);
for (i=0; iSIZE; i++)
sum += data[i];
asm(#FEND);
return sum;
}
int main(int argc,char** argv)
{
struct timeval tv0,tv1;
double s0,s1;
inti;
data = malloc(SIZE*sizeof(float));
for (i=0; iSIZE; i++)
data[i] = 1;
gettimeofday(tv0,0);
s0 = 0;
asm(#MBGN);
for (i=0; iSIZE; i++)
s0 += data[i];
asm(#MEND);
gettimeofday(tv1,0);
printf(T0: %6.2f ms\n,elap(tv0,tv1));
printf(S0: %0.2lf\n,s0);
gettimeofday(tv0,0);
s1 = one();
gettimeofday(tv1,0);
printf(T1: %6.2f ms\n,elap(tv0,tv1));
printf(S1: %0.2lf\n,s1);
free(data);
return 0;
}
Re: 2.6.21-rc4-mm1
On Fri, 23 Mar 2007 00:27:09 +0100, "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ > > > > Is anybody having problems with optical drives and this kernel ? > I can't get my dvdrw to spit any events to udevmonitor. If I mount it > manually everything works fine. > > Perhaps the problem is in hal/g-v-m or anything else, but I suppose that > udevmonitor receives events directly from kernel, isn't it ? > Finally, this was a userspace problem (hal): http://lists.freedesktop.org/archives/hal/2007-March/007545.html What I don't understand is this: I supposed that udev (and so udevmonitor) is independent of hal, more or less hal monitors udev events and does things, like looking the disc label and so on. But I do not get any events in udevmonitor if I'm not logged in gnome. How's this ? TIA -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong IDE cable detection in libata [Re: 2.6.21-rc4-mm1]
On Mon, 26 Mar 2007 20:01:52 +0900, Tejun Heo <[EMAIL PROTECTED]> wrote: > J.A. Magallón wrote: > > Libata seems to misdetect my cable. > > I have double-checked and the cable is 80 pin... > > Does the following patch fix your problem? > > http://article.gmane.org/gmane.linux.ide/17444 > > (You can get the raw message by appending /raw to the URL). > Yes it works !! Disk is back at nice speed of 50 Mb/s. dmesg: ata_piix :00:1f.1: version 2.10ac1 ACPI: PCI Interrupt :00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18 PCI: Setting latency timer of device :00:1f.1 to 64 ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 scsi0 : ata_piix ata1.00: ATAPI, max UDMA/33 ata1.01: ATAPI, max MWDMA0, CDB intr ata1.00: configured for UDMA/33 ata1.01: configured for PIO3 scsi1 : ata_piix ata2.00: ATA-6: ST3120022A, 3.06, max UDMA/100 ata2.00: 234441648 sectors, multi 16: LBA48 ata2.01: ATAPI, max UDMA/33 ata2.00: configured for UDMA/100<= ata2.01: configured for UDMA/33 <= Thanks !! -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Fri, 23 Mar 2007 00:27:09 +0100, J.A. Magallón [EMAIL PROTECTED] wrote: On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton [EMAIL PROTECTED] wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ Is anybody having problems with optical drives and this kernel ? I can't get my dvdrw to spit any events to udevmonitor. If I mount it manually everything works fine. Perhaps the problem is in hal/g-v-m or anything else, but I suppose that udevmonitor receives events directly from kernel, isn't it ? Finally, this was a userspace problem (hal): http://lists.freedesktop.org/archives/hal/2007-March/007545.html What I don't understand is this: I supposed that udev (and so udevmonitor) is independent of hal, more or less hal monitors udev events and does things, like looking the disc label and so on. But I do not get any events in udevmonitor if I'm not logged in gnome. How's this ? TIA -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong IDE cable detection in libata [Re: 2.6.21-rc4-mm1]
On Mon, 26 Mar 2007 20:01:52 +0900, Tejun Heo [EMAIL PROTECTED] wrote: J.A. Magallón wrote: Libata seems to misdetect my cable. I have double-checked and the cable is 80 pin... Does the following patch fix your problem? http://article.gmane.org/gmane.linux.ide/17444 (You can get the raw message by appending /raw to the URL). Yes it works !! Disk is back at nice speed of 50 Mb/s. dmesg: ata_piix :00:1f.1: version 2.10ac1 ACPI: PCI Interrupt :00:1f.1[A] - GSI 18 (level, low) - IRQ 18 PCI: Setting latency timer of device :00:1f.1 to 64 ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 scsi0 : ata_piix ata1.00: ATAPI, max UDMA/33 ata1.01: ATAPI, max MWDMA0, CDB intr ata1.00: configured for UDMA/33 ata1.01: configured for PIO3 scsi1 : ata_piix ata2.00: ATA-6: ST3120022A, 3.06, max UDMA/100 ata2.00: 234441648 sectors, multi 16: LBA48 ata2.01: ATAPI, max UDMA/33 ata2.00: configured for UDMA/100= ata2.01: configured for UDMA/33 = Thanks !! -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Wrong IDE cable detection in libata [Re: 2.6.21-rc4-mm1]
On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > Libata seems to misdetect my cable. I have double-checked and the cable is 80 pin... ata1 is PATA ICH5 bus 1 with DVD-RW + ZIP and 40 pin cable ata2 is PATA ICH5 bus 2 with extra HD + DVD and 80 pin cable ata3 is real SATA ICH5 with boot HD (mm, I chaged bios settings to get the box booting from the SATA disk) werewolf:~# lsscsi [0:0:0:0]cd/dvd HL-DT-ST DVDRAM GSA-H10N JL12 /dev/.tmp-11-0 [0:0:1:0]diskIOMEGA ZIP 250 51.G /dev/sda [1:0:0:0]diskATA ST3120022A 3.06 /dev/sdb [1:0:1:0]cd/dvd TOSHIBA DVD-ROM SD-M1712 1004 /dev/sr1 [2:0:0:0]diskATA ST3200822AS 3.01 /dev/sdc ata_piix :00:1f.1: version 2.10ac1 ACPI: PCI Interrupt :00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18 PCI: Setting latency timer of device :00:1f.1 to 64 ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 scsi0 : ata_piix ata1.00: ATAPI, max UDMA/33 ata1.01: ATAPI, max MWDMA0, CDB intr ata1.00: configured for UDMA/33 ata1.01: configured for PIO3 scsi1 : ata_piix ata2.00: ATA-6: ST3120022A, 3.06, max UDMA/100 ata2.00: 234441648 sectors, multi 16: LBA48 ata2.01: ATAPI, max UDMA/33 ata2.00: limited to UDMA/33 due to 40-wire cable<=== ata2.00: configured for UDMA/33 ata2.01: configured for UDMA/33 scsi 0:0:0:0: CD-ROMHL-DT-ST DVDRAM GSA-H10N JL12 PQ: 0 ANSI: 5 sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 0:0:0:0: Attached scsi CD-ROM sr0 scsi 0:0:1:0: Direct-Access IOMEGA ZIP 250 51.G PQ: 0 ANSI: 5 sd 0:0:1:0: [sda] Attached SCSI removable disk scsi 1:0:0:0: Direct-Access ATA ST3120022A 3.06 PQ: 0 ANSI: 5 sd 1:0:0:0: [sdb] 234441648 512-byte hardware sectors (120034 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 1:0:0:0: [sdb] 234441648 512-byte hardware sectors (120034 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sd 1:0:0:0: [sdb] Attached SCSI disk scsi 1:0:1:0: CD-ROMTOSHIBA DVD-ROM SD-M1712 1004 PQ: 0 ANSI: 5 sr1: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray sr 1:0:1:0: Attached scsi CD-ROM sr1 Any ideas ? -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Wrong IDE cable detection in libata [Re: 2.6.21-rc4-mm1]
On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton [EMAIL PROTECTED] wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Libata seems to misdetect my cable. I have double-checked and the cable is 80 pin... ata1 is PATA ICH5 bus 1 with DVD-RW + ZIP and 40 pin cable ata2 is PATA ICH5 bus 2 with extra HD + DVD and 80 pin cable ata3 is real SATA ICH5 with boot HD (mm, I chaged bios settings to get the box booting from the SATA disk) werewolf:~# lsscsi [0:0:0:0]cd/dvd HL-DT-ST DVDRAM GSA-H10N JL12 /dev/.tmp-11-0 [0:0:1:0]diskIOMEGA ZIP 250 51.G /dev/sda [1:0:0:0]diskATA ST3120022A 3.06 /dev/sdb [1:0:1:0]cd/dvd TOSHIBA DVD-ROM SD-M1712 1004 /dev/sr1 [2:0:0:0]diskATA ST3200822AS 3.01 /dev/sdc ata_piix :00:1f.1: version 2.10ac1 ACPI: PCI Interrupt :00:1f.1[A] - GSI 18 (level, low) - IRQ 18 PCI: Setting latency timer of device :00:1f.1 to 64 ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 scsi0 : ata_piix ata1.00: ATAPI, max UDMA/33 ata1.01: ATAPI, max MWDMA0, CDB intr ata1.00: configured for UDMA/33 ata1.01: configured for PIO3 scsi1 : ata_piix ata2.00: ATA-6: ST3120022A, 3.06, max UDMA/100 ata2.00: 234441648 sectors, multi 16: LBA48 ata2.01: ATAPI, max UDMA/33 ata2.00: limited to UDMA/33 due to 40-wire cable=== ata2.00: configured for UDMA/33 ata2.01: configured for UDMA/33 scsi 0:0:0:0: CD-ROMHL-DT-ST DVDRAM GSA-H10N JL12 PQ: 0 ANSI: 5 sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 0:0:0:0: Attached scsi CD-ROM sr0 scsi 0:0:1:0: Direct-Access IOMEGA ZIP 250 51.G PQ: 0 ANSI: 5 sd 0:0:1:0: [sda] Attached SCSI removable disk scsi 1:0:0:0: Direct-Access ATA ST3120022A 3.06 PQ: 0 ANSI: 5 sd 1:0:0:0: [sdb] 234441648 512-byte hardware sectors (120034 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 1:0:0:0: [sdb] 234441648 512-byte hardware sectors (120034 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sd 1:0:0:0: [sdb] Attached SCSI disk scsi 1:0:1:0: CD-ROMTOSHIBA DVD-ROM SD-M1712 1004 PQ: 0 ANSI: 5 sr1: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray sr 1:0:1:0: Attached scsi CD-ROM sr1 Any ideas ? -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ > Is anybody having problems with optical drives and this kernel ? I can't get my dvdrw to spit any events to udevmonitor. If I mount it manually everything works fine. Perhaps the problem is in hal/g-v-m or anything else, but I suppose that udevmonitor receives events directly from kernel, isn't it ? TIA -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton [EMAIL PROTECTED] wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ Is anybody having problems with optical drives and this kernel ? I can't get my dvdrw to spit any events to udevmonitor. If I mount it manually everything works fine. Perhaps the problem is in hal/g-v-m or anything else, but I suppose that udevmonitor receives events directly from kernel, isn't it ? TIA -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4: extremely high power consumption
On Wed, 21 Mar 2007 23:29:38 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > Today I heard fans running a bit too much. I checked with top, and got > no obvious power hog. And now acpi battery says: > > [EMAIL PROTECTED]:/data/l/zaurus/oz.spitz.3541# cat > /proc/acpi/battery/BAT0/state > present: yes > capacity state: ok > charging state: discharging > present rate:35248 mW > remaining capacity: 1850 mWh > present voltage: 14259 mV > > ...35W! This machine normally eats 14W. > > Now it got better, I still see nothing at top... 22W. That's still 8W > more than it should be. What is going on? > Pavel Periodical disk writes that eat your battery ? No display dimming ? No cpu speed reduction ? Just ideas... -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4: extremely high power consumption
On Wed, 21 Mar 2007 23:29:38 +0100, Pavel Machek [EMAIL PROTECTED] wrote: Hi! Today I heard fans running a bit too much. I checked with top, and got no obvious power hog. And now acpi battery says: [EMAIL PROTECTED]:/data/l/zaurus/oz.spitz.3541# cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: discharging present rate:35248 mW remaining capacity: 1850 mWh present voltage: 14259 mV ...35W! This machine normally eats 14W. Now it got better, I still see nothing at top... 22W. That's still 8W more than it should be. What is going on? Pavel Periodical disk writes that eat your battery ? No display dimming ? No cpu speed reduction ? Just ideas... -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Tue, 20 Mar 2007 17:36:57 +0100, "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ > > > > (oops, I forgot LKML) > > I have no udev events for my dvd-rw... > When I insert a disc in the dvd reader: > > werewolf:~# udevmonitor > udevmonitor prints the received event from the kernel [UEVENT] > and the event which udev sends out after rule processing [UDEV] > > UEVENT[1174385162.607021] mount/block/sr1 (block) > UDEV [1174385162.610056] mount/block/sr1 (block) > > If I insert it in the dvd-rw drive, nothing happens. > I realized that my scsi devices were like this: werewolf:~# lsscsi [0:0:0:0]cd/dvd HL-DT-ST DVDRAM GSA-H10N JL10 /dev/.tmp-11-0 [0:0:1:0]diskIOMEGA ZIP 250 51.G /dev/sda [1:0:0:0]diskATA ST3120022A 3.06 /dev/sdb [1:0:1:0]cd/dvd TOSHIBA DVD-ROM SD-M1712 1004 /dev/.tmp-11-1 [2:0:0:0]diskATA ST3200822AS 3.01 /dev/sdc [7:0:0:0]diskLG USBDrive 1100 /dev/sdd After a service udev force-reload: werewolf:~# lsscsi [0:0:0:0]cd/dvd HL-DT-ST DVDRAM GSA-H10N JL10 /dev/sr0 [0:0:1:0]diskIOMEGA ZIP 250 51.G /dev/sda [1:0:0:0]diskATA ST3120022A 3.06 /dev/sdb [1:0:1:0]cd/dvd TOSHIBA DVD-ROM SD-M1712 1004 /dev/sr1 [2:0:0:0]diskATA ST3200822AS 3.01 /dev/sdc [7:0:0:0]diskLG USBDrive 1100 /dev/sdd If I insert a disc in /dev/sr1 and eject it: werewolf:~# lsscsi [0:0:0:0]cd/dvd HL-DT-ST DVDRAM GSA-H10N JL10 /dev/sr0 [0:0:1:0]diskIOMEGA ZIP 250 51.G /dev/sda [1:0:0:0]diskATA ST3120022A 3.06 /dev/sdb [1:0:1:0]cd/dvd TOSHIBA DVD-ROM SD-M1712 1004 /dev/.tmp-11-1 [2:0:0:0]diskATA ST3200822AS 3.01 /dev/sdc [7:0:0:0]diskLG USBDrive 1100 /dev/sdd If I reload the disc in the TOSHIBA, it is automounted but the strange device is still there. Trying with /dev/sr0 still gives no events. What is happening here ? It is the kernel or is udev setup ? TIA -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > After applying hot-fixes, I get this: MODPOST vmlinux WARNING: init/built-in.o - Section mismatch: reference to .init.text: from .text between 'rest_init' (at offset 0xfa) and 'try_name' WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text:cpu_set_gdt from .text between 'initialize_secondary' (at offset 0xbce3) and 'mp_find_ioapic' WARNING: mm/built-in.o - Section mismatch: reference to .init.data:initkmem_list3 from .text between 'set_up_list3s' (at offset 0x1b384) and 's_start' If you need anything, just ask (.config or the like) -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ > (oops, I forgot LKML) I have no udev events for my dvd-rw... When I insert a disc in the dvd reader: werewolf:~# udevmonitor udevmonitor prints the received event from the kernel [UEVENT] and the event which udev sends out after rule processing [UDEV] UEVENT[1174385162.607021] mount/block/sr1 (block) UDEV [1174385162.610056] mount/block/sr1 (block) If I insert it in the dvd-rw drive, nothing happens. extracts from dmesg: (I have just noticed the message for the 40 wire cable, I will check) (btw, why the h**l ata busses start nubering in 1 and scsi ones in 0 :, it ata also begun in 0 life will be much easier...) ata_piix :00:1f.1: version 2.10ac1 ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 scsi0 : ata_piix ata1.00: ATAPI, max UDMA/33 ata1.01: ATAPI, max MWDMA0, CDB intr ata1.00: configured for UDMA/33 ata1.01: configured for PIO3 scsi1 : ata_piix ata2.00: ATA-6: ST3120022A, 3.06, max UDMA/100 ata2.00: 234441648 sectors, multi 16: LBA48 ata2.01: ATAPI, max UDMA/33 ata2.00: limited to UDMA/33 due to 40-wire cable ata2.00: configured for UDMA/33 ata2.01: configured for UDMA/33 scsi 0:0:0:0: CD-ROMHL-DT-ST DVDRAM GSA-H10N JL10 PQ: 0 ANSI: 5 sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 0:0:0:0: Attached scsi CD-ROM sr0 scsi 0:0:1:0: Direct-Access IOMEGA ZIP 250 51.G PQ: 0 ANSI: 5 sd 0:0:1:0: [sda] Attached SCSI removable disk scsi 1:0:0:0: Direct-Access ATA ST3120022A 3.06 PQ: 0 ANSI: 5 sd 1:0:0:0: [sdb] 234441648 512-byte hardware sectors (120034 MB) sd 1:0:0:0: [sdb] Attached SCSI disk scsi 1:0:1:0: CD-ROMTOSHIBA DVD-ROM SD-M1712 1004 PQ: 0 ANSI: 5 sr1: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray sr 1:0:1:0: Attached scsi CD-ROM sr1 ata_piix :00:1f.2: MAP [ P0 -- P1 -- ] ata3: SATA max UDMA/133 cmd 0x0001c000 ctl 0x0001c402 bmdma 0x0001d000 irq 18 ata4: SATA max UDMA/133 cmd 0x0001c800 ctl 0x0001cc02 bmdma 0x0001d008 irq 18 scsi2 : ata_piix ata3.00: ATA-6: ST3200822AS, 3.01, max UDMA/133 ata3.00: 390721968 sectors, multi 16: LBA48 ata3.00: configured for UDMA/133 scsi3 : ata_piix ATA: abnormal status 0x7F on port 0x0001c807 scsi 2:0:0:0: Direct-Access ATA ST3200822AS 3.01 PQ: 0 ANSI: 5 sd 2:0:0:0: [sdc] 390721968 512-byte hardware sectors (200050 MB) sd 2:0:0:0: [sdc] Write Protect is off sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:0:0: [sdc] 390721968 512-byte hardware sectors (200050 MB) sd 2:0:0:0: [sdc] Write Protect is off sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sdc2 sdc3 sd 2:0:0:0: [sdc] Attached SCSI disk -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc4-mm1
On Mon, 19 Mar 2007 20:56:23 -0800, Andrew Morton [EMAIL PROTECTED] wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/ (oops, I forgot LKML) I have no udev events for my dvd-rw... When I insert a disc in the dvd reader: werewolf:~# udevmonitor udevmonitor prints the received event from the kernel [UEVENT] and the event which udev sends out after rule processing [UDEV] UEVENT[1174385162.607021] mount/block/sr1 (block) UDEV [1174385162.610056] mount/block/sr1 (block) If I insert it in the dvd-rw drive, nothing happens. extracts from dmesg: (I have just noticed the message for the 40 wire cable, I will check) (btw, why the h**l ata busses start nubering in 1 and scsi ones in 0 :, it ata also begun in 0 life will be much easier...) ata_piix :00:1f.1: version 2.10ac1 ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 scsi0 : ata_piix ata1.00: ATAPI, max UDMA/33 ata1.01: ATAPI, max MWDMA0, CDB intr ata1.00: configured for UDMA/33 ata1.01: configured for PIO3 scsi1 : ata_piix ata2.00: ATA-6: ST3120022A, 3.06, max UDMA/100 ata2.00: 234441648 sectors, multi 16: LBA48 ata2.01: ATAPI, max UDMA/33 ata2.00: limited to UDMA/33 due to 40-wire cable ata2.00: configured for UDMA/33 ata2.01: configured for UDMA/33 scsi 0:0:0:0: CD-ROMHL-DT-ST DVDRAM GSA-H10N JL10 PQ: 0 ANSI: 5 sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 0:0:0:0: Attached scsi CD-ROM sr0 scsi 0:0:1:0: Direct-Access IOMEGA ZIP 250 51.G PQ: 0 ANSI: 5 sd 0:0:1:0: [sda] Attached SCSI removable disk scsi 1:0:0:0: Direct-Access ATA ST3120022A 3.06 PQ: 0 ANSI: 5 sd 1:0:0:0: [sdb] 234441648 512-byte hardware sectors (120034 MB) sd 1:0:0:0: [sdb] Attached SCSI disk scsi 1:0:1:0: CD-ROMTOSHIBA DVD-ROM SD-M1712 1004 PQ: 0 ANSI: 5 sr1: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray sr 1:0:1:0: Attached scsi CD-ROM sr1 ata_piix :00:1f.2: MAP [ P0 -- P1 -- ] ata3: SATA max UDMA/133 cmd 0x0001c000 ctl 0x0001c402 bmdma 0x0001d000 irq 18 ata4: SATA max UDMA/133 cmd 0x0001c800 ctl 0x0001cc02 bmdma 0x0001d008 irq 18 scsi2 : ata_piix ata3.00: ATA-6: ST3200822AS, 3.01, max UDMA/133 ata3.00: 390721968 sectors, multi 16: LBA48 ata3.00: configured for UDMA/133 scsi3 : ata_piix ATA: abnormal status 0x7F on port 0x0001c807 scsi 2:0:0:0: Direct-Access ATA ST3200822AS 3.01 PQ: 0 ANSI: 5 sd 2:0:0:0: [sdc] 390721968 512-byte hardware sectors (200050 MB) sd 2:0:0:0: [sdc] Write Protect is off sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:0:0: [sdc] 390721968 512-byte hardware sectors (200050 MB) sd 2:0:0:0: [sdc] Write Protect is off sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sdc2 sdc3 sd 2:0:0:0: [sdc] Attached SCSI disk -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.1 (Cooker) for i586 Linux 2.6.20-jam05 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP PREEMPT - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
