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,&data,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/
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&m=120355254713965&w=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: 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: 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&m=119975354031937&w=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: 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: 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: 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: 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/
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/
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 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 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 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 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 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: 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 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: 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/
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/
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: 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 inf
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 Mip
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
Problem with POSIX threads in latest kernel...
Hi...
I run the (almost) latest -mm kernel (2.6.20-rc3-mm1), and see some strange
behaviour
with POSIX threads (glibc-2.4).
I have downgraded my test to a simple textboox example for a SMP-safe spool
queue, it's just a circular queue with a mutex and a condition variable for in
and out. I have seen the same structure in several places.
Well, it just sometimes gets blocked. GDB says its stuck in pthread_wait().
I could swear it worked on previous kernels. It works as is on IRIX.
I will try to build an older kernel to test.
I takes a second to block it with something like while :; tst; done.
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.19-jam04 (gcc 4.1.2 20061110 (prerelease)
(4.1.2-0.20061110.2mdv2007.1)) #0 SMP PREEMPT
#include
#include
#include
#include
#define SIZE 16
intjobs[SIZE];
intin;
intslots;
pthread_mutex_t slots_mutex;
pthread_cond_t slots_cond;
intout;
intitems;
pthread_mutex_t items_mutex;
pthread_cond_t items_cond;
void put(int job);
void get(int* job);
void* prod(void* data);
void* cons(void* data);
int main(int argc,char** argv)
{
pthread_t prodid,consid;
in = 0;
slots = SIZE;
pthread_mutex_init(&slots_mutex,0);
pthread_cond_init(&slots_cond,0);
out = 0;
items = 0;
pthread_mutex_init(&items_mutex,0);
pthread_cond_init(&items_cond,0);
pthread_setconcurrency(3);
pthread_create(&prodid,0,prod,0);
pthread_create(&consid,0,cons,0);
pthread_join(prodid,0);
pthread_join(consid,0);
return 0;
}
void* prod(void* data)
{
int i;
for (i=0; i<1000; i++)
{
if (!(i%100))
printf("put %d\n",i);
put(i);
}
put(-1);
puts("prod done");
return 0;
}
void* cons(void* data)
{
int i;
do
{
get(&i);
if (!(i%100))
printf("got %d\n",i);
}
while (i>=0);
puts("cons done");
return 0;
}
void put(int job)
{
pthread_mutex_lock(&slots_mutex);
while (slots<=0)
pthread_cond_wait(&slots_cond,&slots_mutex);
jobs[in] = job;
in++;
in %= SIZE;
slots--;
items++;
pthread_mutex_unlock(&slots_mutex);
pthread_mutex_lock(&items_mutex);
pthread_cond_signal(&items_cond);
pthread_mutex_unlock(&items_mutex);
}
void get(int* job)
{
pthread_mutex_lock(&items_mutex);
while (items<=0)
pthread_cond_wait(&items_cond,&items_mutex);
*job = jobs[out];
out++;
out %= SIZE;
items--;
slots++;
pthread_mutex_unlock(&items_mutex);
pthread_mutex_lock(&slots_mutex);
pthread_cond_signal(&slots_cond);
pthread_mutex_unlock(&slots_mutex);
}
Re: Threading...
On Fri, 19 Jan 2007 19:55:41 +0100, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > On Fri, 2007-01-19 at 10:43 -0800, Brian McGrew wrote: > > I have a very interesting question about something that we're seeing > > happening with threading between Fedora Core 3 and Fedora Core 5. Running > > on Dell PowerEdge 1800 Hardware with a Xeon processor with hyper-threading > > turned on. Both systems are using a 2.6.16.16 kernel (MVP al la special). > > > > We have a multithreaded application that starts two worker threads. On > > Fedora Core 3 both of these we use getpid() to get the PID of the thread and > > then use set_afinity to assign each thread to it's own CPU. Both threads > > run almost symmetrically even on their given CPU watching the system > > monitor. > > this is odd; even in FC3 getpid() is supposed to return the process ID > not the thread ID > > > What am I missing? What do I need to do in FC5 or the kernel or the > > threading library to get my threads to run in symmetric parallel again??? > One thing to try. In linux, pthread_setconcurrency never did nothing (it _really_ did in IRIX...). Can you try that ? Perhaps FC5 has implemented some kind of scheduling policy like that on irix (everything stays on the same CPU until it starts to suck cycles, unless you use setconcurrency). -- 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.19-jam04 (gcc 4.1.2 20061110 (prerelease) (4.1.2-0.20061110.2mdv2007.1)) #0 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 with POSIX threads in latest kernel...
On Mon, 22 Jan 2007 11:56:30 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Tue, 16 Jan 2007 02:47:10 +0100 "J.A. Magallón" <[EMAIL PROTECTED]> > > wrote: > > Hi... > > > > I run the (almost) latest -mm kernel (2.6.20-rc3-mm1), and see some strange > > behaviour > > with POSIX threads (glibc-2.4). > > I have downgraded my test to a simple textboox example for a SMP-safe spool > > queue, it's just a circular queue with a mutex and a condition variable for > > in > > and out. I have seen the same structure in several places. > > > > Well, it just sometimes gets blocked. GDB says its stuck in pthread_wait(). > > I could swear it worked on previous kernels. It works as is on IRIX. > > I will try to build an older kernel to test. > > I takes a second to block it with something like while :; tst; done. > > > > Any ideas ? > > Do I need to worry about this still? Oops, no, sorry. It was buggy code that previously seemed to work. Buggy code: pthread_mutex_lock(&slots_mutex); while (slots<=0) pthread_cond_wait(&slots_cond,&slots_mutex); slots--; items++; pthread_mutex_unlock(&slots_mutex); pthread_mutex_lock(&items_mutex); pthread_cond_signal(&items_cond); pthread_mutex_unlock(&items_mutex); (buggy because it acceses items without locking. The same in the other endpoint of the queue). Correct code: pthread_mutex_lock(&slots_mutex); while (slots<=0) pthread_cond_wait(&slots_cond,&slots_mutex); slots--; pthread_mutex_unlock(&slots_mutex); pthread_mutex_lock(&items_mutex); items++; pthread_cond_signal(&items_cond); pthread_mutex_unlock(&items_mutex); So don't worry. I was so busy I forgot to post the solution. -- 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.19-jam04 (gcc 4.1.2 20061110 (prerelease) (4.1.2-0.20061110.2mdv2007.1)) #0 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: SMP performance degradation with sysbench
On Mon, 26 Feb 2007 23:31:29 -0500, Rik van Riel <[EMAIL PROTECTED]> wrote: > Hiro Yoshioka wrote: > > Hi, > > > > From: Rik van Riel <[EMAIL PROTECTED]> > >> Hiro Yoshioka wrote: > >>> Howdy, > >>> > >>> MySQL 5.0.26 had some scalability issues and it solved since 5.0.32 > >>> http://ossipedia.ipa.go.jp/capacity/EV0612260303/ > >>> (written in Japanese but you may read the graph. We compared > >>> 5.0.24 vs 5.0.32) > > snip > >>> MySQL tries to get a mutex but it spends about 16.8% of CPU on 8 core > >>> machine. > >>> > >>> I think there are a lot of room to be inproved in MySQL implementation. > >> That's one aspect. > >> > >> The other aspect of the problem is that when the number of > >> threads exceeds the number of CPU cores, Linux no longer > >> manages to keep the CPUs busy and we get a lot of idle time. > >> > >> On the other hand, with the number of threads being equal to > >> the number of CPU cores, we are 100% CPU bound... > > > > I have a question. If so, what is the difference of kernel's > > view between SMP and CPU cores? > > None. Each schedulable entity (whether a fully fledged > CPU core or an SMT/HT thread) is treated the same. > And what do the SMT and Multi-Core scheduling options in the kernel config are for ? Because of this thread I re-read the help text, and it looks like on could de-select the SMT scheduler option, get a working SMP system, and see what difference ? I suppose its related to migration and cache flushing and so on, but where could I get more details ? And more strange, what is the difference between multi-core and normal SMP configs ? > > Another question. When the number of threads exceeds the number of > > CPU cores, we may get a lot of idle time. Then a workaround of > > MySQL is that do not creat threads which exceeds the number > > of CPU cores. Is it right? > > Not really, that would make it impossible for MySQL to > handle more simultaneous database queries than the system > has CPUs. > I don't know myqsl internals, but you assume one thread per query. If its more like Apache, one long living thread for several connections ? Its the same to answer 4+4 queries than 8 at half the speed, isn't it ? > Besides, it looks like this is not a problem in MySQL > per se (it works on FreeBSD) but some bug in Linux. > -- 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.19-jam07 (gcc 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.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: list.h , list_head and C++
On Tue, 27 Feb 2007 08:34:13 -0600, Robert Hancock <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > On Feb 26, 2:26 pm, Robert Hancock <[EMAIL PROTECTED]> wrote: > >> [EMAIL PROTECTED] wrote: > >>> My C++ program needs an intrusive list, possibly with RCU > >>> capabilities.The data structurelist_head, defined in /usr/include/ > >>> linux/list.h , fits perfectly these needs. In userspace you're better thinking of a STL list protected by some POSIX threads primitives. Depending on what you really want to do with the list, for example a shared work queue, you could look into condition variables or rwlocks. Use the standard STL list. You will save a lot of work. And they are not so bad in performance. -- 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.19-jam07 (gcc 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.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: somebody dropped a (warning) bomb
On Thu, 8 Feb 2007 11:53:38 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Thu, 8 Feb 2007, Jan Engelhardt wrote: > > > > I generally have to agree with you about the unsigned char* vs char*. It > > is a problem of the C language that char can be signed and unsigned, and > > that people, as a result, have used it for storing > > "shorter_than_short_t"s. > > > > What C needs is a distinction between char and int8_t, rendering "char" > > an unsigned at all times basically and making "unsigned char" and > > "signed char" illegal types in turn. > > No, it's really more fundamental than that. > > Exactly because "char *" doesn't have a defined sign, only a TOTALLY > INCOMPETENT compiler will warn about its signedness. > Perhaps the problem is that gcc warns you something like 'if you care anything about the sign behaviour of what you send to strlen() you're doomed'. Ie, you declared the var unsigned, so you care about it. But I can do anything without any regard to the sign. -- 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.19-jam06 (gcc 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.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: somebody dropped a (warning) bomb
On Thu, 8 Feb 2007 14:03:06 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]>
wrote:
>
>
> On Thu, 8 Feb 2007, Linus Torvalds wrote:
> >
> > But THE CALLER CANNOT AND MUST NOT CARE! Because the sign of "char" is
> > implementation-defined, so if you call "strcmp()", you are already
> > basically saying: I don't care (and I _cannot_ care) what sign you are
> > using.
>
> Let me explain it another way.
>
> Say you use
>
> signed char *myname, *yourname;
>
> if (strcmp(myname,yourname) < 0)
> printf("Ha, I win!\n")
>
> and you compile this on an architecture where "char" is signed even
> without the explicit "signed".
>
> What should happen?
>
> Should you get a warning? The types really *are* the same, so getting a
> warning sounds obviously insane. But on the other hand, if you really care
> about the sign that strcmp() uses internally, the code is wrong *anyway*,
Thats the point. Mmmm, I think I see it the other way around. I defined
a variable as 'signed' or 'unsigned', because the sign info matters for me.
And gcc warns about using a function on it that will _ignore_ or even
misinterpret that info. Could it be a BUG ? Yes.
> because with another compiler, or with the *same* compiler on another
> architecture or some other compiler flags, the very same code is buggy.
>
> In other words, either you should get a warning *regardless* of whether
> the sign actually matches or not, or you shouldn't get a warning at all
> for the above code. Either it's buggy code, or it isn't.
>
In fact, I tried to look for an arch where this gives only _one_ error:
#include
void f()
{
const unsigned char *a;
const signed char *b;
int la,lb;
la = strlen(a);
lb = strlen(b);
}
and guess, all give _both_ errors.
Linux/x86, gcc 4.1.2-0.20070115:
werewolf:~> gcc -Wpointer-sign -c t.c
t.c: In function ‘f’:
t.c:10: warning: pointer targets in passing argument 1 of ‘strlen’ differ in
signedness
t.c:11: warning: pointer targets in passing argument 1 of ‘strlen’ differ in
signedness
OSX ppc, gcc-4.0.1
belly:~> gcc -Wpointer-sign -c t.c
t.c: In function ‘f’:
t.c:10: warning: pointer targets in passing argument 1 of ‘strlen’ differ in
signedness
t.c:11: warning: pointer targets in passing argument 1 of ‘strlen’ differ in
signedness
Solaris5.7 Ultra, cc WorkShop Compilers 5.0
den:~> cc -Xa -c t.c
ucbcc: Warning: "-Xa" redefines compatibility mode from "SunC transition" to
"ANSI"
"t.c", line 10: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/string.h", line 71
argument : pointer to const uchar
"t.c", line 11: warning: argument #1 is incompatible with prototype:
prototype: pointer to const char : "/usr/include/string.h", line 71
argument : pointer to const schar
This makes sense.
Someone can try on something psychedelic, like ARM ;) ?
--
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.19-jam06 (gcc 4.1.2 20070115 (prerelease)
(4.1.2-0.20070115.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: [PATCH] Re: Bio device too big | kernel BUG at mm/filemap.c:537!
On Wed, 7 Feb 2007 10:26:56 +1100, Neil Brown <[EMAIL PROTECTED]> wrote:
> On Tuesday February 6, [EMAIL PROTECTED] wrote:
> >
> > This patch should fix the worst of the offences, but I'd like to
> > experiment and think a bit more before I submit it to stable.
> > And probably test it too - as yet I have only compile and brain
> > tested.
>
> Ok, I've experimented and tested and now I know what was causing the
> double-unlock.
>
> The following patch is suitable for 2.6.20.1 and mainline. There is
> room for a bit more improvement, but only for performance, not
> correctness. I'll look into that later.
>
> + blk_recount_segments(q, bi);
I needed to export blk_recount_segments() to build raid as a module:
--- linux/block/ll_rw_blk.c.orig2007-02-12 09:46:55.0 +0100
+++ linux/block/ll_rw_blk.c 2007-02-12 09:45:57.0 +0100
@@ -1258,6 +1258,8 @@
bio->bi_flags |= (1 << BIO_SEG_VALID);
}
+EXPORT_SYMBOL(blk_recount_segments);
+
static int blk_phys_contig_segment(request_queue_t *q, struct bio *bio,
struct bio *nxt)
{
--
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.19-jam06 (gcc 4.1.2 20070115 (prerelease)
(4.1.2-0.20070115.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.20-mm1
On Thu, 15 Feb 2007 05:14:08 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.20-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/ > > Oops plague for me :(. A lot like this: ee1394 usblp evdev CPU:1 EIP:0060:[]Tainted: P VLI EFLAGS: 00010246 (2.6.20-jam01 #1) EIP is at sysfs_lookup+0x5b/0x20a eax: f6707118 ebx: f6b33e5c ecx: f6917d38 edx: 0004 esi: edi: f670717c ebp: f6b33e24 esp: f6997db4 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process udevd (pid: 3899, ti=f6996000 task=f7e34540 task.ti=f6996000) Stack: f66e1800 f6707118 c016da12 f66e1800 f6707118 c02f75c0 f6707118 f6997f04 f6997e38 c0164238 f6997e44 c210d8c0 f6b39340 f6b393b4 f7a7d025 f6997e38 27692f8b f6997f04 c0165a6a f7a7d01d 000200d2 c037ddac 0286 Call Trace: [] d_alloc+0x140/0x198 [] do_lookup+0x128/0x165 [] __link_path_walk+0x7e2/0xc9b [] link_path_walk+0x45/0xbf [] do_path_lookup+0x88/0x1cc [] getname+0x90/0xad [] __user_walk_fd+0x2f/0x47 [] vfs_lstat_fd+0x16/0x3d [] sys_lstat64+0xf/0x23 [] do_page_fault+0x326/0x5e2 [] do_page_fault+0x0/0x5e2 [] sysenter_past_esp+0x5f/0x85 [] wait_for_completion_interruptible+0xdf/0xee === Code: 83 ed 04 8b 45 04 0f 18 00 90 8d 45 04 39 d8 0f 84 bc 00 00 00 f6 45 18 2c 74 e2 89 e8 e8 ed e4 ff ff 89 c6 8b 44 24 10 8b 78 28 ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 be 8b EIP: [] sysfs_lookup+0x5b/0x20a SS:ESP 0068:f6997db4 BUG: unable to handle kernel NULL pointer dereference at virtual address printing eip: c01963ff *pde = Oops: [#5] PREEMPT SMP last sysfs file: /devices/pci:00/:00:00.0/resource Modules linked in: nfsd exportfs lockd nfs_acl sunrpc w83627hf hwmon_vid hwmon i2c_isa i2c_i801 i2c_dev microcode snd_intel8x0 snd_ens1371 gameport snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd nvidia(P) loop intel_agp agpgart udf e1000 3c59x ohci1394 ieee1394 usblp evdev CPU:1 EIP:0060:[]Tainted: P VLI EFLAGS: 00010246 (2.6.20-jam01 #1) EIP is at sysfs_follow_link+0x109/0x254 eax: ebx: 0001 ecx: edx: esi: edi: ebp: 0003 esp: f70fdea4 ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process udevd (pid: 3900, ti=f70fc000 task=c21f5070 task.ti=f70fc000) Stack: f6917cd8 f70fdedc f670b000 f7321c88 f6917cd8 ffea c02f76a0 f6707aa8 0200 bfa2c2fc c0163e50 b7fc9ff4 f70fc000 f70fdfb8 f7f732f4 c21f5070 f7f732c0 f70fdfb8 c011d757 f6cfbe68 f70fdf44 Call Trace: [] generic_readlink+0x27/0x6e [] timespec_trunc+0x18/0x57 [] current_fs_time+0x4d/0x66 [] touch_atime+0x6e/0xee [] sys_readlinkat+0x61/0x7a [] do_page_fault+0x326/0x5e2 [] sys_readlink+0x27/0x2b [] sysenter_past_esp+0x5f/0x85 [] wait_for_completion_interruptible+0xdf/0xee === Full dmesg at: http://belly.cps.unizar.es/~magallon/oops/oops.txt And another one on reboot. Picture here: http://belly.cps.unizar.es/~magallon/oops/IMG_1448.JPG (sorry, no tripod available ;), just the back of my soft chair). And yes, before nobody says anything, nvidia.ko is loaded. If you really want, I can try without 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.19-jam07 (gcc 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.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.20-mm1
On Thu, 15 Feb 2007 15:31:42 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Thu, 15 Feb 2007 22:30:17 +0100 > "J.A. Magall__n" <[EMAIL PROTECTED]> wrote: > > > On Thu, 15 Feb 2007 05:14:08 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > > > Temporarily at > > > > > > http://userweb.kernel.org/~akpm/2.6.20-mm1/ > > > > > > Will appear later at > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/ > > > > > > > > > > Oops plague for me :(. > > > > A lot like this: > > > > ee1394 usblp evdev > > CPU:1 > > EIP:0060:[]Tainted: P VLI > > EFLAGS: 00010246 (2.6.20-jam01 #1) > > EIP is at sysfs_lookup+0x5b/0x20a > > eax: f6707118 ebx: f6b33e5c ecx: f6917d38 edx: 0004 > > esi: edi: f670717c ebp: f6b33e24 esp: f6997db4 > > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > > Process udevd (pid: 3899, ti=f6996000 task=f7e34540 task.ti=f6996000) > > Stack: f66e1800 f6707118 c016da12 f66e1800 f6707118 c02f75c0 f6707118 > > f6997f04 > >f6997e38 c0164238 f6997e44 c210d8c0 f6b39340 f6b393b4 f7a7d025 > > f6997e38 > >27692f8b f6997f04 c0165a6a f7a7d01d 000200d2 c037ddac > > 0286 > > Call Trace: > > [] d_alloc+0x140/0x198 > > [] do_lookup+0x128/0x165 > > [] __link_path_walk+0x7e2/0xc9b > > [] link_path_walk+0x45/0xbf > > [] do_path_lookup+0x88/0x1cc > > [] getname+0x90/0xad > > [] __user_walk_fd+0x2f/0x47 > > [] vfs_lstat_fd+0x16/0x3d > > [] sys_lstat64+0xf/0x23 > > [] do_page_fault+0x326/0x5e2 > > [] do_page_fault+0x0/0x5e2 > > [] sysenter_past_esp+0x5f/0x85 > > [] wait_for_completion_interruptible+0xdf/0xee > > > Oh dear. Any one of about 700 developers might have caused this. > > bisection-search will find this. Can you upload the .config please? > Here it goes: http://belly.cps.unizar.es/~magallon/oops/config-2.6.20-jam01 copied from previous and answered missing CONFIG_'s. Just 2.6.20-m11 + 11-pci-iomap-regions posted in LKML + patch to make HDIO_OBSOLETE_IDENTITY work on sata (also from LKML). > > > > Full dmesg at: > > > > http://belly.cps.unizar.es/~magallon/oops/oops.txt > > > > And another one on reboot. Picture here: > > > > http://belly.cps.unizar.es/~magallon/oops/IMG_1448.JPG > > > > (sorry, no tripod available ;), just the back of my soft chair). > > > > And yes, before nobody says anything, nvidia.ko is loaded. > > If you really want, I can try without it. > > It would be appreciated if you could do that, thanks. Probably tomorrow. -- 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.19-jam07 (gcc 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.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.20-mm1
On Thu, 15 Feb 2007 21:30:06 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Nope, can't reproduce (the bug, that is). > > Actually, the oops you have there is the fourth one, so we might be seeing > downstream effects of oops #1. Can you please capture the first oops > trace? Increasing the log buffer size or using netconsole might help. Well, forget it. Booting without the nVidia driver makes the oopses go away. I looks like nvidia is doing something strange with the i2c interface. D**d closed source drivers... -- 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.19-jam07 (gcc 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.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/
Question on ALSA intel8x0
Hi... I have a curious issue with snd_intel8x0 ALSA driver: Jan 7 01:14:27 werewolf-wl kernel: ACPI: PCI interrupt for device :00:1f.5 disabled Jan 7 01:14:27 werewolf-wl kernel: ACPI: PCI Interrupt :00:1f.5[B] -> GSI 17 (level, low) -> IRQ 21 Jan 7 01:14:27 werewolf-wl kernel: PCI: Setting latency timer of device :00:1f.5 to 64 Jan 7 01:14:27 werewolf-wl kernel: AC'97 0 analog subsections not ready Jan 7 01:14:27 werewolf-wl kernel: intel8x0_measure_ac97_clock: measured 50136 usecs Jan 7 01:14:27 werewolf-wl kernel: intel8x0: measured clock 219 rejected Jan 7 01:14:27 werewolf-wl kernel: intel8x0: clocking to 48000 And this file is created: /dev/.udev/failed/[EMAIL PROTECTED]@controlC0 What does this 'failed' mean ? Why is my card 'not ready' ? Sound works, anyways. BTW, before alsa driver loads, I hear a strange whisper through the speakers, nothing since the sound subsystem is initialized. Bad connections ? -- 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.19-jam03 (gcc 4.1.2 20061110 (prerelease) (4.1.2-0.20061110.1mdv2007.1)) #0 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: macros: "do-while" versus "({ })" and a compile-time error
On Wed, 10 Jan 2007 07:16:55 -0500, "linux-os \(Dick Johnson\)" <[EMAIL
PROTECTED]> wrote:
>
> On Wed, 10 Jan 2007, Robert P. J. Day wrote:
>
> > On Tue, 9 Jan 2007, linux-os (Dick Johnson) wrote:
> >
> >>
> >> On Tue, 9 Jan 2007, Stefan Richter wrote:
> >>
> >>> Robert P. J. Day wrote:
> just to stir the pot a bit regarding the discussion of the two
> different ways to define macros,
> >>>
> >>> You mean function-like macros, right?
> >>>
> i've just noticed that the "({ })"
> notation is not universally acceptable. i've seen examples where
> using that notation causes gcc to produce:
>
> error: braced-group within expression allowed only inside a function
> >>>
> >>> And function calls and macros which expand to "do { expr; } while (0)"
> >>> won't work anywhere outside of functions either.
> >>>
> i wasn't aware that there were limits on this notation. can someone
> clarify this? under what circumstances *can't* you use that notation?
> thanks.
> >>>
> >>> The limitations are certainly highly compiler-specific.
> >>
> >> I don't think so. You certainly couldn't write working 'C' code like
> >> this:
> >>
> >>do { a = 1; } while(0);
> >>
> >> This _needs_ to be inside a function. In fact any runtime operations
> >> need to be inside functions. It's only in assembly that you could
> >> 'roll your own' code like:
> >>
> >> main:
> >>ret 0
> >>
> >>
> >> Most of these errors come about as a result of changes where a macro
> >> used to define a constant. Later on, it was no longer a constant in
> >> code that didn't actually get compiled during the testing.
> >
> > just FYI, the reason i brought this up in the first place is that i
> > noticed that the ALIGN() macro in kernel.h didn't verify that the
> > alignment value was a power of 2, so i thought -- hmmm, i wonder if
> > there are any invocations where that's not true, so i (temporarily)
> > rewrote ALIGN to incorporate that check, and the build blew up
> > including include/net/neighbour.h, which contains the out-of-function
> > declaration:
> >
> > struct neighbour
> > {
> >...
> >unsigned char ha[ALIGN(MAX_ADDR_LEN, sizeof(unsigned
> > long))];
> >...
> >
> > so it's not a big deal, it was just me goofing around and breaking
> > things.
> >
> > rday
>
>
> Hmmm, in that case you would be trying to put code inside a structure!
> Neat --if you could do it!
>
The ({ }) is a block expression, ie, it allows declaring variables and
executing code. Its a gcc extension trying to resemble what other languages
like ML have:
ML:
f = let
y = x*x
in
2*y + sin(y)
end
GNU C:
f = ({ int y = x*x;
2*y + sin(y); })
So you can put it on every place you could also put a { } block or declare a
variable. {} is a compund command and ({ }) is a compund expression
(or block expression, do not know which is the good name in engelish).
--
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.19-jam03 (gcc 4.1.2 20061110 (prerelease)
(4.1.2-0.20061110.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/
oprofile as user
Hi First of all, thanks for oprofile ! It's the first tool I can really use to profile my app, with a ton of dynamically loaded plugins and without having to link everything statically... But, it there any sane way to use it as non-root user ? Is there any alternative ? I'm even thinking of suid'ing opcontrol. I tried sysprof, but it locks the machine as soon as I load the module. I use the latest -mm kernel. Any ideas ? 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.18-jam14 (gcc 4.1.2 20061110 (prerelease) (4.1.2-0.20061110.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.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 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, 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/
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/
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/
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/
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/
/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/
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-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/ > 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 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: 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-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/
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/
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 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 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/
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: 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/
Re: 2.6.21-rc2-mm1
On Fri, 2 Mar 2007 03:00:26 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc2/2.6.21-rc2-mm1/ > nfs blocks shutdown and reboot. If I try to do 'service nfs stop', the box hangs, no login, no SysRQ-T or P, S-U-B works at least. 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-jam01 (gcc 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.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-rc2-mm1
On Fri, 2 Mar 2007 03:00:26 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc2/2.6.21-rc2-mm1/ > > I'm also noticing very bad behaviour wrt scheduling, I think. When I launch my parallel cpu burning code, the system _really_ stalls, the mouse in X11 is not jerky, it is _stuck_ for a couple or three seconds... The only diffrecence is that, trying to solve nVidia driver problems, I disabled BKL preemption: werewolf:/usr/src/linux# grep PREEMPT .config # CONFIG_PREEMPT_RCU is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y # CONFIG_PREEMPT_BKL is not set -- 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-jam01 (gcc 4.1.2 20070115 (prerelease) (4.1.2-0.20070115.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/
i2c vs nVidia [Re: 2.6.21-rc2-mm1]
On Fri, 2 Mar 2007 03:00:26 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/
>
More things...
Yes, this is related to nVidia driver. First of all, I'm not asking for help
for a broken closed-source driver. I just want Linux to be foolbullet-proof
;).
As one can expect from a closed-source driver, recent changes in Linux broke it.
New nVidia drivers include some i2c sensors. The driver worked till
2.6.20-rc6-mm3.
Since then, I can't use them. I have tracked down the problem to i2c.
nVidia driver tries to create 3 i2c devices, and I get this:
**WARNING** I2C adapter driver [NVIDIA i2c adapter 0 at 1:00.0] forgot to
specify physical device; fix it!
i2c-10: attach_adapter failed (-16) for driver [w83627hf]
**WARNING** I2C adapter driver [NVIDIA i2c adapter 1 at 1:00.0] forgot to
specify physical device; fix it!
i2c-11: attach_adapter failed (-16) for driver [w83627hf]
**WARNING** I2C adapter driver [NVIDIA i2c adapter 2 at 1:00.0] forgot to
specify physical device; fix it!
i2c-12: attach_adapter failed (-16) for driver [w83627hf]
Two problems arise:
- The directories in /sys/class/i2c-adapter/ are created, but trying to ls
its contents oopses:
last sysfs file: class/i2c-adapter/i2c-0/name
Modules linked in: nvidia(P) nfsd exportfs lockd nfs_acl sunrpc snd_intel8x0
snd_ens1371 gameport snd_rawmidi snd_ac97_codec w83627hf ac97_bus hwmon_vid
snd_pcm hwmon snd_timer i2c_isa snd_page_alloc i2c_i801 snd i2c_dev loop
intel_agp agpgart udf e1000 3c59x microcode ohci1394 ieee1394 usblp evdev
CPU:3
EIP:0060:[]Tainted: P VLI
EFLAGS: 00010202 (2.6.20-jam01 #1)
EIP is at sysfs_follow_link+0xe6/0x254
eax: 00020b36 ebx: f329edd8 ecx: edx: f4ab84d8
esi: f0df4ee8 edi: 0100 ebp: 0002 esp: f4039ea4
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process sensors (pid: 4991, ti=f4038000 task=f7efa540 task.ti=f4038000)
Stack: f7ee4338 f4039edc f0ef7000 ffea f4ab84d8 c0387128
c02f76a0 f329edd8 0100 bfd2b6fc c0162b12
45eb5857 1f6efe56 c2235fc0 f4039f44 c011c434
Call Trace:
[] generic_readlink+0x27/0x6e
[] timespec_trunc+0x18/0x5d
[] current_fs_time+0x41/0x50
[] sys_readlinkat+0x61/0x7a
[] sys_readlink+0x27/0x2b
[] sysenter_past_esp+0x5f/0x85
[] __down_interruptible+0xa2/0x10e
===
Code: 24 18 b8 00 b2 39 c0 e8 6e ba 15 00 8b 44 24 18 85 c0 0f 84 42 01 00 00
b8 cc ee 37 c0 e8 dd 73 f9 ff 8b 44 24 10 31 ed 83 c5 01 <8b> 40 24 85 c0 75 f6
8b 44 24 18 89 04 24 bb 01 00 00 00 31 f6
EIP: [] sysfs_follow_link+0xe6/0x254 SS:ESP 0068:f4039ea4
BUG: at lib/kref.c:32 kref_get()
[] kref_get+0x3d/0x3f
[] kobject_get+0xf/0x13
[] sysfs_follow_link+0x1da/0x254
[] generic_readlink+0x27/0x6e
[] timespec_trunc+0x18/0x5d
[] current_fs_time+0x41/0x50
[] sys_readlinkat+0x61/0x7a
[] sys_readlink+0x27/0x2b
[] sysenter_past_esp+0x5f/0x85
[] __down_interruptible+0xa2/0x10e
===
- As adapters do not get a driver (or what ?), each time you start X, three
new folders are created in /sys/class/i2c-adapter/
For some AGP black magic, the driver is loaded/registered/whatever 2 times
on each X start.
So, after each X start, you get SIX broken dirs in /sys that hang and oops
every app that tries to list i2c devices (like Gnome Sensors Applet, so your
Gnome login hangs forever). Just ls /sys/class/i2c-adapter/i2c-*/.
It also oopses when removing i2c modules.
No driver should be able to do that to Linux, even if I try lo load a jpeg
of my children renamed to .ko
--
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-jam01 (gcc 4.1.2 20070115 (prerelease)
(4.1.2-0.20070115.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: [PATCH] sched: fix idle at tick
On Tue, 6 Mar 2007 18:41:08 +1100, Con Kolivas <[EMAIL PROTECTED]> wrote: > On Tuesday 06 March 2007 18:02, Andrew Morton wrote: > > On Tue, 6 Mar 2007 17:25:36 +1100 Con Kolivas <[EMAIL PROTECTED]> wrote: > > > Signed-off-by: Con Kolivas <[EMAIL PROTECTED]> > > > --- > > > kernel/sched.c |2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > Index: linux-2.6.21-rc2-mm1-base/kernel/sched.c > > > === > > > --- linux-2.6.21-rc2-mm1-base.orig/kernel/sched.c 2007-03-06 > > > 17:19:17.0 +1100 +++ > > > linux-2.6.21-rc2-mm1-base/kernel/sched.c 2007-03-06 17:20:40.0 > > > +1100 @@ -3444,7 +3444,7 @@ void scheduler_tick(void) > > > > > > update_cpu_clock(p, rq, now); > > > > > > - if (idle_at_tick) > > > + if (!idle_at_tick) > > > task_running_tick(rq, p); > > > #ifdef CONFIG_SMP > > > update_load(rq); > > > > Looks right, thanks. The original patch had > > > > - if (p == rq->idle) > > + if (idle_at_tick) > > /* Task on the idle queue */ > > wake_priority_sleeper(rq); > > else > > task_running_tick(rq, p); > > > > but it got damaged by smt-nice removal. > > I gathered something like that happened. If it wasn't clear this change > caused > massive scheduler damage with no cpu accounting whatsoever occurring. I > recommend putting it in your hotfixes/ dir if you're not planning an -mm2 > soon. > Good! I can confirm this makes things going smoothly again (apart from the speed of the x11 nv driver at 1600x1200 ;) ). hot-fixes candidate. -- 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-jam01 (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-rc2-mm2
On Tue, 6 Mar 2007 00:44:08 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.21-rc2-mm2/
>
Does this include a fix for the NFS problem ?
BTW, I have in my kernel a patch like this below, isn't it needed ?
Original thread:
http://marc.theaimsgroup.com/?l=linux-kernel&m=117189051227292&w=2
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -2919,14 +2919,14 @@ static int __make_request(request_queue_
*/
blk_queue_bounce(q, &bio);
+ spin_lock_irq(q->queue_lock);
/*
* Check if we can merge with the plugged list before grabbing
* any locks.
*/
if (!check_plug_merge(q, ioc, bio))
- goto out;
+ goto out_unlock;
- spin_lock_irq(q->queue_lock);
el_ret = elv_merge(q, &req, bio);
if (el_ret == ELEVATOR_BACK_MERGE) {
if (bio_attempt_back_merge(q, req, bio)) {
@@ -2984,7 +2984,6 @@ out_unlock:
list_add_tail(&req->queuelist, &ioc->plugged_list);
}
-out:
return 0;
end_io_eopnotsupp:
--
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-jam01 (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-rc2-mm2
On Tue, 6 Mar 2007 01:15:24 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Tue, 6 Mar 2007 10:06:23 +0100 "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > > > On Tue, 6 Mar 2007 00:44:08 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > > > Temporarily at > > > > > > http://userweb.kernel.org/~akpm/2.6.21-rc2-mm2/ > > > > > > > Does this include a fix for the NFS problem ? > > Which NFS problem? > http://marc.theaimsgroup.com/?l=linux-kernel&m=117305359825926&w=2 > > BTW, I have in my kernel a patch like this below, isn't it needed ? > > Original thread: > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=117189051227292&w=2 > > That patch caused additional failures. But I tossed out the git-block tree, > so that problem should no longer be there. > OK, 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-jam01 (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-rc2-mm2
On Tue, 6 Mar 2007 01:42:40 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Tue, 6 Mar 2007 10:38:23 +0100 "J.A. Magallón" <[EMAIL PROTECTED]> wrote: > > > On Tue, 6 Mar 2007 01:15:24 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > On Tue, 6 Mar 2007 10:06:23 +0100 "J.A. Magallón" <[EMAIL PROTECTED]> > > > wrote: > > > > > > > On Tue, 6 Mar 2007 00:44:08 -0800, Andrew Morton <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > > > > > Temporarily at > > > > > > > > > > http://userweb.kernel.org/~akpm/2.6.21-rc2-mm2/ > > > > > > > > > > > > > Does this include a fix for the NFS problem ? > > > > > > Which NFS problem? > > > > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=117305359825926&w=2 > > yup, that got fixed. Thanks, I will build it tonite... -- 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-jam01 (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-rc2-mm2
On Tue, 6 Mar 2007 00:44:08 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc2-mm2/ > I have another question about i2c... The 'sensors' program gives me a stange message: w83627thf-i2c-9191-290 Can't get adapter name for bus 9191<- VCore: +1.49 V (min = +1.94 V, max = +1.94 V) ALARM +12.0V: +11.86 V (min = +10.82 V, max = +13.19 V) + 3.3V:+3.30 V (min = +3.14 V, max = +3.47 V) ... And gnome-sensors-applet can't read the sensors. If using libsensors, no value is displayed (I suppose an applicacion bug). And the access to sensors directly through i2c-dev gives an error like this: Error opening sensor device file: /sys/devices/platform/i2c-9191/9191-0290/ In fact, the real path is /sys/devices/platform/i2c-adapter:i2c-9191/9191-0290/ I supposed it was a kernel change not tracked by userspace, but the strange thing is that looking at the code the sensors applet lists the sensors reding directories and files in /sys (AFAICS in the code). So perhaps there is a little inconsistency, /sys says in some place the sensor is at x, when it really is at y. Or the 'i2c-adapter:' is a bug and should be 'i2c-adapter/'. ??? -- 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-jam02 (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/
e1000 oops on boot [Re: 2.6.21-rc2-mm2]
On Tue, 6 Mar 2007 00:44:08 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.21-rc2-mm2/ > e1000 gave this on a warm boot: http://belly.cps.unizar.es/~magallon/oops/IMG_1510.JPG Any idea ? -- 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-jam02 (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 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/
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
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: 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 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: 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, 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/
