Re: screen goes blank when loading gma500_gfx (atom D2500)

[Michael Tokarev]

19.03.2015 14:56, One Thousand Gnomes wrote:
> On Thu, 19 Mar 2015 14:09:29 +0300
> Michael Tokarev  wrote:
> 
>> Half a year passed since my first email in this thread, and current kernels
>> (4.0-tobe) still does not work properly.  Meanwhile, I found this thread:
>> http://www.linuxquestions.org/questions/slackware-installation-40/black-screen-on-intel-desktopboard-d2500cc-4175503983/
>> which seems to help.  I wonder where they got these boot params from...
>>
> 
> Its one of the standard suggestions for dealing with wonky DRM I think.
> 
> If that makes the difference on your box can you send me a dmidecode of
> it, and I'll see if we can at least teach the driver that the 2500CC
> needs LVDS enabled regardless of what the BIOS reports.

Ok. actually this is not so simple.

Yes, LVDS:d makes a difference.  Namely, it enables monitor connected to
VGA-0 to function.

But once I plug in a digital monitor (DVI-0), screen goes blank when loading
the module again, and this time, it does not matter whenever I specify any
video= options (trying to disable any combinations of listed adaptors),
screen is always blank.

So basically the thing is still unusable.  Because d-sub connection isn't
stable (picture "trembles" depending on the cable and environment conditions),
while digital option does not work.

In bios, there's an option to ENable LVDS (it is disabled by default) and
once enabled, to make it primary or secondary (with either automatically
or manually choosen secondary/primary, being d-sub or dvi).  When I enable
LVDS with any other monitor in bios, the thing does not work again, the
same way (screen goes blank once the module is loaded), but now d-sub/vga
monitor does not work too.

Ouf of curiocity I tried to run windows7 on this machine.  Apparently it
works with dvi monitor just fine and supports configuration with 2 monitors.
Maybe they have some quirks in the drivers, I dunno...

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: screen goes blank when loading gma500_gfx (atom D2500)

[Michael Tokarev]

19.03.2015 23:05, One Thousand Gnomes wrote:
>> Yes, with video=LVDS-1:d boot parameter, kernel boots fine and there is
>> graphics/video output on the screen, with the following message from kernel
>> when loading gma500_gfx:
>>
>> [6.472859] [drm] forcing LVDS-1 connector OFF
>>
>> (and a few others).
>>
>> There's one funky thing still -- the screen size is not calculated correctly
>> for the text (vga, d-sub) console, last text line is placed at about 3/4 of
>> the screen size, with the rest - 1/4 - of the screen being blank.
> 
> I've seen that in one other case, where what was in fact happening was
> that forcing the connector "off" was actually effectively leaving it as
> the BIOS set it.

When I use LVDS-1:d in the kernel command line, that connector is not shown
by utilities such as xrandr, at all.  There is, however, another connector,
named LVDS-0, and are also DVI-0, DVI-1, and DisplayPort-0, DisplayPort-1,
while this mobo only have DVI & D-SUB (and LVDS soldered on board too) and
no DP.  At least as far as I can see.  So at least one LVDS connector is
shown anyway (LVDS-0, not LVDS-1), and that one is "not connected".

Besides, DisplayPort-1 is shown as "connected" by xrandr, with monitor set
to 1024x768 mode, -- I think this is why the text VGA size is calculated
wrong.. Lemme see...

..nope.  Adding video=DisplayPort-1:d to the kernel command line (in
addition to video=LVDS-1:d) makes no difference, DisplayPort-1 is still
shown by xrandr as connected @1024x768.

> What happens if you then use xrandr to change the
> display sizes ?

X11 works fine as far as I can see.  Xrandr works and changes video modes.
Once I switch from X back to the text console the text size occupes 3/4 of
the screen only, as if the monitor was smaller.

I wonder if it will work with more than one monitor... ;)  I'll try hopefully
today.

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: screen goes blank when loading gma500_gfx (atom D2500)

[Michael Tokarev]

19.03.2015 14:56, One Thousand Gnomes wrote:
> On Thu, 19 Mar 2015 14:09:29 +0300
> Michael Tokarev  wrote:
> 
>> Half a year passed since my first email in this thread, and current kernels
>> (4.0-tobe) still does not work properly.  Meanwhile, I found this thread:
>> http://www.linuxquestions.org/questions/slackware-installation-40/black-screen-on-intel-desktopboard-d2500cc-4175503983/
>> which seems to help.  I wonder where they got these boot params from...
> 
> Its one of the standard suggestions for dealing with wonky DRM I think.
> 
> If that makes the difference on your box can you send me a dmidecode of
> it, and I'll see if we can at least teach the driver that the 2500CC
> needs LVDS enabled regardless of what the BIOS reports.

I think you mean disable, not enable, since this is (again, I think) what
video=LVDS-1:d kernel boot parameter does.

Yes, with video=LVDS-1:d boot parameter, kernel boots fine and there is
graphics/video output on the screen, with the following message from kernel
when loading gma500_gfx:

[6.472859] [drm] forcing LVDS-1 connector OFF

(and a few others).

There's one funky thing still -- the screen size is not calculated correctly
for the text (vga, d-sub) console, last text line is placed at about 3/4 of
the screen size, with the rest - 1/4 - of the screen being blank.

However, X seems to work fine, using generic modesetting driver.

Below is dmidecode output.

Thanks,

/mjt

===
# dmidecode 2.12
SMBIOS 2.7 present.
27 structures occupying 1491 bytes.
Table at 0x000EB920.

Handle 0x, DMI type 4, 42 bytes
Processor Information
Socket Designation: CPU 1
Type: Central Processor
Family: Other
Manufacturer: Intel(R) Corporation
ID: 61 06 03 00 FF FB EB BF
Version: Intel(R) Atom(TM) CPU D2500   @ 1.86GHz
Voltage: 1.1 V
External Clock: 133 MHz
Max Speed: 4000 MHz
Current Speed: 1868 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: 0x0003
L2 Cache Handle: 0x0001
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Core Count: 2
Core Enabled: 2
Thread Count: 1
Characteristics:
64-bit capable
Multi-Core
Execute Protection

Handle 0x0001, DMI type 7, 19 bytes
Cache Information
Socket Designation: Unknown
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Back
Location: Internal
Installed Size: 512 kB
Maximum Size: 512 kB
Supported SRAM Types:
Asynchronous
Installed SRAM Type: Asynchronous
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Data
Associativity: 8-way Set-associative

Handle 0x0002, DMI type 7, 19 bytes
Cache Information
Socket Designation: Unknown
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 32 kB
Maximum Size: 32 kB
Supported SRAM Types:
Asynchronous
Installed SRAM Type: Asynchronous
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Instruction
Associativity: 8-way Set-associative

Handle 0x0003, DMI type 7, 19 bytes
Cache Information
Socket Designation: Unknown
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 24 kB
Maximum Size: 24 kB
Supported SRAM Types:
Asynchronous
Installed SRAM Type: Asynchronous
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Data
Associativity: 32-way Set-associative

Handle 0x0004, DMI type 0, 24 bytes
BIOS Information
Vendor: Intel Corp.
Version: CCCDT10N.86A.0039.2013.0425.1625
Release Date: 04/25/2013
Address: 0xF
Runtime Size: 64 kB
ROM Size: 2048 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
ATAPI Zip drive boot is supported
BIOS boot specification is supported
Function key-initiat

Re: screen goes blank when loading gma500_gfx (atom D2500)

[Michael Tokarev]

19.03.2015 14:09, Michael Tokarev wrote:
> Half a year passed since my first email in this thread, and current kernels

Actually it was more than a year, since Feb-2014 ;)

> (4.0-tobe) still does not work properly.  Meanwhile, I found this thread:
> http://www.linuxquestions.org/questions/slackware-installation-40/black-screen-on-intel-desktopboard-d2500cc-4175503983/
> which seems to help.  I wonder where they got these boot params from...
> 
> Thanks,
> 
> /mjt

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: screen goes blank when loading gma500_gfx (atom D2500)

[Michael Tokarev]

Half a year passed since my first email in this thread, and current kernels
(4.0-tobe) still does not work properly.  Meanwhile, I found this thread:
http://www.linuxquestions.org/questions/slackware-installation-40/black-screen-on-intel-desktopboard-d2500cc-4175503983/
which seems to help.  I wonder where they got these boot params from...

Thanks,

/mjt

05.08.2014 20:15, Michael Tokarev wrote:
> 05.08.2014 20:11, Michael Tokarev wrote:
>> Hello again.
>>
>> It's been 4 more months since last message in this thread (which was mine).
>> Now kernel 3.16 has been released, and I decided to give it a try.  And it
>> behaves just like all previous kernels, -- once gma500_gfx module is loaded,
>> screen goes blank, monitor turns off ("no signal detected") and nothing to
>> be seen until reboot.
>>
>> Can we try to debug this somehow, after more than half a year?... :)
> 
> Current debugging (by 3.16), after:
> 
>  modprobe drm debug=6
>  modprobe gma500_gfx
> 
> on a freshly booted system:
> 
> [   46.463381] Linux agpgart interface v0.103
> [   46.491487] [drm] Initialized drm 1.1.0 20060810
> [   56.585520] [drm:psb_intel_opregion_setup] Public ACPI methods supported
> [   56.585528] [drm:psb_intel_opregion_setup] ASLE supported
> [   56.585563] gma500 :00:02.0: irq 50 for MSI/MSI-X
> [   56.585591] [drm:psb_intel_init_bios] Using VBT from OpRegion: $VBT 
> CEDARVIEW  d
> [   56.585604] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 0 
> 144000 1920 2016 2080 2176 1080 1088 1092 1100 0x8 0xa
> [   56.585609] [drm:parse_sdvo_device_mapping] No SDVO device info is found 
> in VBT
> [   56.585617] [drm:parse_edp] EDP timing in vbt t1_t3 2000 t8 10 t9 2000 t10 
> 500 t11_t12 5000
> [   56.585621] [drm:parse_edp] VBT reports EDP: Lane_count 1, Lane_rate 6, 
> Bpp 24
> [   56.585624] [drm:parse_edp] VBT reports EDP: VSwing  0, Preemph 0
> [   56.598203] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
> [   56.598902] acpi device:28: registered as cooling_device2
> [   56.599109] input: Video Bus as 
> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input11
> [   56.599326] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [   56.599366] [drm] No driver support for vblank timestamp query.
> [   56.650918] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent adapter 
> intel drm LVDSDDC_C
> [   56.651842] [drm:cdv_intel_dp_i2c_init] i2c_init DPDDC-B
> [   56.652352] [drm:cdv_intel_dp_aux_ch] dp_aux_ch timeout status 0x51440064
> [   56.652356] [drm:cdv_intel_dp_i2c_aux_ch] aux_ch failed -110
> [   56.652863] [drm:cdv_intel_dp_aux_ch] dp_aux_ch timeout status 0x51440064
> [   56.652866] [drm:cdv_intel_dp_i2c_aux_ch] aux_ch failed -110
> [   56.653706] [drm:cdv_intel_dp_i2c_init] i2c_init DPDDC-C
> [   56.654014] [drm:cdv_intel_dp_i2c_aux_ch] aux_i2c nack
> [   56.654223] [drm:cdv_intel_dp_i2c_aux_ch] aux_i2c nack
> [   56.714765] gma500 :00:02.0: trying to get vblank count for disabled 
> pipe 1
> [   56.714812] gma500 :00:02.0: trying to get vblank count for disabled 
> pipe 1
> [   56.775220] [drm:drm_helper_probe_single_connector_modes_merge_bits] 
> [CONNECTOR:10:VGA-1]
> [   56.900606] [drm:drm_helper_probe_single_connector_modes_merge_bits] 
> [CONNECTOR:10:VGA-1] probed modes :
> [   56.900617] [drm:drm_mode_debug_printmodeline] Modeline 26:"1280x1024" 60 
> 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x48 0x5
> [   56.900624] [drm:drm_mode_debug_printmodeline] Modeline 36:"1280x1024" 75 
> 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
> [   56.900630] [drm:drm_mode_debug_printmodeline] Modeline 29:"1280x1024" 72 
> 132840 1280 1368 1504 1728 1024 1025 1028 1067 0x0 0x6
> [   56.900637] [drm:drm_mode_debug_printmodeline] Modeline 28:"1152x864" 75 
> 108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5
> [   56.900643] [drm:drm_mode_debug_printmodeline] Modeline 37:"1024x768" 75 
> 78800 1024 1040 1136 1312 768 769 772 800 0x40 0x5
> [   56.900649] [drm:drm_mode_debug_printmodeline] Modeline 38:"1024x768" 70 
> 75000 1024 1048 1184 1328 768 771 777 806 0x40 0xa
> [   56.900656] [drm:drm_mode_debug_printmodeline] Modeline 39:"1024x768" 60 
> 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
> [   56.900662] [drm:drm_mode_debug_printmodeline] Modeline 40:"832x624" 75 
> 57284 832 864 928 1152 624 625 628 667 0x40 0xa
> [   56.900669] [drm:drm_mode_debug_printmodeline] Modeline 41:"800x600" 75 
> 49500 800 816 896 1056 600 601 604 625 0x40 0x5
> [   56.900675] [drm:drm_mode_debug_printmodeline] Modeline 42:"800x600" 72 
> 5 800 856 976 1040 600 637

Re: screen goes blank when loading gma500_gfx (atom D2500)

[Michael Tokarev]

05.08.2014 20:11, Michael Tokarev wrote:
> Hello again.
> 
> It's been 4 more months since last message in this thread (which was mine).
> Now kernel 3.16 has been released, and I decided to give it a try.  And it
> behaves just like all previous kernels, -- once gma500_gfx module is loaded,
> screen goes blank, monitor turns off ("no signal detected") and nothing to
> be seen until reboot.
> 
> Can we try to debug this somehow, after more than half a year?... :)

Current debugging (by 3.16), after:

 modprobe drm debug=6
 modprobe gma500_gfx

on a freshly booted system:

[   46.463381] Linux agpgart interface v0.103
[   46.491487] [drm] Initialized drm 1.1.0 20060810
[   56.585520] [drm:psb_intel_opregion_setup] Public ACPI methods supported
[   56.585528] [drm:psb_intel_opregion_setup] ASLE supported
[   56.585563] gma500 :00:02.0: irq 50 for MSI/MSI-X
[   56.585591] [drm:psb_intel_init_bios] Using VBT from OpRegion: $VBT 
CEDARVIEW  d
[   56.585604] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 0 
144000 1920 2016 2080 2176 1080 1088 1092 1100 0x8 0xa
[   56.585609] [drm:parse_sdvo_device_mapping] No SDVO device info is found in 
VBT
[   56.585617] [drm:parse_edp] EDP timing in vbt t1_t3 2000 t8 10 t9 2000 t10 
500 t11_t12 5000
[   56.585621] [drm:parse_edp] VBT reports EDP: Lane_count 1, Lane_rate 6, Bpp 
24
[   56.585624] [drm:parse_edp] VBT reports EDP: VSwing  0, Preemph 0
[   56.598203] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[   56.598902] acpi device:28: registered as cooling_device2
[   56.599109] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input11
[   56.599326] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   56.599366] [drm] No driver support for vblank timestamp query.
[   56.650918] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent adapter 
intel drm LVDSDDC_C
[   56.651842] [drm:cdv_intel_dp_i2c_init] i2c_init DPDDC-B
[   56.652352] [drm:cdv_intel_dp_aux_ch] dp_aux_ch timeout status 0x51440064
[   56.652356] [drm:cdv_intel_dp_i2c_aux_ch] aux_ch failed -110
[   56.652863] [drm:cdv_intel_dp_aux_ch] dp_aux_ch timeout status 0x51440064
[   56.652866] [drm:cdv_intel_dp_i2c_aux_ch] aux_ch failed -110
[   56.653706] [drm:cdv_intel_dp_i2c_init] i2c_init DPDDC-C
[   56.654014] [drm:cdv_intel_dp_i2c_aux_ch] aux_i2c nack
[   56.654223] [drm:cdv_intel_dp_i2c_aux_ch] aux_i2c nack
[   56.714765] gma500 :00:02.0: trying to get vblank count for disabled 
pipe 1
[   56.714812] gma500 :00:02.0: trying to get vblank count for disabled 
pipe 1
[   56.775220] [drm:drm_helper_probe_single_connector_modes_merge_bits] 
[CONNECTOR:10:VGA-1]
[   56.900606] [drm:drm_helper_probe_single_connector_modes_merge_bits] 
[CONNECTOR:10:VGA-1] probed modes :
[   56.900617] [drm:drm_mode_debug_printmodeline] Modeline 26:"1280x1024" 60 
108000 1280 1328 1440 1688 1024 1025 1028 1066 0x48 0x5
[   56.900624] [drm:drm_mode_debug_printmodeline] Modeline 36:"1280x1024" 75 
135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
[   56.900630] [drm:drm_mode_debug_printmodeline] Modeline 29:"1280x1024" 72 
132840 1280 1368 1504 1728 1024 1025 1028 1067 0x0 0x6
[   56.900637] [drm:drm_mode_debug_printmodeline] Modeline 28:"1152x864" 75 
108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5
[   56.900643] [drm:drm_mode_debug_printmodeline] Modeline 37:"1024x768" 75 
78800 1024 1040 1136 1312 768 769 772 800 0x40 0x5
[   56.900649] [drm:drm_mode_debug_printmodeline] Modeline 38:"1024x768" 70 
75000 1024 1048 1184 1328 768 771 777 806 0x40 0xa
[   56.900656] [drm:drm_mode_debug_printmodeline] Modeline 39:"1024x768" 60 
65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[   56.900662] [drm:drm_mode_debug_printmodeline] Modeline 40:"832x624" 75 
57284 832 864 928 1152 624 625 628 667 0x40 0xa
[   56.900669] [drm:drm_mode_debug_printmodeline] Modeline 41:"800x600" 75 
49500 800 816 896 1056 600 601 604 625 0x40 0x5
[   56.900675] [drm:drm_mode_debug_printmodeline] Modeline 42:"800x600" 72 
5 800 856 976 1040 600 637 643 666 0x40 0x5
[   56.900681] [drm:drm_mode_debug_printmodeline] Modeline 30:"800x600" 60 
4 800 840 968 1056 600 601 605 628 0x40 0x5
[   56.900687] [drm:drm_mode_debug_printmodeline] Modeline 31:"640x480" 75 
31500 640 656 720 840 480 481 484 500 0x40 0xa
[   56.900694] [drm:drm_mode_debug_printmodeline] Modeline 32:"640x480" 73 
31500 640 664 704 832 480 489 491 520 0x40 0xa
[   56.900700] [drm:drm_mode_debug_printmodeline] Modeline 33:"640x480" 67 
30240 640 704 768 864 480 483 486 525 0x40 0xa
[   56.900706] [drm:drm_mode_debug_printmodeline] Modeline 34:"640x480" 60 
25200 640 656 752 800 480 490 492 525 0x40 0xa
[   56.900713] [drm:drm_mode_debug_printmodeline] Modelin

Re: screen goes blank when loading gma500_gfx (atom D2500)

[Michael Tokarev]

Hello again.

It's been 4 more months since last message in this thread (which was mine).
Now kernel 3.16 has been released, and I decided to give it a try.  And it
behaves just like all previous kernels, -- once gma500_gfx module is loaded,
screen goes blank, monitor turns off ("no signal detected") and nothing to
be seen until reboot.

Can we try to debug this somehow, after more than half a year?... :)

Thank you,

/mjt

05.04.2014 12:15, Michael Tokarev wrote:
> Hello again
> 
> It's been about 2 months since I sent the original debugging output.  Today I 
> tried
> out 3.14 kernel.  And this one behaves quite similarly, screen goes blank 
> right
> when loading gma500_gfx module.  Here's the dmesg from a freshly booted system
> after doing
> 
>   modprobe drm debug=6
>   modprobe gma500_gfx
> 
> with a monitor connected to VGA port (before loading gma500_gfx, it displays 
> the
> regular text console):
> 
> [   39.863330] Linux agpgart interface v0.103
> [   39.900511] [drm] Initialized drm 1.1.0 20060810
> [   45.012300] [drm:psb_intel_opregion_setup], Public ACPI methods supported
> [   45.012308] [drm:psb_intel_opregion_setup], ASLE supported
> [   45.012345] gma500 :00:02.0: irq 50 for MSI/MSI-X
> [   45.012371] [drm:psb_intel_init_bios], Using VBT from OpRegion: $VBT 
> CEDARVIEW  d
> [   45.012384] [drm:drm_mode_debug_printmodeline], Modeline 0:"1920x1080" 0 
> 144000 1920 2016 2080 2176 1080 1088 1092 1100 0x8 0xa
> [   45.012389] [drm:parse_sdvo_device_mapping], No SDVO device info is found 
> in VBT
> [   45.012397] [drm:parse_edp], EDP timing in vbt t1_t3 2000 t8 10 t9 2000 
> t10 500 t11_t12 5000
> [   45.012401] [drm:parse_edp], VBT reports EDP: Lane_count 1, Lane_rate 6, 
> Bpp 24
> [   45.012405] [drm:parse_edp], VBT reports EDP: VSwing  0, Preemph 0
> [   45.012478] gma500 :00:02.0: GPU: power management timed out.
> [   45.026195] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
> [   45.026891] acpi device:29: registered as cooling_device2
> [   45.027104] input: Video Bus as 
> /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input11
> [   45.027681] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [   45.027726] [drm] No driver support for vblank timestamp query.
> [   45.078928] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent 
> adapter intel drm LVDSDDC_C
> [   45.079839] [drm:cdv_intel_dp_i2c_init], i2c_init DPDDC-B
> [   45.080383] [drm:cdv_intel_dp_aux_ch], dp_aux_ch timeout status 0x51440064
> [   45.080388] [drm:cdv_intel_dp_i2c_aux_ch], aux_ch failed -110
> [   45.080896] [drm:cdv_intel_dp_aux_ch], dp_aux_ch timeout status 0x51440064
> [   45.080899] [drm:cdv_intel_dp_i2c_aux_ch], aux_ch failed -110
> [   45.081754] [drm:cdv_intel_dp_i2c_init], i2c_init DPDDC-C
> [   45.082062] [drm:cdv_intel_dp_i2c_aux_ch], aux_i2c nack
> [   45.082272] [drm:cdv_intel_dp_i2c_aux_ch], aux_i2c nack
> [   45.122742] [drm:cdv_intel_single_pipe_active], pipe enabled 0
> [   45.142780] gma500 :00:02.0: trying to get vblank count for disabled 
> pipe 1
> [   45.142826] gma500 :00:02.0: trying to get vblank count for disabled 
> pipe 1
> [   45.183207] [drm:cdv_intel_single_pipe_active], pipe enabled 0
> [   45.203249] [drm:drm_helper_probe_single_connector_modes], 
> [CONNECTOR:7:VGA-1]
> [   45.332286] [drm:drm_helper_probe_single_connector_modes], 
> [CONNECTOR:7:VGA-1] probed modes :
> [   45.332297] [drm:drm_mode_debug_printmodeline], Modeline 23:"1280x1024" 60 
> 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x48 0x5
> [   45.332304] [drm:drm_mode_debug_printmodeline], Modeline 33:"1280x1024" 75 
> 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
> [   45.332311] [drm:drm_mode_debug_printmodeline], Modeline 26:"1280x1024" 72 
> 132840 1280 1368 1504 1728 1024 1025 1028 1067 0x0 0x6
> [   45.332318] [drm:drm_mode_debug_printmodeline], Modeline 25:"1152x864" 75 
> 108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5
> [   45.332325] [drm:drm_mode_debug_printmodeline], Modeline 34:"1024x768" 75 
> 78800 1024 1040 1136 1312 768 769 772 800 0x40 0x5
> [   45.332332] [drm:drm_mode_debug_printmodeline], Modeline 35:"1024x768" 70 
> 75000 1024 1048 1184 1328 768 771 777 806 0x40 0xa
> [   45.332338] [drm:drm_mode_debug_printmodeline], Modeline 36:"1024x768" 60 
> 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
> [   45.332345] [drm:drm_mode_debug_printmodeline], Modeline 37:"832x624" 75 
> 57284 832 864 928 1152 624 625 628 667 0x40 0xa
> [   45.332352] [drm:drm_mode_debug_printmodeline], Modeline 38:"800x600" 75 
> 49500 800 816 896 1056 600 601 604 625 0x40 0x5
> [   45.

Re: [PATCH] arch: x86: kvm: x86.c: Cleaning up uninitialized variables

[Michael Tokarev]

03.06.2014 16:04, Paolo Bonzini wrote:
> Il 01/06/2014 01:05, Rickard Strandqvist ha scritto:
>> There is a risk that the variable will be used without being initialized.
>>
>> This was largely found by using a static code analysis program called 
>> cppcheck.
>>
>> Signed-off-by: Rickard Strandqvist 
> 
> No, there isn't.  The full context looks like this:
> 
> longmode = is_long_mode(vcpu) && cs_l == 1;
> if (!longmode) {
> param = ((u64)kvm_register_read(vcpu, VCPU_REGS_RDX) << 32) |
> (kvm_register_read(vcpu, VCPU_REGS_RAX) & 0x);
> ingpa = ((u64)kvm_register_read(vcpu, VCPU_REGS_RBX) << 32) |
> (kvm_register_read(vcpu, VCPU_REGS_RCX) & 0x);
> outgpa = ((u64)kvm_register_read(vcpu, VCPU_REGS_RDI) << 32) |
> (kvm_register_read(vcpu, VCPU_REGS_RSI) & 0x);
> }
> #ifdef CONFIG_X86_64
> else {
> param = kvm_register_read(vcpu, VCPU_REGS_RCX);
> ingpa = kvm_register_read(vcpu, VCPU_REGS_RDX);
> outgpa = kvm_register_read(vcpu, VCPU_REGS_R8);
> }
> #endif
> 
> and longmode must be zero if !CONFIG_X86_64:

This is not the first time this code is attempted to be changed.

Maybe adding an additional #ifdef..endif around the longmode
assignment and the "if" above will solve this for good?

Or maybe something like this:

 #ifdef CONFIG_X86_64
 if (!(is_long_mode(vcpu) && cs_l == 1)) {
 #else
 if (1) {
 #endif
 param = ((u64)kvm_register_read(vcpu, VCPU_REGS_RDX) << 32) |
 (kvm_register_read(vcpu, VCPU_REGS_RAX) & 0x);
 ingpa = ((u64)kvm_register_read(vcpu, VCPU_REGS_RBX) << 32) |
 (kvm_register_read(vcpu, VCPU_REGS_RCX) & 0x);
 outgpa = ((u64)kvm_register_read(vcpu, VCPU_REGS_RDI) << 32) |
 (kvm_register_read(vcpu, VCPU_REGS_RSI) & 0x);
 }
 else {
 param = kvm_register_read(vcpu, VCPU_REGS_RCX);
 ingpa = kvm_register_read(vcpu, VCPU_REGS_RDX);
 outgpa = kvm_register_read(vcpu, VCPU_REGS_R8);
 }

, to make it all explicit and obvious?

Thanks,

/mjt

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: screen goes blank when loading gma500_gfx (atom D2500)

[Michael Tokarev]

9
[   45.351935] [drm:drm_target_preferred], looking for preferred mode on 
connector 9
[   45.351938] [drm:drm_target_preferred], found mode 1920x1080
[   45.351942] [drm:drm_target_preferred], looking for cmdline mode on 
connector 20
[   45.351945] [drm:drm_target_preferred], looking for preferred mode on 
connector 20
[   45.351949] [drm:drm_target_preferred], found mode 1024x768
[   45.351953] [drm:drm_setup_crtcs], picking CRTCs for 4096x4096 config
[   45.351962] [drm:drm_setup_crtcs], desired mode 1280x1024 set on crtc 3
[   45.351967] [drm:drm_setup_crtcs], desired mode 1920x1080 set on crtc 4
[   45.351987] [drm] Initialized gma500 1.0.0 2011-06-06 for :00:02.0 on 
minor 0

Thank you!

/mjt

15.02.2014 22:28, Michael Tokarev wrote:
> 10.02.2014 14:44, One Thousand Gnomes wrote:
>>> fbcon is loaded so it isn't an issue.
>>>
>>> I tried 3.10 kernel initially (the above messages are from it), next
>>> I tried 3.13 kernel too, and that one behaves exactly the same.
>>>
>>> As far as I remember, this system never worked with graphics well.
>>> Previous kernel (from which I updated) was 3.2 which had no
>>> gma500 module (local build).
>>>
>>> What are the steps to debug this further?
>>
>> Check you have X86_SYSFB and SIMPLEFB disabled
> 
> Neither of these options exists in 3.10 config.  In 3.13 I had X86_SYSFB set
> to y initially (SIMPLEFB doesn't exist there too), but setting it to n does
> not make any difference.
> 
>> Boot with drm.debug=6
>>
>> collect the logs
> 
> I used `modprobe drm debug=6' (initially booting with gma500_gfx module
> disabled), followed with `modprobe gma500_gfx'.  After loading module
> the screen goes blank as before, and monitor says 'no signal detected'.
> 
> Here are the logs:
> 
> [599286.739923] Linux agpgart interface v0.103
> [599286.765176] [drm] Initialized drm 1.1.0 20060810
> [599303.673734] gma500 :00:02.0: setting latency timer to 64
> [599303.673883] [drm:psb_intel_opregion_setup], Public ACPI methods supported
> [599303.673887] [drm:psb_intel_opregion_setup], ASLE supported
> [599303.673923] gma500 :00:02.0: irq 50 for MSI/MSI-X
> [599303.673950] [drm:psb_intel_init_bios], Using VBT from OpRegion: $VBT 
> CEDARVIEW  d
> [599303.673959] [drm:drm_mode_debug_printmodeline], Modeline 0:"1920x1080" 0 
> 144000 1920 2016 2080 2176 1080 1088 1092 1100 0x8 0xa
> [599303.673969] [drm:parse_sdvo_device_mapping], No SDVO device info is found 
> in VBT
> [599303.673975] [drm:parse_edp], EDP timing in vbt t1_t3 2000 t8 10 t9 2000 
> t10 500 t11_t12 5000
> [599303.673980] [drm:parse_edp], VBT reports EDP: Lane_count 1, Lane_rate 6, 
> Bpp 24
> [599303.673984] [drm:parse_edp], VBT reports EDP: VSwing  0, Preemph 0
> [599303.688094] acpi device:29: registered as cooling_device2
> [599303.688446] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
> [599303.688557] input: Video Bus as 
> /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input11
> [599303.689160] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [599303.689188] [drm] No driver support for vblank timestamp query.
> [599303.740423] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent 
> adapter intel drm LVDSDDC_C
> [599303.741222] [drm:cdv_intel_dp_i2c_init], i2c_init DPDDC-B
> [599303.741732] [drm:cdv_intel_dp_aux_ch], dp_aux_ch timeout status 0x51440064
> [599303.741736] [drm:cdv_intel_dp_i2c_aux_ch], aux_ch failed -110
> [599303.742242] [drm:cdv_intel_dp_aux_ch], dp_aux_ch timeout status 0x51440064
> [599303.742246] [drm:cdv_intel_dp_i2c_aux_ch], aux_ch failed -110
> [599303.742997] [drm:cdv_intel_dp_i2c_init], i2c_init DPDDC-C
> [599303.743305] [drm:cdv_intel_dp_i2c_aux_ch], aux_i2c nack
> [599303.743510] [drm:cdv_intel_dp_i2c_aux_ch], aux_i2c nack
> [599303.783922] [drm:cdv_intel_single_pipe_active], pipe enabled 0
> [599303.803958] gma500 :00:02.0: trying to get vblank count for disabled 
> pipe 1
> [599303.803996] gma500 :00:02.0: trying to get vblank count for disabled 
> pipe 1
> [599303.844370] [drm:cdv_intel_single_pipe_active], pipe enabled 0
> [599303.864408] [drm:drm_helper_probe_single_connector_modes], 
> [CONNECTOR:7:VGA-1]
> [599303.877172] [drm:drm_helper_probe_single_connector_modes], 
> [CONNECTOR:7:VGA-1] disconnected
> [599303.877184] [drm:drm_helper_probe_single_connector_modes], 
> [CONNECTOR:9:LVDS-1]
> [599303.881764] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent 
> adapter intel drm LVDSBLC_B
> [599303.881778] [drm:drm_helper_probe_single_connector_modes], 
> [CONNECTOR:9:LVDS-1] probed modes :
> [599303.881783] [drm:drm_mode_debug_printmodeline], Modeline 22:&

Re: [Qemu-devel] Massive read only kvm guests when backing file was missing

[Michael Tokarev]

27.03.2014 20:14, Alejandro Comisario wrote:
> Seems like virtio (kvm 1.0) doesnt expose timeout on the guest side
> (ubuntu 12.04 on host and guest).
> So, how can i adjust the tinmeout on the guest ?

After a bit more talks on IRC yesterday, it turned out that the situation
is _much_ more "interesting" than originally described.  The OP claims to
have 10500 guests running off an NFS server, and that after NFS server
downtime, the "backing files" were disappeared (whatever it means), so
they had to restore those files.  More, the OP didn't even bother to look
at the guest's dmesg, being busy rebooting all 10500 guests.

> This solution is the most logical one, but i cannot apply it!
> thanks for all the responses!

I suggested the OP to actually describe the _real_ situation, instead of
giving random half-pictures, and actually take a look at the actual problem
as reported in various places (most importantly the guest kernel log), and
reoirt _those_ hints to the list.  I also mentioned that, at least for some
NFS servers, if a client has a file open on the server, and this file is
deleted, the server will report error to the client when client tries to
access that file, and this has nothing at all to do with timeouts of any
kind.

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: screen goes blank when loading gma500_gfx (atom D2500)

[Michael Tokarev]

10.02.2014 14:44, One Thousand Gnomes wrote:
>> fbcon is loaded so it isn't an issue.
>>
>> I tried 3.10 kernel initially (the above messages are from it), next
>> I tried 3.13 kernel too, and that one behaves exactly the same.
>>
>> As far as I remember, this system never worked with graphics well.
>> Previous kernel (from which I updated) was 3.2 which had no
>> gma500 module (local build).
>>
>> What are the steps to debug this further?
> 
> Check you have X86_SYSFB and SIMPLEFB disabled

Neither of these options exists in 3.10 config.  In 3.13 I had X86_SYSFB set
to y initially (SIMPLEFB doesn't exist there too), but setting it to n does
not make any difference.

> Boot with drm.debug=6
> 
> collect the logs

I used `modprobe drm debug=6' (initially booting with gma500_gfx module
disabled), followed with `modprobe gma500_gfx'.  After loading module
the screen goes blank as before, and monitor says 'no signal detected'.

Here are the logs:

[599286.739923] Linux agpgart interface v0.103
[599286.765176] [drm] Initialized drm 1.1.0 20060810
[599303.673734] gma500 :00:02.0: setting latency timer to 64
[599303.673883] [drm:psb_intel_opregion_setup], Public ACPI methods supported
[599303.673887] [drm:psb_intel_opregion_setup], ASLE supported
[599303.673923] gma500 :00:02.0: irq 50 for MSI/MSI-X
[599303.673950] [drm:psb_intel_init_bios], Using VBT from OpRegion: $VBT 
CEDARVIEW  d
[599303.673959] [drm:drm_mode_debug_printmodeline], Modeline 0:"1920x1080" 0 
144000 1920 2016 2080 2176 1080 1088 1092 1100 0x8 0xa
[599303.673969] [drm:parse_sdvo_device_mapping], No SDVO device info is found 
in VBT
[599303.673975] [drm:parse_edp], EDP timing in vbt t1_t3 2000 t8 10 t9 2000 t10 
500 t11_t12 5000
[599303.673980] [drm:parse_edp], VBT reports EDP: Lane_count 1, Lane_rate 6, 
Bpp 24
[599303.673984] [drm:parse_edp], VBT reports EDP: VSwing  0, Preemph 0
[599303.688094] acpi device:29: registered as cooling_device2
[599303.688446] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[599303.688557] input: Video Bus as 
/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input11
[599303.689160] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[599303.689188] [drm] No driver support for vblank timestamp query.
[599303.740423] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter 
intel drm LVDSDDC_C
[599303.741222] [drm:cdv_intel_dp_i2c_init], i2c_init DPDDC-B
[599303.741732] [drm:cdv_intel_dp_aux_ch], dp_aux_ch timeout status 0x51440064
[599303.741736] [drm:cdv_intel_dp_i2c_aux_ch], aux_ch failed -110
[599303.742242] [drm:cdv_intel_dp_aux_ch], dp_aux_ch timeout status 0x51440064
[599303.742246] [drm:cdv_intel_dp_i2c_aux_ch], aux_ch failed -110
[599303.742997] [drm:cdv_intel_dp_i2c_init], i2c_init DPDDC-C
[599303.743305] [drm:cdv_intel_dp_i2c_aux_ch], aux_i2c nack
[599303.743510] [drm:cdv_intel_dp_i2c_aux_ch], aux_i2c nack
[599303.783922] [drm:cdv_intel_single_pipe_active], pipe enabled 0
[599303.803958] gma500 :00:02.0: trying to get vblank count for disabled 
pipe 1
[599303.803996] gma500 :00:02.0: trying to get vblank count for disabled 
pipe 1
[599303.844370] [drm:cdv_intel_single_pipe_active], pipe enabled 0
[599303.864408] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:7:VGA-1]
[599303.877172] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:7:VGA-1] disconnected
[599303.877184] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:9:LVDS-1]
[599303.881764] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter 
intel drm LVDSBLC_B
[599303.881778] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:9:LVDS-1] probed modes :
[599303.881783] [drm:drm_mode_debug_printmodeline], Modeline 22:"1920x1080" 60 
144000 1920 2016 2080 2176 1080 1088 1092 1100 0x8 0xa
[599303.881791] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:12:DVI-D-1]
[599303.886292] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter 
intel drm HDMIB
[599303.886298] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:12:DVI-D-1] disconnected
[599303.886304] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:14:DP-1]
[599303.886811] [drm:cdv_intel_dp_aux_ch], dp_aux_ch timeout status 0x51440064
[599303.886815] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:14:DP-1] disconnected
[599303.886820] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:18:DVI-D-2]
[599303.891350] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter 
intel drm HDMIC
[599303.891357] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:18:DVI-D-2] disconnected
[599303.891362] [drm:drm_helper_probe_single_connector_modes], 
[CONNECTOR:20:DP-2]
[599303.891569] [drm:cdv_dp_detect], DPCD: Rev=11 LN_Rate=a LN_CNT=82 
LN_DOWNSP=41
[599303.891876] [drm:cdv_intel_dp_i2c_aux_ch], aux_i2c nack
[599303.892082] [drm:cdv_intel_dp_i2c_aux_ch], aux_i2c nack
[599303.892085] [drm:i2c_algo_dp_aux_xfer], dp_aux_xfer return -12

Re: [ANNOUNCE] s390 31 bit kernel support removal

[Michael Tokarev]

12.02.2014 13:29, Heiko Carstens wrote:
> We want to remove s390 31 bit kernel support with Linux kernel 3.16.

Maybe you can send a patch for Documentation/feature-removal-schedule.txt
about this now?

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

screen goes blank when loading gma500_gfx (atom D2500)

[Michael Tokarev]

Hello.

Today I rebooted my router into a new kernel and noticed that
the screen goes blank after booting the system (initial bootup
messages are visible).  After some debugging it turns out that
the screen goes blank when loading gma500_gfx module.

This is an intel D2500CC motherboard with Atom D5200 built-in,
with a monitor connected to a VGA port, the following vga device
is reported by lspci:

00:02.0 VGA compatible controller: Intel Corporation Atom Processor D2xxx/N2xxx 
Integrated Graphics Controller (rev 09)

Here are the dmesg output after loading gma500_gfx:

[  176.427071] Linux agpgart interface v0.103
[  176.452914] [drm] Initialized drm 1.1.0 20060810
[  176.476037] gma500 :00:02.0: setting latency timer to 64
[  176.476216] gma500 :00:02.0: irq 50 for MSI/MSI-X
[  176.491675] acpi device:29: registered as cooling_device2
[  176.492041] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[  176.492169] input: Video Bus as 
/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input11
[  176.492357] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[  176.492396] [drm] No driver support for vblank timestamp query.
[  176.607485] gma500 :00:02.0: trying to get vblank count for disabled 
pipe 1
[  176.607531] gma500 :00:02.0: trying to get vblank count for disabled 
pipe 1
[  176.806078] [drm] Initialized gma500 1.0.0 2011-06-06 for :00:02.0 on 
minor 0

which does not look bad or suspicious to me.

fbcon is loaded so it isn't an issue.

I tried 3.10 kernel initially (the above messages are from it), next
I tried 3.13 kernel too, and that one behaves exactly the same.

As far as I remember, this system never worked with graphics well.
Previous kernel (from which I updated) was 3.2 which had no
gma500 module (local build).

What are the steps to debug this further?

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

3.10.25 kernel behaves unstable as a qemu/kvm guest

[Michael Tokarev]

Hello.

This is just an initial/preliminary heads-up, maybe mis-directed, about
a possible issue.

I upgraded 2 machines today to 3.10.25, and both shows some.. strangeness
within linux guests, which are also running 3.10.25.  Revering to 3.10.24
in guests (compiled by the same compiler with the same options) or
using older qemu/kvm (running with 1.7 now) fixes it.

All guests are using virtio-net and virtio-blk.

On one machine (prod), one guest (also prod) loads okay, but the networking
is not functioning: no packets are received by the guest.  I weren't able
to debug this further at this time, so reverted back to an older qemu/kvm
(1.1).

On another machine (my home workstation where I can experiment), the same
combination (3.10.25 on host & guest and qemu 1.7) shows rather unstable
behavour: about every 1/2 boot it stalls somewhere at the initial boot,
either after initializing PNP, or initializing networking, or sometimes
after initializing virtio, and the rest 1/2 it boots okay.

When it stalls, it consumes no CPU, qemu process is responsive, the guest
just does nothing.  Like this:

 ...
 NET: Registering protocol family 2
 TCP: established hash table entries: 8192 (order: 5, 131072 bytes)
 TCP bind hash table entries: 8192 (order: 5, 131072 bytes)
 TCP: Hash tables configured (established 8192 bind 8192)
 TCP: reno registered
 [at this point it hanged]

(after this it normally registers UDP hash tables and other net stuff)

I'm not sure yet what's going on.  I understand that there are no guest-related
changes in 3.10.25 (compared with .24), so there should be something else.
The fact that it stalls randomly suggests there's some uninitialized value
somewhere.

I'll try to debug it further.  Just a heads-up for now.

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/10] autofs4 - rename autofs4 to autofs

[Michael Tokarev]

31.08.2013 15:42, Ian Kent wrote:
[...]
> By leaving a Kconfig and Makefile in fs/autofs4 (to build autofs4.ko)
> with a deprication message sub-system maintainers and other users will
> make any needed changes before these are removed after two kernel versions.
> IMHO the presence of the warning is reason enough to leave a build stub
> rather than do a straight out rename.

Why do you want to continue building autofs4.ko? (or allowing to)
What's actually wrong with a stright rename?
If the new module can be auto-loaded by both name (by providing an
alias), there's no need to keep ability to build autofs4.ko, I think.

Well, maybe except of the case when autofs is needed in initramfs (like
for systemd).  For this, indeed, you can keep autofs4.ko which is a
dummy depending on autofs.ko...

> Ian Kent (10):
>   autofs4 - coding style fixes
>   autofs4 - fix string.h include in auto_dev-ioctl.h
>   autofs4 - move linux/auto_dev-ioctl.h to uapi/linux
>   autofs - merge auto_fs.h and auto_fs4.h
>   autofs - use autofs instead of autofs4 everywhere
>   autofs - copy autofs4 to autofs
>   autofs - create autofs Kconfig and Makefile
>   autofs - update fs/autofs4/Kconfig
>   autofs - update fs/autofs4/Makefile
>   autofs - delete fs/autofs4

By doing it this way, you're losing all git history.
If you perform stright rename and git detects it, you
can use, eg, git log --follow to see whole hostory
across rename.  This way you create new files without
history.

So I strongly shuggest actually renaming the subdirectory
(together with appropriate kconfig/makefile changes so
things are bisectable), and creating the stubs after this.

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Very poor latency when using hard drive (raid1)

[Michael Tokarev]

15.04.2013 13:59, l...@tigusoft.pl пишет:
> There are 2 hard drives (normal, magnetic) in software raid 1
> on 3.2.41 kernel.
> 
> When I write into them e.g. using dd from /dev/zero to a local file
> (ext4 on default settings), running 2 dd at once (writing two files) it
> starves all other programs that try to use the disk.
> 
> Running ls on any directory on same disk (same fs btw), takes over half
> minute to execute, same for any other disk touching action.
> 
> Did anyone seen such problem, where too look, what to test?

This is typical, known for many years, issue.

Your dds are run against buffer cache, the same as used by all other
regular accesses.  So once it fills up, cached directories and the
like are thrown away to make room for new cache space.  So once
you need something else, that something needs to be read from disk,
which is busy together with the buffer cache.

> What could solve it (other then ionice on applications that I expect to
> use hard drive)?

Just don't mix these two workloads.  Or, if you really need to transfer
large amount of data, use direct I/O (O_DIRECT) -- for dd it is
iflag=direct or oflag=direct (depending on the I/O direction).

ionice wont help much.

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH linux-next] autofs4: autofs4_catatonic_mode(): remove redundant null check on kfree()

[Michael Tokarev]

13.02.2013 11:37, Ian Kent wrote:
[]

So, you would like me to forward this to Linus?

I'd be inclined to wait until the window for 3.9 opens since Linus
probably has more than enough to do finalizing 3.8 right now.


I guess this change is anything but urgent ;)

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH linux-next] autofs4: autofs4_catatonic_mode(): remove redundant null check on kfree()

[Michael Tokarev]

13.02.2013 11:20, Ian Kent wrote:

On Tue, 2013-02-12 at 10:12 -0700, Tim Gardner wrote:

smatch analysis:

fs/autofs4/waitq.c:46 autofs4_catatonic_mode() info: redundant null
  check on wq->name.name calling kfree()


I'm not sure about this change.

autofs4_catatonic_mode() could be called when there are remaining
entries in the wait queue, which is nulled, so autofs4_wait_release()
won't see the the discarded waits if it is called.


Ian, this is about something else really.  The patch is about the
NULL check before calling kfree() -- it does the NULL check internally.
It is nothing about code flow or anything else, it is about calling
kfree() unconditionally regardless whenever the argument is actually
NULL or non-NULL.  It makes the code shorter and easier to read.

You can add my

Signed-off-by: Michael Tokarev 

if you want.


Cc: Ian Kent 
Cc: aut...@vger.kernel.org
Signed-off-by: Tim Gardner 
---
  fs/autofs4/waitq.c |6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/autofs4/waitq.c b/fs/autofs4/waitq.c
index 03bc1d3..3db70da 100644
--- a/fs/autofs4/waitq.c
+++ b/fs/autofs4/waitq.c
@@ -42,10 +42,8 @@ void autofs4_catatonic_mode(struct autofs_sb_info *sbi)
while (wq) {
nwq = wq->next;
wq->status = -ENOENT; /* Magic is gone - report failure */
-   if (wq->name.name) {
-   kfree(wq->name.name);
-   wq->name.name = NULL;
-   }
+   kfree(wq->name.name);
+   wq->name.name = NULL;
wq->wait_ctr--;
wake_up_interruptible(&wq->queue);
wq = nwq;



--
To unsubscribe from this list: send the line "unsubscribe autofs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Transparent Huge Pages

[Michael Tokarev]

Hello.

I'm trying to understand how to use transparent huge pages
(currently in x86).  Before I used "explicit" huge pages
alot (mostly about hugetlbfs), but it looked like THP should
be easier so I gave it a try.

This tiny program:

- cut -
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char **argv) {
  void *ptr;
  size_t len = argv[1] ? atoi(argv[1]) : 1024*1024*1024;
  /* no error checking! */
  posix_memalign(&ptr, 2048*1024, len);
  madvise(ptr, len, MADV_HUGEPAGE);
  memset(ptr, 0, len);
  usleep(500); /* let khugepagesd do its work */
  system("grep ^AnonHugePages: /proc/meminfo");
  return 0;
}
- cut -

which just tries to allocate some amount of RAM (1Gb by default)
aligned to 2Mb, uses madvise(HUGEPAGE) on it, and checks
/proc/meminfo for AnonHugePages.

The problem is: I've never seen any value for AnonHugePages
larger than about 16Mb.  Usually it is around 10Mb or 8Mb,
no matter how large the requested memory size is, including
the default 1Gb.

The question, obviously, is: why so small?

My system (which is a few years old now) has 6Gb of RAM,
it uses AMD Athlon II X2 260 CPU, and is running 3.2
kernel.

Original question comes from grounds of of QEMU, which is
supposed to use THP for guest memory, but it also does not
use more than these ~10Mb, when allocating 1Gb to the guest.

Thanks!

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/11] x86/microcode: Early load microcode

[Michael Tokarev]

On 20.12.2012 23:48, Fenghua Yu wrote:
> From: Fenghua Yu 
> 
> The problem in current microcode loading method is that we load a microcode 
> way,
> way too late; ideally we should load it before turning paging on.  This may 
> only
> be practical on 32 bits since we can't get to 64-bit mode without paging on,
> but we should still do it as early as at all possible.

Why loading microcode this early is important?
Why it is bad to load it at the end of (initial) boot?

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git patches] libata fixes for 3.7

[Michael Tokarev]

On 02.10.2012 23:59, Jeff Garzik wrote:
> On 10/02/2012 03:44 PM, Michael Tokarev wrote:
>> On 02.10.2012 23:40, Jeff Garzik wrote:
>>
>>> Minor libata updates, nothing notable.
>>>
>>> 1) Apply -- and then revert -- the FUA feature.  Caused
>>> disk corruption in linux-next, proving it cannot be turned on by
>>> default.
>>
>> Any details on that?  Disk corruprion is rather a nasty
>> side-effect indeed.
> 
> One thread with reports is
> 
> Storage related regression in linux-next 20120824

Eg, https://lkml.org/lkml/2012/8/27/66 (two reports).
Thank you!

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git patches] libata fixes for 3.7

[Michael Tokarev]

On 02.10.2012 23:40, Jeff Garzik wrote:

> Minor libata updates, nothing notable.
> 
> 1) Apply -- and then revert -- the FUA feature.  Caused
>disk corruption in linux-next, proving it cannot be turned on by
>default.

Any details on that?  Disk corruprion is rather a nasty
side-effect indeed.

Thank you!

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: tg3 driver upgrade (Linux 2.6.32 -> 3.2) breaks IBM Bladecenter SoL

[Michael Tokarev]

On 02.10.2012 22:49, Ferenc Wagner wrote:
> "Michael Chan"  writes:
>> These are the likely fixes:
>>
>> commit cf9ecf4b631f649a964fa611f1a5e8874f2a76db 
>> Author: Matt Carlson 
>> Date: Mon Nov 28 09:41:03 2011 +
>>
>> tg3: Fix TSO CAP for 5704 devs w / ASF enabled
> 
> You are exactly right: cf9ecf4b fixed the premanent SoL breakage
> introduced by dabc5c67.  Looks like ASF utilizes similar technology to
> that of the HS20 BMC.  Thanks for the tip, it greatly reduced our CPU
> wear. :)  It's a pity ethtool -k did not give a hint.  Do you think it's
> possible to work around in 3.2 by eg. fiddling some ethtool setting?

Maybe it's better to push this commit to -stable instead? (the commit
that broke things is part of 3.0 kernel so all current 3.x -stable
kernels are affected)

(Besides, that commit "This patch fixes the problem by revisiting and
reevaluating the decision after tg3_get_eeprom_hw_cfg() is called." -
merely copies a somewhat "twisted" chunk of code into another place,
which does not look optimal)

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lve module taint?

[Michael Tokarev]

On 19.09.2012 06:02, Rusty Russell wrote:

> From: Matthew Garrett 
> Subject: module: taint kernel when lve module is loaded
> Date: Fri, 22 Jun 2012 13:49:31 -0400
> 
> Cloudlinux have a product called lve that includes a kernel module. This
> was previously GPLed but is now under a proprietary license, but the
> module continues to declare MODULE_LICENSE("GPL") and makes use of some
> EXPORT_SYMBOL_GPL symbols. Forcibly taint it in order to avoid this.

> + /* lve claims to be GPL but upstream won't provide source */
> + if (strcmp(mod->name, "lve") == 0)
> + add_taint_module(mod, TAINT_PROPRIETARY_MODULE);

This is setting a, in my opinion, rather bad precedent.  Next we'll
be adding various modules here due to various reasons.

I think this case should be pure political now, not technical.  Ie,
if some project declares itself as GPL, it is not kernel task to
verify that the sources are available or to enforce that.

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Qemu-devel] x86, nops settings result in kernel crash

[Michael Tokarev]

On 20.08.2012 21:13, Tomas Racek wrote:
[]
Can we trim the old, large and now not-so-relevant discussion please? ;)

> I can provide you with more different traces if it can help. But I thought 
> that maybe it will be more useful for you to try it on your own. So I've 
> prepared some minimal debian installation which you could download here (apx 
> 163M bzipped):
> 
> http://fi.muni.cz/~xracek/debian.img.bz2
> 
> Password:
> root/asdfgh
> 
> Here is my config for guest kernel:
> 
> http://fi.muni.cz/~xracek/config
> 
> I use
> 
> qemu-kvm -m 1500 -hda debian.img -kernel linux/arch/x86/boot/bzImage -append 
> "root=/dev/sda1"

Um.  I'd expect the image to be self-contained, no external kernel.
I wanted to do a quick test to see if it fails on my machine too,
d/loaded debian.img.bz2 but there's no kernel.  So.. no quick test
for you ;)

> After logging in just run "sh runtest.sh". This leads to crash in my case 
> (host: Intel Core i5-2540M, kernel 3.5.2-1.fc17.x86_64, qemu 1.0.1).

With all the above, this "runtest.sh" is informationally equal to
your disk image.

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: root=PARTUUID for MBR/NT disk signatures?

[Michael Tokarev]

On 21.08.2012 08:47, Will Drewry wrote:
[]
> Functionally, I suspect this will work fine, but I am concerned that
> it is a bad move from an efficiency perspective (not unfixable
> though).  Right now, the user-supplied value is converted from
> string-uuid to packed-uuid.  This is then memcmp'd across any and all
> partitions - be it 2 or 200 - across all attached storage.  If we move
> to a pure string, then we end up needing to unpack every packed UUID
> at disk scan time (or search, depending on impl) rather than just the
> one user supplied value.
> 
> Perhaps the cost is negligible on modern machines, but it seems like
> the wrong place to put the cost (per entry rather than per search
> value).

Amount of work needed to READ all the partition tables might be
quite a bit larger than strcmp'ing it all.  I think.

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.0+ NFS issues (bisected)

[Michael Tokarev]

On 18.08.2012 15:13, J. Bruce Fields wrote:
> On Sat, Aug 18, 2012 at 10:49:31AM +0400, Michael Tokarev wrote:
[]
>> Well.  What can I say?  With the change below applied (to 3.2 kernel
>> at least), I don't see any stalls or high CPU usage on the server
>> anymore.  It survived several multi-gigabyte transfers, for several
>> hours, without any problem.  So it is a good step forward ;)
>>
>> But the whole thing seems to be quite a bit fragile.  I tried to follow
>> the logic in there, and the thing is quite a bit, well, "twisted", and
>> somewhat difficult to follow.  So I don't know if this is the right
>> fix or not.  At least it works! :)
> 
> Suggestions welcomed.

Ok...

Meanwhile, you can add my
Tested-By: Michael Tokarev 

to the patch.

>> And I really wonder why no one else reported this problem before.
>> Is me the only one in this world who uses linux nfsd? :)
> 
> This, for example:
> 
>   http://marc.info/?l=linux-nfs&m=134131915612287&w=2
> 
> may well describe the same problem  It just needed some debugging
> persistence, thanks!

Ah.  I tried to find something when I initially
sent this report, but weren't able to.  Apparently
I'm not alone with this problem indeed!

Thank you for all the work!

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.0+ NFS issues (bisected)

[Michael Tokarev]

On 18.08.2012 02:32, J. Bruce Fields wrote:
> On Fri, Aug 17, 2012 at 04:08:07PM -0400, J. Bruce Fields wrote:
>> Wait a minute, that assumption's a problem because that calculation
>> depends in part on xpt_reserved, which is changed here
>>
>> In particular, svc_xprt_release() calls svc_reserve(rqstp, 0), which
>> subtracts rqstp->rq_reserved and then calls svc_xprt_enqueue, now with a
>> lower xpt_reserved value.  That could well explain this.
> 
> So, maybe something like this?

Well.  What can I say?  With the change below applied (to 3.2 kernel
at least), I don't see any stalls or high CPU usage on the server
anymore.  It survived several multi-gigabyte transfers, for several
hours, without any problem.  So it is a good step forward ;)

But the whole thing seems to be quite a bit fragile.  I tried to follow
the logic in there, and the thing is quite a bit, well, "twisted", and
somewhat difficult to follow.  So I don't know if this is the right
fix or not.  At least it works! :)

And I really wonder why no one else reported this problem before.
Is me the only one in this world who uses linux nfsd? :)

Thank you for all your patience and the proposed fix!

/mjt

> commit c8136c319ad85d0db870021fc3f9074d37f26d4a
> Author: J. Bruce Fields 
> Date:   Fri Aug 17 17:31:53 2012 -0400
> 
> svcrpc: don't add to xpt_reserved till we receive
> 
> The rpc server tries to ensure that there will be room to send a reply
> before it receives a request.
> 
> It does this by tracking, in xpt_reserved, an upper bound on the total
> size of the replies that is has already committed to for the socket.
> 
> Currently it is adding in the estimate for a new reply *before* it
> checks whether there is space available.  If it finds that there is not
> space, it then subtracts the estimate back out.
> 
> This may lead the subsequent svc_xprt_enqueue to decide that there is
> space after all.
> 
> The results is a svc_recv() that will repeatedly return -EAGAIN, causing
> server threads to loop without doing any actual work.
> 
> Reported-by: Michael Tokarev 
> Signed-off-by: J. Bruce Fields 
> 
> diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
> index ec99849a..59ff3a3 100644
> --- a/net/sunrpc/svc_xprt.c
> +++ b/net/sunrpc/svc_xprt.c
> @@ -366,8 +366,6 @@ void svc_xprt_enqueue(struct svc_xprt *xprt)
>   rqstp, rqstp->rq_xprt);
>   rqstp->rq_xprt = xprt;
>   svc_xprt_get(xprt);
> - rqstp->rq_reserved = serv->sv_max_mesg;
> - atomic_add(rqstp->rq_reserved, &xprt->xpt_reserved);
>   pool->sp_stats.threads_woken++;
>   wake_up(&rqstp->rq_wait);
>   } else {
> @@ -644,8 +642,6 @@ int svc_recv(struct svc_rqst *rqstp, long timeout)
>   if (xprt) {
>   rqstp->rq_xprt = xprt;
>   svc_xprt_get(xprt);
> - rqstp->rq_reserved = serv->sv_max_mesg;
> - atomic_add(rqstp->rq_reserved, &xprt->xpt_reserved);
>  
>   /* As there is a shortage of threads and this request
>* had to be queued, don't allow the thread to wait so
> @@ -743,6 +739,10 @@ int svc_recv(struct svc_rqst *rqstp, long timeout)
>   len = xprt->xpt_ops->xpo_recvfrom(rqstp);
>   dprintk("svc: got len=%d\n", len);
>   }
> + if (len > 0) {
> + rqstp->rq_reserved = serv->sv_max_mesg;
> + atomic_add(rqstp->rq_reserved, &xprt->xpt_reserved);
> + }
>   svc_xprt_received(xprt);
>  
>   /* No data, incomplete (TCP) read, or accept() */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.0+ NFS issues (bisected)

[Michael Tokarev]

On 17.08.2012 21:26, Michael Tokarev wrote:
> On 17.08.2012 21:18, J. Bruce Fields wrote:
>> On Fri, Aug 17, 2012 at 09:12:38PM +0400, Michael Tokarev wrote:
> []
>>> So we're calling svc_recv in a tight loop, eating
>>> all available CPU.  (The above is with just 2 nfsd
>>> threads).
>>>
>>> Something is definitely wrong here.  And it happens mure more
>>> often after the mentioned commit (f03d78db65085).
>>
>> Oh, neat.  Hm.  That commit doesn't really sound like the cause, then.
>> Is that busy-looping reproduceable on kernels before that commit?
> 
> Note I bisected this issue to this commit.  I haven't seen it
> happening before this commit, and reverting it from 3.0 or 3.2
> kernel makes the problem to go away.
> 
> I guess it is looping there:
> 
> 
> net/sunrpc/svc_xprt.c:svc_recv()
> ...
> len = 0;
> ...
> if (test_bit(XPT_LISTENER, &xprt->xpt_flags)) {
> ...
> } else if (xprt->xpt_ops->xpo_has_wspace(xprt)) {  <=== here -- has 
> no wspace due to memory...
> ...  len = 
> }
> 
> /* No data, incomplete (TCP) read, or accept() */
> if (len == 0 || len == -EAGAIN)
> goto out;
> ...
> out:
> rqstp->rq_res.len = 0;
> svc_xprt_release(rqstp);
> return -EAGAIN;
> }
> 
> I'm trying to verify this theory...

Yes.  I inserted a printk there, and all these million times while
we're waiting in this EAGAIN loop, this printk is triggering:


[21052.533053]  svc_recv: !has_wspace
[21052.533070]  svc_recv: !has_wspace
[21052.533087]  svc_recv: !has_wspace
[21052.533105]  svc_recv: !has_wspace
[21052.533122]  svc_recv: !has_wspace
[21052.533139]  svc_recv: !has_wspace
[21052.533156]  svc_recv: !has_wspace
[21052.533174]  svc_recv: !has_wspace
[21052.533191]  svc_recv: !has_wspace
[21052.533208]  svc_recv: !has_wspace
[21052.533226]  svc_recv: !has_wspace
[21052.533244]  svc_recv: !has_wspace
[21052.533265] calling svc_recv: 1228163 times (err=-4)
[21052.533403] calling svc_recv: 1226616 times (err=-4)
[21052.534520] nfsd: last server has exited, flushing export cache

(I stopped nfsd since it was flooding the log).

I can only guess that before that commit, we always had space,
now we don't anymore, and are looping like crazy.

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.0+ NFS issues (bisected)

[Michael Tokarev]

On 17.08.2012 21:18, J. Bruce Fields wrote:
> On Fri, Aug 17, 2012 at 09:12:38PM +0400, Michael Tokarev wrote:
[]
>> So we're calling svc_recv in a tight loop, eating
>> all available CPU.  (The above is with just 2 nfsd
>> threads).
>>
>> Something is definitely wrong here.  And it happens mure more
>> often after the mentioned commit (f03d78db65085).
> 
> Oh, neat.  Hm.  That commit doesn't really sound like the cause, then.
> Is that busy-looping reproduceable on kernels before that commit?

Note I bisected this issue to this commit.  I haven't seen it
happening before this commit, and reverting it from 3.0 or 3.2
kernel makes the problem to go away.

I guess it is looping there:


net/sunrpc/svc_xprt.c:svc_recv()
...
len = 0;
...
if (test_bit(XPT_LISTENER, &xprt->xpt_flags)) {
...
} else if (xprt->xpt_ops->xpo_has_wspace(xprt)) {  <=== here -- has no 
wspace due to memory...
...  len = 
}

/* No data, incomplete (TCP) read, or accept() */
if (len == 0 || len == -EAGAIN)
goto out;
...
out:
rqstp->rq_res.len = 0;
svc_xprt_release(rqstp);
return -EAGAIN;
}

I'm trying to verify this theory...

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.0+ NFS issues (bisected)

[Michael Tokarev]

On 17.08.2012 20:00, J. Bruce Fields wrote:
[]> Uh, if I grepped my way through this right: it looks like it's the
> "memory" column of the "TCP" row of /proc/net/protocols; might be
> interesting to see how that's changing over time.

This file does not look interesting.  Memory usage does not jump,
there's no high increase either.

But there's something else which is interesting here.

I noticed that in perf top, the top consumer of CPU is svc_recv()
(I mentioned this in the start of this thread).  So I looked how
this routine is called from nfsd.  And here we go.

fs/nfsd/nfssvc.c:

/*
 * This is the NFS server kernel thread
 */
static int
nfsd(void *vrqstp)
{
...
/*
 * The main request loop
 */
for (;;) {
/*
 * Find a socket with data available and call its
 * recvfrom routine.
 */
int i = 0;
while ((err = svc_recv(rqstp, 60*60*HZ)) == -EAGAIN)
++i;
printk(KERN_ERR "calling svc_recv: %d times (err=%d)\n", i, err);
if (err == -EINTR)
break;
...

(I added the "i" counter and the printk).  And here's the output:

[19626.401136] calling svc_recv: 0 times (err=212)
[19626.405059] calling svc_recv: 1478 times (err=212)
[19626.409512] calling svc_recv: 1106 times (err=212)
[19626.543020] calling svc_recv: 0 times (err=212)
[19626.543059] calling svc_recv: 0 times (err=212)
[19626.548074] calling svc_recv: 0 times (err=212)
[19626.549515] calling svc_recv: 0 times (err=212)
[19626.552320] calling svc_recv: 0 times (err=212)
[19626.553503] calling svc_recv: 0 times (err=212)
[19626.556007] calling svc_recv: 0 times (err=212)
[19626.557152] calling svc_recv: 0 times (err=212)
[19626.560109] calling svc_recv: 0 times (err=212)
[19626.560943] calling svc_recv: 0 times (err=212)
[19626.565315] calling svc_recv: 1067 times (err=212)
[19626.569735] calling svc_recv: 2571 times (err=212)
[19626.574150] calling svc_recv: 3842 times (err=212)
[19626.581914] calling svc_recv: 2891 times (err=212)
[19626.583072] calling svc_recv: 1247 times (err=212)
[19626.616885] calling svc_recv: 0 times (err=212)
[19626.616952] calling svc_recv: 0 times (err=212)
[19626.622889] calling svc_recv: 0 times (err=212)
[19626.624518] calling svc_recv: 0 times (err=212)
[19626.627118] calling svc_recv: 0 times (err=212)
[19626.629735] calling svc_recv: 0 times (err=212)
[19626.631777] calling svc_recv: 0 times (err=212)
[19626.633986] calling svc_recv: 0 times (err=212)
[19626.636746] calling svc_recv: 0 times (err=212)
[19626.637692] calling svc_recv: 0 times (err=212)
[19626.640769] calling svc_recv: 0 times (err=212)
[19626.657852] calling svc_recv: 0 times (err=212)
[19626.661602] calling svc_recv: 0 times (err=212)
[19626.670160] calling svc_recv: 0 times (err=212)
[19626.671917] calling svc_recv: 0 times (err=212)
[19626.684643] calling svc_recv: 0 times (err=212)
[19626.684680] calling svc_recv: 0 times (err=212)
[19626.812820] calling svc_recv: 0 times (err=212)
[19626.814697] calling svc_recv: 0 times (err=212)
[19626.817195] calling svc_recv: 0 times (err=212)
[19626.820324] calling svc_recv: 0 times (err=212)
[19626.822855] calling svc_recv: 0 times (err=212)
[19626.824823] calling svc_recv: 0 times (err=212)
[19626.828016] calling svc_recv: 0 times (err=212)
[19626.829021] calling svc_recv: 0 times (err=212)
[19626.831970] calling svc_recv: 0 times (err=212)

> the stall begin:
[19686.823135] calling svc_recv: 3670352 times (err=212)
[19686.823524] calling svc_recv: 3659205 times (err=212)

> transfer continues
[19686.854734] calling svc_recv: 0 times (err=212)
[19686.860023] calling svc_recv: 0 times (err=212)
[19686.887124] calling svc_recv: 0 times (err=212)
[19686.895532] calling svc_recv: 0 times (err=212)
[19686.903667] calling svc_recv: 0 times (err=212)
[19686.922780] calling svc_recv: 0 times (err=212)

So we're calling svc_recv in a tight loop, eating
all available CPU.  (The above is with just 2 nfsd
threads).

Something is definitely wrong here.  And it happens mure more
often after the mentioned commit (f03d78db65085).

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.0+ NFS issues (bisected)

[Michael Tokarev]

On 12.07.2012 16:53, J. Bruce Fields wrote:
> On Tue, Jul 10, 2012 at 04:52:03PM +0400, Michael Tokarev wrote:
>> I tried to debug this again, maybe to reproduce in a virtual machine,
>> and found out that it is only 32bit server code shows this issue:
>> after updating the kernel on the server to 64bit (the same version)
>> I can't reproduce this issue anymore.  Rebooting back to 32bit,
>> and voila, it is here again.
>>
>> Something apparenlty isn't right on 32bits... ;)
>>
>> (And yes, the prob is still present and is very annoying :)
> 
> OK, that's very useful, thanks.  So probably a bug got introduced in the
> 32-bit case between 2.6.32 and 3.0.
> 
> My personal upstream testing is normally all x86_64 only.  I'll kick off
> a 32-bit install and see if I can reproduce this quickly.

Actually it has nothing to do with 32 vs 64 bits as I
initially thought.  It happens on 64bits too, but takes
more time (or data to transfer) to trigger.


> Let me know if you're able to narrow this down any more.

I bisected this issue to the following commit:

commit f03d78db65085609938fdb686238867e65003181
Author: Eric Dumazet 
Date:   Thu Jul 7 00:27:05 2011 -0700

net: refine {udp|tcp|sctp}_mem limits

Current tcp/udp/sctp global memory limits are not taking into account
hugepages allocations, and allow 50% of ram to be used by buffers of a
single protocol [ not counting space used by sockets / inodes ...]

Lets use nr_free_buffer_pages() and allow a default of 1/8 of kernel ram
per protocol, and a minimum of 128 pages.
Heavy duty machines sysadmins probably need to tweak limits anyway.


Reverting this commit on top of 3.0 (or any later 3.x kernel) fixes
the behavour here.

This machine has 4Gb of memory.  On 3.0, with this patch applied
(as it is part of 3.0), tcp_mem is like this:

  21228 28306   42456

with this patch reverted, tcp_mem shows:

  81216 108288  162432

and with these values, it works fine.

So it looks like something else goes wrong there,
which lead to all nfsds fighting with each other
for something and eating 100% of available CPU
instead of servicing clients.

For added fun, when setting tcp_mem to the "good" value
from "bad" value (after booting into kernel with that
patch applied), the problem is _not_ fixed.

Any further hints?

Thanks,

/mjt

>> On 31.05.2012 17:51, Michael Tokarev wrote:
>>> On 31.05.2012 17:46, Myklebust, Trond wrote:
>>>> On Thu, 2012-05-31 at 17:24 +0400, Michael Tokarev wrote:
>>> []
>>>>> I started tcpdump:
>>>>>
>>>>>  tcpdump -npvi br0 -s 0 host 192.168.88.4 and \( proto ICMP or port 2049 
>>>>> \) -w nfsdump
>>>>>
>>>>> on the client (192.168.88.2).  Next I mounted a directory on the client,
>>>>> and started reading (tar'ing) a directory into /dev/null.  It captured a
>>>>> few stalls.  Tcpdump shows number of packets it got, the stalls are at
>>>>> packet counts 58090, 97069 and 97071.  I cancelled the capture after that.
>>>>>
>>>>> The resulting file is available at 
>>>>> http://www.corpit.ru/mjt/tmp/nfsdump.xz ,
>>>>> it is 220Mb uncompressed and 1.3Mb compressed.  The source files are
>>>>> 10 files of 1Gb each, all made by using `truncate' utility, so does not
>>>>> take place on disk at all.  This also makes it obvious that the issue
>>>>> does not depend on the speed of disk on the server (since in this case,
>>>>> the server disk isn't even in use).
>>>>
>>>> OK. So from the above file it looks as if the traffic is mainly READ
>>>> requests.
>>>
>>> The issue here happens only with reads.
>>>
>>>> In 2 places the server stops responding. In both cases, the client seems
>>>> to be sending a single TCP frame containing several COMPOUNDS containing
>>>> READ requests (which should be legal) just prior to the hang. When the
>>>> server doesn't respond, the client pings it with a RENEW, before it ends
>>>> up severing the TCP connection and then retransmitting.
>>>
>>> And sometimes -- speaking only from the behavour I've seen, not from the
>>> actual frames sent -- server does not respond to the RENEW too, in which
>>> case the client reports "nfs server no responding", and on the next
>>> renew it may actually respond.  This happens too, but much more rare.
>>>
>>> During these stalls, ie, when there's no network activity at all,
>>> the server NFSD threads are busy eating all availa

Re: [PATCH] block: Don't use static to define "void *p" in show_partition_start().

[Michael Tokarev]

On 03.08.2012 12:41, Jens Axboe wrote:
> On 08/03/2012 07:07 AM, majianpeng wrote:
[]
>> diff --git a/block/genhd.c b/block/genhd.c
>> index cac7366..d839723 100644
>> --- a/block/genhd.c
>> +++ b/block/genhd.c
>> @@ -835,7 +835,7 @@ static void disk_seqf_stop(struct seq_file *seqf, void 
>> *v)
>>  
>>  static void *show_partition_start(struct seq_file *seqf, loff_t *pos)
>>  {
>> -static void *p;
>> +void *p;
>>  
>>  p = disk_seqf_start(seqf, pos);
>>  if (!IS_ERR_OR_NULL(p) && !*pos)
> 
> Huh, that looks like a clear bug. I've applied it, thanks.

It also looks like a -stable material, don't you think?

Thanks,

/mjt

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.5-rcX : Big problem with root device returning

[Michael Tokarev]

On 15.07.2012 23:12, werner wrote:

> Even if rdev isn't often used, it should kept working, as it's included in 
> many other programs, and principally in the installers.

rdev doesn't _exist_ anymore in current software,
including installers.

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.5-rcX : Big problem with root device returning

[Michael Tokarev]

On 12.07.2012 16:08, werner wrote:
> There is a big problem since 3.5-rc1 which potentially mess the installations
> 
> rdev   don't give longer back the root device like /dev/sda1  , but in the 
> bios form like 0x80010300

Note rdev returns information which is written to kernel image, not
information about actual device the system booted from.

> rdev is essential for the installation programs  and for the installation 
> f.ex. of lilo .   It's not conveniente to rely on the bios numbers, because 
> on some meinbords they change depending which boot order you select in BIOS, 
> or only if you select another boot device in the bios boot menu with F12.   
> Whilst /dev/sdXY is more reliable.
> 
>   rdev is an old basical function which always worked correctly, until now.

rdev utility is obsolete, it is not present in current util-linux anymore,
because it makes just no sense nowadays.  Storing root device in the
kernel image has been obsoleted long ago by boot loaders providing
kernel command line and root= parameter.  More, root device is often
not mounted by kernel itself, but by initramfs (which become an integral
part of the kernel image).

It is obsolete because of 3 reasons:

1) you've kernel command line from the bootloader to store this and
  other info
2) it is not guaranteed that the next reboot the same device will be
 using the same /dev/sdX node, since they're discovered dynamically
 (in this sense, bios codes are more reliable, and filesystem UUIDs or
 labels are the right way to go)
3) static device numbers are slowly going away too, very few tools
 left which knows about particular major,minor pairs.

> The error starts with 3.5-rc1 and is not corrected until 3.5-rc6 .If I go 
> back to an earlier kernel, 3.4 or older, then the same installation works 
> correct (rdev gives /dev/sda1 ) and if I go back then again to 3.5-rcX it's 
> again wrong (rdev gives 0x80010300).Thus, this seems a wrong manner how 
> the kernel gives back the root device,  or interact with rdev.  It's also 
> possible that this problem happens only under any kernel compilation option,  
>  so that below I give the differences in config between 3.4 and 3.5-rc1
> 
> This problem should be fixed most quickly,  rdev always have to work 
> correctly.

There's no problem, so nothing to fix.

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] core-kernel: use multiply instead of shifts in hash_64

[Michael Tokarev]

On 03.07.2012 00:25, Andrew Hunter wrote:
> diff --git a/include/linux/hash.h b/include/linux/hash.h
> index b80506b..daabc3d 100644
> --- a/include/linux/hash.h
> +++ b/include/linux/hash.h
> @@ -34,7 +34,9 @@
>  static inline u64 hash_64(u64 val, unsigned int bits)
>  {
>   u64 hash = val;
> -
> +#if BITS_PER_LONG == 64
> + hash *= GOLDEN_RATIO_PRIME_64;
> +#else
>   /*  Sigh, gcc can't optimise this alone like it does for 32 bits. */

Hmm.  Does this comment make sense here now?

Thanks,

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.0+ NFS issues

[Michael Tokarev]

I tried to debug this again, maybe to reproduce in a virtual machine,
and found out that it is only 32bit server code shows this issue:
after updating the kernel on the server to 64bit (the same version)
I can't reproduce this issue anymore.  Rebooting back to 32bit,
and voila, it is here again.

Something apparenlty isn't right on 32bits... ;)

(And yes, the prob is still present and is very annoying :)

Thanks,

/mjt


On 31.05.2012 17:51, Michael Tokarev wrote:
> On 31.05.2012 17:46, Myklebust, Trond wrote:
>> On Thu, 2012-05-31 at 17:24 +0400, Michael Tokarev wrote:
> []
>>> I started tcpdump:
>>>
>>>  tcpdump -npvi br0 -s 0 host 192.168.88.4 and \( proto ICMP or port 2049 \) 
>>> -w nfsdump
>>>
>>> on the client (192.168.88.2).  Next I mounted a directory on the client,
>>> and started reading (tar'ing) a directory into /dev/null.  It captured a
>>> few stalls.  Tcpdump shows number of packets it got, the stalls are at
>>> packet counts 58090, 97069 and 97071.  I cancelled the capture after that.
>>>
>>> The resulting file is available at http://www.corpit.ru/mjt/tmp/nfsdump.xz ,
>>> it is 220Mb uncompressed and 1.3Mb compressed.  The source files are
>>> 10 files of 1Gb each, all made by using `truncate' utility, so does not
>>> take place on disk at all.  This also makes it obvious that the issue
>>> does not depend on the speed of disk on the server (since in this case,
>>> the server disk isn't even in use).
>>
>> OK. So from the above file it looks as if the traffic is mainly READ
>> requests.
> 
> The issue here happens only with reads.
> 
>> In 2 places the server stops responding. In both cases, the client seems
>> to be sending a single TCP frame containing several COMPOUNDS containing
>> READ requests (which should be legal) just prior to the hang. When the
>> server doesn't respond, the client pings it with a RENEW, before it ends
>> up severing the TCP connection and then retransmitting.
> 
> And sometimes -- speaking only from the behavour I've seen, not from the
> actual frames sent -- server does not respond to the RENEW too, in which
> case the client reports "nfs server no responding", and on the next
> renew it may actually respond.  This happens too, but much more rare.
> 
> During these stalls, ie, when there's no network activity at all,
> the server NFSD threads are busy eating all available CPU.
> 
> What does it all tell us? :)
> 
> Thank you!
> 
> /mjt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dm-devel] Re: [PATCH] Implement barrier support for single device DM devices

[Michael Tokarev]

Jeremy Higdon wrote:
[]
> I'll put it even more strongly.  My experience is that disabling write
> cache plus disabling barriers is often much faster than enabling both
> barriers and write cache enabled, when doing metadata intensive
> operations, as long as you have a drive that is good at CTQ/NCQ.

Now, and it's VERY interesting at least for me (and is off-topic in
this thread) -- which drive(s) are good at NCQ?  I tried numerous SATA
(NCQ is about sata, right? :) drives, but NCQ either does nothing in
terms of performance or hurts.  Yesterday we ordered another drive
from Hitachi (their "raid edition" thing), -- will try it tomorrow,
but I've no hope here as it's some 5th or 6th model/brand already.

(Ol'good SCSI drives, even 10 years old, shows large difference when
TCQ is enabled...)

Thanks!
--
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: [dm-devel] Re: [PATCH] Implement barrier support for single device DM devices

[Michael Tokarev]

Ric Wheeler wrote:
> Alasdair G Kergon wrote:
>> On Fri, Feb 15, 2008 at 03:20:10PM +0100, Andi Kleen wrote:
>>> On Fri, Feb 15, 2008 at 04:07:54PM +0300, Michael Tokarev wrote:
>>>> I wonder if it's worth the effort to try to implement this.
>>
>> My personal view (which seems to be in the minority) is that it's a
>> waste of our development time *except* in the (rare?) cases similar to
>> the ones Andi is talking about.
> 
> Using working barriers is important for normal users when you really
> care about data loss and have normal drives in a box. We do power fail
> testing on boxes (with reiserfs and ext3) and can definitely see a lot
> of file system corruption eliminated over power failures when barriers
> are enabled properly.
> 
> It is not unreasonable for some machines to disable barriers to get a
> performance boost, but I would not do that when you are storing things
> you really need back.

The talk here is about something different - about supporting barriers
on md/dm devices, i.e., on pseudo-devices which uses multiple real devices
as components (software RAIDs etc).  In this "world" it's nearly impossible
to support barriers if there are more than one underlying component device,
barriers only works if there's only one component.  And the talk is about
supporting barriers only in "minority" of cases - mostly for simplest
device-mapper case only, NOT covering any raid1 or other "fancy" configurations.

> Of course, you don't need barriers when you either disable the write
> cache on the drives or use a battery backed RAID array which gives you a
> write cache that will survive power outages...

Two things here.

First, I still don't understand why in God's sake barriers are "working"
while regular cache flushes are not.  Almost no consumer-grade hard drive
supports write barriers, but they all support regular cache flushes, and
the latter should be enough (while not the most speed-optimal) to ensure
data safety.  Why to require write cache disable (like in XFS FAQ) instead
of going the flush-cache-when-appropriate (as opposed to write-barrier-
when-appropriate) way?

And second, "surprisingly", battery-backed RAID write caches tends to fail
too, sometimes... ;)  Usually, such a battery is enough to keep the data
in memory for several hours only (sine many RAID controllers uses regular
RAM for memory caches, which requires some power to keep its state), --
I come across this issue the hard way, and realized that only very few
persons around me who manages raid systems even knows about this problem -
that the battery-backed cache is only for some time...  For example,
power failed at evening, and by tomorrow morning, batteries are empty
already.  Or, with better batteries, think about a weekend... ;)
(I've seen some vendors now uses flash-based backing store for caches
instead, which should ensure far better results here).

/mjt
--
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.24: RPC: bad TCP reclen 0x00020090 (large)

[Michael Tokarev]

Andrew Morton wrote:
> (suitable cc added)

Thanks.  I was meant to sent it to linux-nfs originally, but
looks like i mistyped the address.

> (regression)

Now, after we did some more experiments with it, I don't think it's
a regression.  I'll post a bit more details in a few hours when the
ongoing testing finishes.  Thanks!

/mjt
--
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: Spurious completions during NCQ

[Michael Tokarev]

Hugo Mills wrote:
> On Fri, Feb 15, 2008 at 10:00:00AM -0500, Calvin Walton wrote:
>> On Fri, 2008-02-15 at 13:46 +, Hugo Mills wrote:
>>> I'm getting these on my Dell Latitude D830:
>>>
>>> Feb 15 13:06:00 willow kernel: ata1.00: exception Emask 0x2 SAct 0x4 SErr 
>>> 0x0 action 0x2 frozen
>>> Feb 15 13:06:00 willow kernel: ata1.00: spurious completions during NCQ 
>>> issue=0x0 SAct=0x4 FIS=004040a1:0002
>>>In some cases, there are several cmd/res lines listed. It's
>>> happening about once an hour or so (not correlated with any other
>>> event that I can see). It doesn't seem to be affecting operation of
>>> the machine, but it's making me nervous.

JFYI: Most probably it is correlated with smartd asking
the device for it's SMART status.

/mjt
--
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] quota: Turn quotas off when remounting read-only

[Michael Tokarev]

Jan Engelhardt wrote:
> On Feb 11 2008 13:39, Jan Kara wrote:
>>> But...  I'm thinking about this scenario:
>>>
>>>  # mount /data
>>>  # quotaon /data
>>>  (some maintenance stuff to be planned)
>>>  # mount -o remount,ro /data
>>>  (do backup etc)
>>>  # mount -r remount,rw /data
>>>
>>> at this point, it's expected that quota on /data is enabled.
>>> After this patch, it's not anymore...
>>  Yes, it previously accidentally worked this way (for an year or so,
>> before that we refused to remount read-only). Hmm, but maybe we could
>> somehow tweak quotas to be turned on when remounting read-write again.
>> We have all the information we need at the time of remounting read-only
>> so we could store it and use it later when remounting read-write. I'll have
>> a look into that.
> 
> Maybe it is possible to leave quota on all times, so that the
> reporting quota ioctls continue to work even in ro mode?

Well, that'd be the best approach imho (plus check if all
ioctls which try to modify quotas fails with EROFS as
appropriate).

But the problem really is that it's unknown at this time
where it fails in the first place.  I can't reproduce my
hang "on demand" (mount-ro followed with umount when quotas
are turned on, with ext3fs - umount never finishes), yet
it has biten me for several times already.  So it must be
something rare, some small race maybe, which is difficult
to find...  Yet it finds itself at the most inappropriate
moment. ;)  I already learned to turn the quota off before
doing something with a filesystem, but sometimes I'm
forgetting this, and the result is always the same... ;)
Oh well.

/mjt
--
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] Implement barrier support for single device DM devices

[Michael Tokarev]

Alasdair G Kergon wrote:
> On Fri, Feb 15, 2008 at 01:08:21PM +0100, Andi Kleen wrote:
>> Implement barrier support for single device DM devices
>  
> Thanks.  We've got some (more-invasive) dm patches in the works that
> attempt to use flushing to emulate barriers where we can't just
> pass them down like that.

I wonder if it's worth the effort to try to implement this.

As far as I understand (*), if a filesystem realizes that the
underlying block device does not support barriers, it will
switch to using regular flushes instead - isn't it the same
thing as you're trying to do on an MD level?

Note that a filesystem must understand barriers/flushes on
underlying block device, since many disk drives don't support
barriers anyway.

(*) this is, in fact, an interesting question.  I still can't
find complete information about this.  For example, how safe
xfs is if barriers are not supported or turned off?  Is it
"less safe" than with barriers?  Will it use regular cache
flushes if barriers are not here?  Ditto for ext3fs, but
here, barriers are not enabled by default.

/mjt
--
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/

2.6.24: RPC: bad TCP reclen 0x00020090 (large)

[Michael Tokarev]

Hello!

After upgrading to 2.6.24 (from .23), we're seeing ALOT
of messages like in $subj in dmesg:

Feb 13 13:21:39 paltus kernel: RPC: bad TCP reclen 0x00020090 (large)
Feb 13 13:21:46 paltus kernel: printk: 3586 messages suppressed.
Feb 13 13:21:46 paltus kernel: RPC: bad TCP reclen 0x00020090 (large)
Feb 13 13:21:49 paltus kernel: printk: 371 messages suppressed.
Feb 13 13:21:49 paltus kernel: RPC: bad TCP reclen 0x00020090 (large)
Feb 13 13:21:55 paltus kernel: printk: 2979 messages suppressed.
...

with linux NFS server.  The clients are all linux too, mostly 2.6.23
and some 2.6.22.

I found the "offending" piece of code in net/sunrpc/svcsock.c,
in routine svc_tcp_recvfrom() with condition being:

   if (svsk->sk_reclen > serv->sv_max_mesg) ...

This happens after a server reboot.  At this point, client(s) are trying
to perform some NFS transaction and fail, and server starts generating
the above messages - till I do a umount followed by mount on all clients.
Before, such situation (nfs server reboot) were handled transparently,
ie, there was nothing to do, the mount continued working just fine when
the server comes back online.

Now, I'm not sure if it's really 2.6.24-specific problem or a userspace
problem.  Some time ago we also upgraded nfs-kernel-server (Debian)
package, and the remount-after-nfs-server-reboot problem started to
occur at THAT time (and it is something to worry about as well, I just
had no time to deal with it); but the dmesg spamming only appeared
with 2.6.24.

How to debug the issue further on from this point?

Thanks!

/mjt
--
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] quota: Turn quotas off when remounting read-only

[Michael Tokarev]

Andrew Morton wrote:
> On Thu, 7 Feb 2008 15:37:21 +0100 Jan Kara <[EMAIL PROTECTED]> wrote:
> 
>> Turn off quotas before filesystem is remounted read only. Otherwise quota 
>> will
>> try to write to read-only filesystem which does no good... We could also just
>> refuse to remount ro when quota is enabled but turning quota off is 
>> consistent
>> with what we do on umount.

[a nice one-liner snipped]

> Cool.  And this is applicable to 2.6.23, 2.6.22 and even earlier, isn't it?

Provided the amount of time this issue exists, I don't think it's worth
to push it to -stable.  It's an ld, issue, which happens quite
rarely, and no one bothered to report it so far...  But it's not my
call... ;)

But...  I'm thinking about this scenario:

 # mount /data
 # quotaon /data
 (some maintenance stuff to be planned)
 # mount -o remount,ro /data
 (do backup etc)
 # mount -r remount,rw /data

at this point, it's expected that quota on /data is enabled.
After this patch, it's not anymore...

I think it's more usual scenario than mine (umount instead of
remount-rw).  And this change will break it.  So I'm not sure
what really to do here.  Probably refusing remount-ro if quota
is on is better...  it's annoying for sure, but at least it's
explicit, and avoids the handg too.

/mjt
--
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: remount-ro & umount & quota interaction

[Michael Tokarev]

Jan Kara wrote:
[]
>> I mean, why it locks in the first place?  Quota subsystem trying
>> to write something into an read-only filesystem?  If so, WHY it
>> is trying to do that on umount instead on a remount-ro?

>   Actually, I couldn't reproduce the hang on my testing machine so I don't
> know exactly why it hangs. But my guess is that it's because we try to
> write to the filesystem...

I can't reproduce it here easily as well.  Yesterday I had a
locked-up console and had to hard-reboot the machine due to
this (it was far from first time when I've hit this issue),
but "on-demand reproducing" don't work (the uptime on that
host was about 100 days, and I had to do some repartition -
hence remount-ro to copy consistent data to other place -
maybe during that 100 day there was something... ;)

And I wasn't able to reproduce it on 2.6.24 so far, as well
(this one is only used on a test machine so far).

I'll keep trying ;)

Thanks for your support!

/mjt
--
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: remount-ro & umount & quota interaction

[Michael Tokarev]

Jan Kara wrote:
[deadlock after remount-ro followed with umount when
 quota is enabled]

>   Of course, thanks for report :). The problem is we allow remounting
> read only which we should refuse when quota is enabled. I'll fix that in
> a minute.

Hmm.  While that will prevent the lockup, maybe it's better to
perform an equivalent of quotaoff on mount-ro instead?  Or even
do something more useful, like flush the quota stuff like the
rest of the filesystem is flushed to disk, so that on umount,
quota will not stay on the way...

I mean, why it locks in the first place?  Quota subsystem trying
to write something into an read-only filesystem?  If so, WHY it
is trying to do that on umount instead on a remount-ro?

Thanks!

/mjt
--
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/

remount-ro & umount & quota interaction

[Michael Tokarev]

For a long time I'm bitten by a bad interaction
of mount -o remount,ro and quota operations.

The sequence is as follows:

 mount /fs
 quotaon -ug /fs
 mount -o remount,ro /fs
 umount /fs

At this point, umount never returns.  /proc/$pid/wchan
shows vfs_quota_off:

Feb  6 20:53:25 linux kernel: umountD e5183eb8 0  8646  1
Feb  6 20:53:25 linux kernel:e5183ecc 0086 0002 e5183eb8 
e5183eb0  c1db2540 c1db2684
Feb  6 20:53:25 linux kernel:c1db2684 c1c0dd00  cfd9f1c0 
c0367080 c0367080 f5849000 f7f06880
Feb  6 20:53:25 linux kernel:f7e89d80  c0367080 b7c9795c 
005f3997  00ff 
Feb  6 20:53:25 linux kernel: Call Trace:
Feb  6 20:53:25 linux kernel:  [] vfs_quota_off+0x345/0x490
Feb  6 20:53:25 linux kernel:  [] autoremove_wake_function+0x0/0x50
Feb  6 20:53:25 linux kernel:  [] deactivate_super+0x46/0x80
Feb  6 20:53:25 linux kernel:  [] sys_umount+0x4a/0x240
Feb  6 20:53:25 linux kernel:  [] sys_stat64+0xf/0x30
Feb  6 20:53:25 linux kernel:  [] remove_vma+0x39/0x50
Feb  6 20:53:25 linux kernel:  [] do_munmap+0x197/0x1f0
Feb  6 20:53:25 linux kernel:  [] sys_oldumount+0x15/0x20
Feb  6 20:53:25 linux kernel:  [] sysenter_past_esp+0x5f/0x85

The filesystem is ext3.  The issue is here for a long time,
at least since before 2.6.20, and is still present in 2.6.23
(I'll try 2.6.24 later today).

Can it be fixed please? :)

Thanks!

/mjt
--
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: swsusp on an AMD x2-64, 2.6.24: regression?

[Michael Tokarev]

Michael Tokarev wrote:
> Rafael J. Wysocki wrote:
[]
>> I guess it's a special variation of
>> http://bugzilla.kernel.org/show_bug.cgi?id=9528
>>
>> Please try to hibernate in the shutdown mode (ie. echo
>> "shutdown" into /sys/power/disk before hibernation).

[yes it works with shutdown...]

> In any way, this is definitely progress, and that bug
> seems to be the same as I'm seeing here.
> 
> Now... I see there's a new BIOS for this mobo available
> (it's ASUS M2NPV-VM motherboard, Geforce6150/Nforce430(?)),
> which is more recent compared with what I have here.  Trying
> it now (will try to reflash it without a floppy - it turns
> out to be quite.. challenging task ;)

Ok, updated the bios (using freedos virtual boot floppy provided
by memdisk from syslinux), and... now it all works correctly!

I was definitely blaming linux for the regression - obviously,
as "before-kernel" worked, while "current-kernel" does not
anymore.  But the problem seems to be due to some bios buglet.
Oh well... ;)

> Thanks!
!

Now I can go on with my other.. question, namely the UPS thingie... :)

/mjt
--
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: swsusp on an AMD x2-64, 2.6.24: regression?

[Michael Tokarev]

Rafael J. Wysocki wrote:
> On Friday, 1 of February 2008, Michael Tokarev wrote:
[]
>> no_console_suspend it is.  Tried that, the "S|" thing is still
>> here, but instead of "Suspending console(s)" it now shows
>> progress of suspending other devices.  The end result is
>> the same - finally it stops and sits here ad infinitum.
> 
> I guess it's a special variation of
> http://bugzilla.kernel.org/show_bug.cgi?id=9528
> 
> Please try to hibernate in the shutdown mode (ie. echo
> "shutdown" into /sys/power/disk before hibernation).

Hmm.  A very obscure thing - that bug, that is.

Tried "shutdown" - it works - even with all the other
"fancy" stuff like highres timers, cpufreq et al.  And
it resumes correctly as well.

After reading all the stuff attached to that bugreport,
I also tried removing ohci_hcd - it also works just fine
(had to do it in one line --
   rmmod ohci-hcd; sleep 5; echo disk > /sys/power/state
-- because I don't have non-USB keyboard handy :)

What I also noticied is that at least twice while doing
all the experiments, I've seen a message similar to (off
memory):

  ohci_hcd: unlink after non-IRQ - controller is probably using the wrong IRQ

this is done when no_console_suspend is enabled - during
the final stage of suspend, when the kernel prints messages
about disabling acpi devices.  I can't reproduce it easily,
but it happened at least twice with the same kernel configuration
(i tried different options, many variations, recompiling and
reinstalling kernel each time).

In any way, this is definitely progress, and that bug
seems to be the same as I'm seeing here.

Now... I see there's a new BIOS for this mobo available
(it's ASUS M2NPV-VM motherboard, Geforce6150/Nforce430(?)),
which is more recent compared with what I have here.  Trying
it now (will try to reflash it without a floppy - it turns
out to be quite.. challenging task ;)

Thanks!

/mjt
--
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: swsusp on an AMD x2-64, 2.6.24: regression?

[Michael Tokarev]

Pavel Machek wrote:
> On Fri 2008-02-01 00:41:06, Michael Tokarev wrote:
[]
>> With 2.6.24, it tries to suspend, saves pages to disk,
>> when prints this:
>>
>> ..Saving pages... done.
>> Sl

It's actually "S|", not "Sl".

>> Suspending console(s)
>> _
>>
>> At this point, nothing more happens.  It does not
>> react to keyboard or to any other external events,

..because the keyboard is USB-connected, and it shuts
down all USB devices.  I'll try with PS/2 keyboard
(when I'll find one I had somewhere... ;)

[]
> no_console_suspend (sp?), nohz=off, highres=off, and try with minimum
> config.

no_console_suspend it is.  Tried that, the "S|" thing is still
here, but instead of "Suspending console(s)" it now shows
progress of suspending other devices.  The end result is
the same - finally it stops and sits here ad infinitum.

nohz and highres are useless now, as I recompiled the kernel
without support for those, and without CPU_IDLE and other
fancy stuff, and disabled cpufreq just in case.

What's minimum config?  Should I turn off SMP (it's a dual-core
CPU by the way)?  Something else?  (I already removed most
driver modules when when trying suspend - only ones which are
absolutely necessary are left).

I've read Documentation/power/tricks.txt. From that list,
I have the following:

 o all drivers are unloaded except disk and usb (keyboard)
 o preempt is disabled (was never enabled)
 o APIC IS in use.
 o modules are in use.  Is it worth to try module-less?
 o vga text console - not even "vga" per se, - no framebuffers
   and such, not even as modules.  No "video mode switching
   support" is enabled.
 o only a few processes left, in like single-user mode.

One other difference between 2.6.23 and 2.6.24 as I see here
is: 2.6.24 tells me about TSC unstability (when I load cpufreq
stuff), while 2.6.23 did not.  This is about 64bit mode - with
32bits, both switches from tsc to hpet, so in this regard,
2.6.24 (with 32bits) is not different from 2.6.23 it seems
(i mean in relation with suspend issues, since 32bits .23
mentioned tsc instability yet it suspended fine).

So I'm.. stuck. :)  Don't know where to go from here.

Thanks!

/mjt
--
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: hibernate/suspend-to-disk: to turn power or not?

[Michael Tokarev]

Pavel Machek wrote:
[]
>> I'm looking at the uswsusp source (while the kernel compiles),
>> and have a question here.  Is it possible to call some external
>> application (typically a shell script) to do the final work after
>> when the image has been written?  I mean in principle - I
>> understand there are some limitations here, but I don't know
>> which exactly.
> 
> No, you can't exec() anything. That would write mtime back to disk and
> cause badness.

Now that's.. interesting.

s2disk writes to a swap device/file, which should update
mtime of this device node/file.  Isn't it something which
also causes the same badness?

Also, if the only concern is mtime update, what's really
wrong with it?  I mean, regardless of whether such update
will finally hit the disk or not, there's not much difference
really - it updates just mtime field, and there should be
no harm in that.  Unless such update first goes to a
journal (in a journalling filesystem) - which DOES modify
some on-disk structures.

>> it typically involves writing/reading something to/from
>> a given serial port (/dev/ttySxx), or to an USB device,

> Create libups.so, and link s2disk to it?

And what's the difference here again?  We'll open a serial
port and write something to it - which, again, will update
mtime of that device node.  Unless the said node is on a
tmpfs, exactly the same badness will happen.  Not all the
world is udev, after all.

So I don't get the reason why we can't exec something here,
still.  (And, for example, call splashy commands as external
processes, instead of linking all this cruft into s2disk and
resume.)

What I'm thinking about here is - s2ram mlock()s its memory.
If it will fork/exec something, that something will obviously
NOT be locked like that.  Is it of some concern?  Probably
not, because that something will be executed after we've
taken the snapshot.

/mjt
--
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/

swsusp on an AMD x2-64, 2.6.24: regression?

[Michael Tokarev]

Since I upgraded from 2.6.23 to 2.6.24, suspend to
disk does not work anymore on this machine.  I'm
trying to debug this now, for several hours already,
without much luck so far.

The machine is based on AMD X2-64 (BE-2400) CPU and
NVidia MCP51PV (GeForce 6150/NForce 430) chipset.

Up until 2.6.23 (both 32- and 64-bit kernels), suspend/
resume worked just fine without any glitch.

With 2.6.24, it tries to suspend, saves pages to disk,
when prints this:

..Saving pages... done.
Sl
Suspending console(s)
_

At this point, nothing more happens.  It does not
react to keyboard or to any other external events,
only reset/poweroff helps.  Note the "Sl" stuff -
I guess it's a beginning of some message, but I
don't know which one.

After a hard reboot after that, the system resumes
from the saved image.

This happens with both 32- and 64-bits kernels, when
using either good'old `echo disk > /sys/power/state'
or when using s2disk from uswsusp (with 32bits kernel,
as this utility does not work with 64bits kernel when
compiled as 32bits application).  Note that when using
s2disk with 2.6.24, very similar picture is shown -
that same "Sl" line.

The only noticeable changes in my config (x86-64 one)
compared with the one from 2.6.23 is - I enabled tickless
(dyntics) and high-res timers, CPU_IDLE and FAIR_CGROUP_SCHED.
I recompiled the kernel without those options (on by one), --
the effect on suspend is exactly the same.

Is there anything I can do to further diagnose this?

Thanks!

/mjt

--
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: hibernate/suspend-to-disk: to turn power or not?

[Michael Tokarev]

Nigel Cunningham wrote:
[]
> That should be doable. How is your UPS connected? Presumably, with some
> modifications to the appropriate driver, we could send the commands when
> we're ready to shutdown. It would probably be useful whether or not your
> hibernating (if not, sending the commands could always be made an option).

You mean adding stuff to some KERNEL driver?  Like to a serial driver if
the UPS is connected to a COM-port??

I'm afraid either I don't understand what you're talking about here, or,
if I got you right, that YOU don't understand what you're talking about...

Come on, teaching kernel about various idiotic UPSes out there is more
than insane... ;)

/mjt
--
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: hibernate/suspend-to-disk: to turn power or not?

[Michael Tokarev]

Rafael J. Wysocki wrote:
> On Wednesday, 30 of January 2008, Michael Tokarev wrote:
>> I'm trying to "glue" hibernation and UPS control
>> together, and have a question.
[]
> If your box hibernates and resumes correctly in the shutdown mode (ie.

Ohh-well.. :)

I was thinking about more or less general solution to this.
Yes, my boxes counts as primary targets, because we've seen
so many various failures due to power loss and because I want
to finally stop it somehow.  The thing basically works with
plain shutdown (no suspend is involved), but it turned out
that many esp. cheap UPSes (the ones used by "masses") don't
check the status of their batteries up until they lose AC
power, when it's too late...  The result is that when you
lose AC power, you discover that you've only a few secs to
perform shutdown, and hence hibernate is the only option,
as it usually is much faster than to try to shut down stuff
(esp. when things like squid or a big database are on the
way, with their looong time to shutdown cleanly).

> basically without ACPI assistance), you can use s2disk for hibernation and
> modify it to switch off the UPS instead of powering off the box.

Heh.  First, I didn't know about s2disk up until now.  I've
seen uswsusp utils some years before, but I thought it's
about some patch for vanilla kernel (some time ago it was
indeed the case) and that the utils aren't needed for current
kernels (I always used "echo disk > /sys/power/state" to
suspend).

Now, and I hate to say that, I found that this my test
box is totally unsuitable for testing this all.  Because
it all just Does Not Work.  Because:

 o 2.6.24 kernel fails to suspend properly.  It "saves pages",
   prints "Suspending console", when prints "Sl" and nothing
   more happens.  At this time, I can manually poweroff the
   machine, and resume works.  The same happens when running
   32bits or 64bits kernel (it's an amd x2-64 system).

 o uswsusp is unaware of 64bits kernel and 32bits userland.
   Looking at the source, that's probably (and for sure in
   certain places) more than just missing compat_ioctl wrappers
   for those:

  ioctl32(s2disk:3574): Unknown cmd fd(4) cmd(400c330d){t:'3';sz:12} 
arg(ffa4578c) on /dev/snapshot
  ioctl32(s2disk:3574): Unknown cmd fd(4) cmd(4004330a){t:'3';sz:4} 
arg(0805) on /dev/snapshot

   "probably" is where it reads the swap space - it's just
   my guess that s2disk (and resume) will do some wrong here.
   "for sure" is vbe code - since 32bits vbetools package
   fails badly with 64bit kernel, it seems that it is looking
   at the wrong place in /dev/mem.

 o when running 32bits 2.6.24 kernel, s2disk fails the same
   way as pure in-kernel solution fails, above.  And it
   fails to resume, too, -- unlike pure in-kernel solution.

I know kernel-only way worked with 2.6.23 (both 32 and 64
bits) - compiling that now...

It's sad when while working on something you discover that
"underlying" tools you use also don't work, and start fixing
those, when discover that something else fails, and so on,
until you finally gave up and abandom the whole initial
idea...  Oh well, but c'est la vie...

Back to the original question and a proposed solution.

I'm looking at the uswsusp source (while the kernel compiles),
and have a question here.  Is it possible to call some external
application (typically a shell script) to do the final work after
when the image has been written?  I mean in principle - I
understand there are some limitations here, but I don't know
which exactly.

For the given task (send some command to the damn UPS),
it typically involves writing/reading something to/from
a given serial port (/dev/ttySxx), or to an USB device,
or to a network -- depending on the UPS in use.  There
are so many different UPSes out there, with so many different
and stupid so-called "protocols", that it's impossible to
teach s2disk about them all.

If such a thing is possible, the next question is obvious --
where exactly it belongs in suspend.c, and again, under
which conditions it can be called (for example, how about
different methods - shutdown/platform/etc?).

Also, if I need the system to stay on while the UPS cuts
the power (in order for it to start up automatically,
provided "restore to previous state on AC power resume"
BIOS option is enabled), should such a script (which is
called from s2disk) just sleep letting the UPS to do the
work, or should it pass information back to s2disk to NOT
to poweroff the machine?  I mean, just like in case of
"regular" shutdown when we're running off battery, between
when the UPS control script gets called and when it's
really safe to cut the power off, some more things has to
be done - like stopping disks, "remoint

Re: hibernate/suspend-to-disk: to turn power or not?

[Michael Tokarev]

Bruno Prémont wrote:
> On Wednesday 30 January 2008 20:18:40 you wrote:
>> I'm trying to "glue" hibernation and UPS control
>> together, and have a question.
>>
>> When the system power comes off an UPS (Uninterruptable
>> Power Supply I mean), it's probably a good idea to turn
>> the UPS off when shutting the system down or hibernating.
>
> This depends on how you can turn the UPS back on...

Most UPSes has an option to turn themselves on when the
power returns (except of very dumb ones).

> If pushing the button manually is not an issue or the UPS
> can still be controlled remotely (e.g. via network) when
> being off it doesn't matter.

It does not matter really.

[]
>> returns.  Now, when we shutting down a system, we
>> need to turn the UPS *before* powering down the
>> system but *after* the shutdown procedure has been
>> completed.  This is done by replacing poweroff with
>> halt, and ordering the UPS to turn itself off after
>> a small delay (needed for the poweroff command to
>> complete) - this way, system will be on but in a
>> safe-to-powercut mode, and in order to turn it
>> back on only the UPS has to be turned on.
>
> All systems I've seen that provide such an option in the BIOS
> list three possible actions on power-back:
> - remain off
> - go back to previous state
> - boot

Or sometimes a subset of the 3 - like "always off or return to
previous state".  But this does not matter again - I'm not
asking about how to control the power-on feature, or how to
control a particular UPS, -- instead, I'm asking how to hook
up something into the hibernate path, to the very end of it,
to do whatever is needed, and/or how to control whether after
the hibernate is complete the kernel should turn the system
off or not.

> In your case it's possibly easier to choose the option to
> always boot when power comes back.

Whatever works and is most suitable given the particular
situation.  It doesn't really matter here.

[]
> Can you configure your UPS to poweroff when load on its output
> drops below a given threshold? (I know that such a feature
> exists on master-slave power outlets where all slave outlets
> are powered only when the master outlet has a sufficient load)

Certain models can be configured this way.  But the question
stands still, because many models can't be programmed this way.

What's needed is to run something at the end of hibernate
process, nothing more nothing less.

> Another path may be to dig into hibernate via kexec:
>   http://kerneltrap.org/node/11756

Well.. that might work after all.  It doesn't work
with vanilla kernel, does it?  I mean, I can get
*my* system to work as I like it to work, but it
can't work on another Linux system...

>> P.S.  Surprisingly, there's NO software that works
>> with UPSes and implements even the basic shutdown
>> process completely (not even mentioning hibernation).
>> Most common is just to turn the system off without
>> touching the UPS.  Yes it will work (till the UPS
>> will run out of battery), but how about servers which
>> should be up-n-running, ie. which should restart
>> automatically?..  Oh well.
>
> Can't the UPS software trigger scripts or be controlled
> using scripts?

In some cases it can, but usually in a very limited way.
It's just like no one wrote good software about this
topic... ;)  Or good scripts, for that matter.  That's
exactly what I'm trying to do, and certain questions
(like this one) pops up.

Thanks.

/mjt
--
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/

hibernate/suspend-to-disk: to turn power or not?

[Michael Tokarev]

I'm trying to "glue" hibernation and UPS control
together, and have a question.

When the system power comes off an UPS (Uninterruptable
Power Supply I mean), it's probably a good idea to turn
the UPS off when shutting the system down or hibernating.

Even with shutdown (not related to hibernating) there's
an interesting twist: modern systems can remember the
previous on/off status when the power gets cut and
restores - BIOS-controlled option that allows the
system to automatically start when the input power
returns.  Now, when we shutting down a system, we
need to turn the UPS *before* powering down the
system but *after* the shutdown procedure has been
completed.  This is done by replacing poweroff with
halt, and ordering the UPS to turn itself off after
a small delay (needed for the poweroff command to
complete) - this way, system will be on but in a
safe-to-powercut mode, and in order to turn it
back on only the UPS has to be turned on.

But the question comes as how to control the UPS when
we replace shutdown with hibernation.  Ideally I want
to send some commands to the UPS after hibernation has
been completed (since I don't know how much time it
will require to hibernate), but before the machine
will be turned off by the kernel.  Or at the very least,
to be able to stop the kernel turning the machine off
after hibernation process is complete - this way,
I can order the UPS to turn the power off after some
delay and hope hibernation process will finish when
the UPS will finally cut the power (not all UPSes
are able to do timely shutdown like this).

What's my way here?

Thanks!

/mjt

P.S.  Surprisingly, there's NO software that works
with UPSes and implements even the basic shutdown
process completely (not even mentioning hibernation).
Most common is just to turn the system off without
touching the UPS.  Yes it will work (till the UPS
will run out of battery), but how about servers which
should be up-n-running, ie. which should restart
automatically?..  Oh well.
--
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: Sending IOCTLs from 32-bit userland to 64-bit Kernel module

[Michael Tokarev]

Yoav Artzi wrote:
> Hi,
> 
> 
> I have a 32-bit user land application which sends an IOCTL to a 64-bit
> Kernel module. I have a few different cmd codes that I can send through
> the IOCTL. For some reason I seem to always get the same IOCTL cmd from
> user land, no matter what the ioctl() call is given. This cmd code that
> I get has some bytes (W/R and the module code) that are OK, but the rest
> is just garbage or zeros. This was originally a 32-bit system, and we
> are no converting the Kernel module to 64-bit, so maybe there's
> something special for 32-64 communication that miss.

Please see numerous examples in kernel source, in many files named
compat_ioctl.c.  If your ioctls uses structures with fields that
have different sizes in 32- and 64-bit worlds (most notable int,
various enums etc), there should be corresponding translation
layer as in those examples.  If it's your kernel code, that is.
(And try to avoid such types there, use u32 or u64 and the like
that explicitly specify size).

Another possible problem is different alignment of fields in
64- vs 32-bits worlds.

> I am working on Linux Kernel v2.6.18.

If the kernel side isn't your code, the chances are quite high
that this problem has long been fixed in more recent kernels.

/mjt
--
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: Udev coldplugging loads 8139too driver instead of 8139cp

[Michael Tokarev]

Stephen Hemminger wrote:
> On Tue, 29 Jan 2008 03:46:08 +0300
> Michael Tokarev <[EMAIL PROTECTED]> wrote:
[]
>> There are 2 drivers for 8139-based NICs.  For really different two kinds
>> of hardware, which both uses the same PCI identifiers.  Both drivers
>> "claims" to work with all NICs with those PCI ids, because "externally"
>> (by means of udev for example) it's impossible to distinguish the two
>> kinds of hardware, it becomes clean only when the driver (either of the
>> two) loads and actually checks which hardware we have here.
> 
> Is there any chance of using subdevice or subversion to tell them apart?
> That worked for other vendors like DLINK who slapped same ID on different
> cards.

If it were that simple... ;)

No.  The difference is in PCI revision number (byte #8 in PCI config space).
If it's >= 0x40 - it's 8139too, < 0x40 - 8139cp.  Or 0x20 - I forgot.

Here's a code snippet from a shell script I used ages ago to automatically
load modules (similar to what udev does nowadays):

  # special hack for 8139{too,cp} stuff
  case "$modalias" in
  *v10ECd8139*)
rev="$(dd if="$1/config" bs=1 skip=8 count=1 2>/dev/null)"
if [ -n "$rev" ]; then
  list=
  for module in $modlist; do
case "$module" in
8139cp)
  if [ ".$rev" \< ". " ]; then
$vecho1 "$TAG: not loading $module for this device"
continue
  fi
  ;;
8139too)
  if [ ".$rev" \> ". " ]; then
$vecho1 "$TAG: not loading $module for this device"
continue
  fi
  ;;
esac
list="$list $module"
  done
  modlist="$list"
fi
;;
  esac

/mjt
--
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: Udev coldplugging loads 8139too driver instead of 8139cp

[Michael Tokarev]

Frederik Himpe wrote:
> Linux 2.6.24 kernel gives the following messages when udev coldplugging
> loads the driver for my NIC:
> 
> 8139too :00:0b.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip
> 8139too :00:0b.0: Use the "8139cp" driver for improved performance and 
> stability.

There are 2 drivers for 8139-based NICs.  For really different two kinds
of hardware, which both uses the same PCI identifiers.  Both drivers
"claims" to work with all NICs with those PCI ids, because "externally"
(by means of udev for example) it's impossible to distinguish the two
kinds of hardware, it becomes clean only when the driver (either of the
two) loads and actually checks which hardware we have here.

Udev in fact loads both - 8139cp and 8139too.  The difference is the ORDER
in which it loads them - if for "cp-handled" hardware it first loads "too",
too will complain as above and will NOT claim the device.  The same is
true for the opposite.

So - in short - things has always been this way (thanks to realtec).
I've seen similar (but opposite) effects on my systems, which are all
should be serviced by 8139too driver but 8139cp loaded first - up
till i gave up and just disabled 8139cp...

I don't know what happened in 2.6.24, but my guess is that since 8139too-based
hw is now alot more common, the two drivers are listed in the opposite
order.

In short: NotABug, or ComplainToRealtec (but that's wy too late and
will not help anyway) ;)

/mjt

--
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/

tickless/dynticks + cpufreq = tsc unstable

[Michael Tokarev]

Is it normal that once I enable cpufreq on
a tickless system, it spews a warning:

Clocksource tsc unstable (delta = -288201154 ns)

?

It's an old problem, and I was thinking about
differences between x86-64 (it worked there) and
i386 kernels.  But with 2.6.24, x86-64 can run
tickless as well, and once I enable this mode,
and load dynamic cpufreq governor, the above message
gets printed too.

The system is amd x2-64, all kernels since tickless
has been introduced.

I'm not sure if it's really something to worry about --
probably not, as this system has hpet.  But on another
system, Intel-based, where there was no hpet and jiffies
clocksourse gets selected instead, there were some...
issues still (I don't remember offhand which ones, will
check the next week with new kernel).

Thanks!

/mjt
--
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: acpi/apm events as inputs: how to handle?

[Michael Tokarev]

Michael Tokarev wrote:
> Dmitry Torokhov wrote:
> []
>>> Well, you use event device in any case; as for finding right one - I guess
>>> you look at device capabilities and filter what you need ...
>>>
>>> {pts/0}%
>>> cat /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/capabilities/key
>>> 10 0 0 0
>> Exactly. Any driver working through evdev interface should examine
>> device's capabilities and decide whether it is interested in the
>> device or not.
> 
> Ok, got it.
> But I can't open the device multiple times, can I?
> Like, there's a daemon listening on volume up/down and other
> multimedia keys for example, and it can't listen to the same
> eventX as a daemon that's watching for power/sleep buttons, --
> instead, they should be combined into the same executable.
> Unless there's a way to multiplex the events...
> (Hmm, this becoming quite... ugly.  Oh well.)

Are the capabilities available over ioctl?  Because if not, it
really is a problem to find correct /sys file for a given /dev
node.  I'd rather not scan whole /sys to find the right device... ;)

> By the way, where are all the capabilities of input devices
> documented?

Looked at the code, but it's a bit... difficult to follow, so
to say.  What is in ../capabilities/keys, for example - is it
a bitmap of all keys the given event device can produce, based
on KEY_xxx constants from  ?

/mjt
--
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: acpi/apm events as inputs: how to handle?

[Michael Tokarev]

Dmitry Torokhov wrote:
[]
>> Well, you use event device in any case; as for finding right one - I guess
>> you look at device capabilities and filter what you need ...
>>
>> {pts/0}%
>> cat /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/capabilities/key
>> 10 0 0 0
> 
> Exactly. Any driver working through evdev interface should examine
> device's capabilities and decide whether it is interested in the
> device or not.

Ok, got it.
But I can't open the device multiple times, can I?
Like, there's a daemon listening on volume up/down and other
multimedia keys for example, and it can't listen to the same
eventX as a daemon that's watching for power/sleep buttons, --
instead, they should be combined into the same executable.
Unless there's a way to multiplex the events...
(Hmm, this becoming quite... ugly.  Oh well.)

By the way, where are all the capabilities of input devices
documented?

/mjt

--
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: acpi/apm events as inputs: how to handle?

[Michael Tokarev]

Dmitry Torokhov wrote:
> Hi Michael,

Hello!

[]
> There are keyboards (USB, PS2) with Sleep and Suspend buttons
> that are not related to ACPI nor APM. We had 2 options - add
> an input handler that would translate input events into ACPI
> events and feed /proc/acpi/event[*] or go other way around and
> use input layer for delivering suspend and sleep requests for
> all types of keyboards/buttons, including ACPI buttons. The
> secons option is better because userspace solution using input
> layer will not be tied to a particular technology (ACPI) and
> can be used on other platforms as well.

Aha, this makes sense.
And it brings a few questions, too.

As far as I can see, there's little information about how to
actually use the input interface.  Let's suppose I'm about to
write an application (a daemon) that should replace acpid --
it's handling of the said buttons (power and sleep).  How to
find the right devices?  Should it use /dev/input/event* or
something else?  How about handling hot-plugged devices like
new (and removed) keyboards? (And yes, my keyboard has a sleep
button.)

And by the way, what INPUT can one expect from a PC speaker?
input: PC Speaker as /devices/platform/pcspkr/input/input0

Thanks!

/mjt
--
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/

acpi/apm events as inputs: how to handle?

[Michael Tokarev]

(Not so) recently, ACPI events started appearing as
key press events over linux input subsystem.  The
question regarding this is simple: how it's supposed
to be handled?

First of all, I don't know any software so far that
can handle input layer in userspace when not running
X.  In X, it's usually done using window manager
setup or with special application (like, volume
up/down keys etc).  But without X, there's no such
application, as far as I can see.

It's easy to write one, but there may be.. issues
with finding which input device to use.

Now, linux already have hotplug subsystem, using
/sbin/hotplug helper (or whatever it points to,
or using netlink).  ACPI key events are rare.

What I'm thinking about is: why ACPI events are
routed over input subsystem, instead of hotplug
subsystem?  With input, there's a need for a
special daemon/application listening on the
specific "keyboard" device, while with hotplug
subsystem, it's already here - linux (by default
anyway, if not running udev etc), kernel fires
up a script when an event occurs.  I don't see
how this special application/daemon is different
from ol'good acpid.

Or.. maybe I missed something?

Thanks!

/mjt
--
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: RAID timeout parameter accessibility request

[Michael Tokarev]

Jose de la Mancha wrote:
[]
> Jan Engelhardt wrote:
>> Not sure about Debian, but perhaps /sys/block/md0/md/safe_mode_delay
>> does something?
> 
> --> I'll check that out. Does someone know about how this "safe mode delay"
> works ?

It's about something entirely different.  This parameter tells md after
how much inactivity time to update the superblocks to indicate the array
is "clean" - so that in case of power loss w/o shutting down the array,
it will not require reconstruction.  It has nothing to do with timeouts.

By the way, linux raid is usually discussed at [EMAIL PROTECTED], not here.

/mjt
--
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 1/1] mxser, remove it

[Michael Tokarev]

Jiri Slaby wrote:
> (Old) mxser is obsoleted by mxser_new and scheduled for removal on Dec 2007.
> Remove it.
> 
> Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
> ---
>  Documentation/feature-removal-schedule.txt |8 -
>  drivers/char/Kconfig   |   11 -
>  drivers/char/Makefile  |1 -
>  drivers/char/mxser.c   | 3141 
> 
>  drivers/char/mxser.h   |  441 
>  5 files changed, 0 insertions(+), 3602 deletions(-)
>  delete mode 100644 drivers/char/mxser.c
>  delete mode 100644 drivers/char/mxser.h

While we're at it, how about adding a modalias for mxser_new
module with old (being removed) name, so that users who're
using the old module will not scream?  I mean, in order for
`modprobe mxser' to load mxser_new module.

/mjt
--
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.24-rc5-git7: Reported regressions from 2.6.23

[Michael Tokarev]

Johannes Weiner wrote:
[]
> I still have a bug with cpufreq when using ondemand governor as default.
> 
> The performance governor, which has been the essential default until
> 1c2562459faedc35927546cfa5273ec6c2884cce,  was initialized with
> fs_initcall() instead of module_init() to make sure the driver is up and
> running when the bootcode (speedstep_init in my case) calls into it.
> 
> Since the above mentioned commit, other governors can also be chosen to
> be the default but they are not correctly initialized before first use
> then.

By the way, is there any real need to specify default governor at
a compile time in the first place?  Performance governor (which was
the only default so far) is a very simple one (not large to consider
its size effects for embedded systems for example), and switching
governors at run time is trivial as well.  What's the motivation
behind this new config option?

[]
> This migrates all governors from module_init() to fs_initcall() when
> being the default, as was already done in cpufreq_performance when it
> was the only possible choice.

Oh well.  Which leads to more surprises in the future, I think...

Thanks.

/mjt
--
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: /sys/block [was: [PATCH 007 of 7] md: Get name for block device in sysfs]

[Michael Tokarev]

Michael Tokarev wrote:
> Kay Sievers wrote:
>> On Mon, 2007-12-17 at 08:29 +0300, Michael Tokarev wrote:
> []
>>> How to distinguish char devices from block devices in sysfs?
>>> Is the only way to read a symlink `subsystem' in the device
>>> directory?
>> By its subsystem value (block), from the symlink, from the environment,
>> or from $1.
> 
> Environment and $1 comes as arguments for hotplug helper, not
> when scanning /sys/.

By the way, that's one of reasons I asked about useful content
in uevent files (but failed to provide a patch so far ;).
In 2.6.23, those files ARE readable finally, but doesn't
contain much info yet.

/mjt
--
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: /sys/block [was: [PATCH 007 of 7] md: Get name for block device in sysfs]

[Michael Tokarev]

Kay Sievers wrote:
> On Mon, 2007-12-17 at 08:29 +0300, Michael Tokarev wrote:
[]
>> How to distinguish char devices from block devices in sysfs?
>> Is the only way to read a symlink `subsystem' in the device
>> directory?
> 
> By its subsystem value (block), from the symlink, from the environment,
> or from $1.

Environment and $1 comes as arguments for hotplug helper, not
when scanning /sys/.

>> For now, I've a shell code (used heavily in numerous places),
>> which looks like this:
>>
>>   function makedev() {
>> ...
>> case $DEVPATH in
>>   /block/*) TYPE=b ;;
>>   *) TYPE=c ;;
>> esac
>> ...
>> mknod /dev/$DEV $TYPE $MAJOR $MINOR
>>   }
>>
>> The only external process invocation in there is mknod, all
>> the rest is done using pure shell constructs.  Is it really
>> necessary to spawn another process just to read a symlink
>> now?  It will be almost 2 times slower
> 
> No need.

It seems there IS a need now ;)

Thanks for the clarification.

/mjt
--
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/

/sys/block [was: [PATCH 007 of 7] md: Get name for block device in sysfs]

[Michael Tokarev]

Kay Sievers wrote:
> On Mon, 2007-12-17 at 09:43 +1100, Neil Brown wrote:
>> On Saturday December 15, [EMAIL PROTECTED] wrote:
>>> On Dec 14, 2007 7:26 AM, NeilBrown <[EMAIL PROTECTED]> wrote:
 Given an fd on a block device, returns a string like

 /block/sda/sda1

 which can be used to find related information in /sys.
>> 
>>> As pointed out to when you came up with the idea, we can't do this. A 
>>> devpath
>>> is a path to the device and will not necessarily start with "/block" for 
>>> block
>>> devices. It may start with "/devices" and can be much longer than
>>> BDEVNAME_SIZE*2  + 10.
>> When you say "will not necessarily" can I take that to mean that it
>> currently does, but it might (will) change??
> 
> It's in -mm. The devpath for all block devices, like for all other
> devices, will start with /devices/* if !SYSFS_DEPRECATED.

This is the second time I come across this (planned?) change, and for
the second time I can't understand it.

How to distinguish char devices from block devices in sysfs?
Is the only way to read a symlink `subsystem' in the device
directory?

For now, I've a shell code (used heavily in numerous places),
which looks like this:

  function makedev() {
...
case $DEVPATH in
  /block/*) TYPE=b ;;
  *) TYPE=c ;;
esac
...
mknod /dev/$DEV $TYPE $MAJOR $MINOR
  }

The only external process invocation in there is mknod, all
the rest is done using pure shell constructs.  Is it really
necessary to spawn another process just to read a symlink
now?  It will be almost 2 times slower

(Sure thing this may be rewritten in C, but using shell it's
MUCH easier to customize if necessary.)

Also, /sys/block/ directory is very easy to use currently, --
unlike other /sys/ stuff which is way too deep and often
placed in unknown/unexpected places (and /sys/class/ and
/sys/bus/ directories are changing all the time).

What's the benefit of moving things from /sys/block/ to
/sys/devices/ ?

Thanks.

/mjt
--
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 2/2] Unionfs: clarify usage.txt mount options

[Michael Tokarev]

Michael Tokarev wrote:
> Erez Zadok wrote:
[...]

JFYI: My message bounced back:

<[EMAIL PROTECTED]>: host cs.sunysb.edu[130.245.1.15] said: 550 5.7.1 Access
denied (in reply to MAIL FROM command)

(stupid anti-spam policy @sunysb.edu, it seems - refusing
to accept *.ru as sender address, no matter if the mail
was sent to, say, postmaster@, asking about delivery
problems...  Oh well.)

Please excuse me for cluttering up the lists.

/mjt
--
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 2/2] Unionfs: clarify usage.txt mount options

[Michael Tokarev]

Erez Zadok wrote:

> --- a/Documentation/filesystems/unionfs/usage.txt
> +++ b/Documentation/filesystems/unionfs/usage.txt
[]
> +OPTIONS can be any legal combination one of:
   ^
A small typo.

> +
> +- ro # mount file system read-only
> +- rw # mount file system read-write
> +- remount# remount the file system (see Branch Management below)
> +- incgen # increment generation no. (see Cache Consistency below)
> +
> +BRANCH-OPTIONS can be either (1) a list of branches given to the "dirs="
> +option, or (2) a list of individual branch manipulation commands, described
> +in the "Branch Management" section below.

Should this (2) choice mention remount operation somehow?
It seems the (2) case is about remount only.

> +The "dirs=" option takes a colon-delimited list of directories to compose
> +the union, with an optional branch mode for each of those directories.
> +Directories that come earlier (specified first, on the left) in the list
> +have a higher precedence than those which come later.  Additionally,

By the way, what is "precedence" here?  I mean, will unionfs always
write to the first rw branch, or is it possible to write to some
deeper branch too?

And finally, can a first (and all of them as well) branch be ro?

Thanks.

/mjt
--
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/

clock jumps on dualcore PentiumD with cpufreq

[Michael Tokarev]

This isn't a new issue, but so far no solution(s)
has been found, it seems.  And with kernel development
going on, the issue becomes worse.

Up to 2.6.20 or so (I don't remember exactly, but if
I recall correctly the issue first appeared when new
timer code has been merged), there was no issues at
all.

Starting with 2.6.21 (at least), I see frequent messages
from chronyd (http://chrony.sunsite.dk/), which was running
on this machine since the day one, messages telling me
that system clock has been reset - up to +/- several
seconds.

On 2.6.22 there were only a few such messages per day,
and the time delta was less than a second - in between
0.2-0.8 second usually.  On 2.6.23, it become much,
much worse.  Here's a typical log from today:

...
Dec  9 08:10:50 paltus chronyd[1761]: System clock wrong by 0.664195 seconds, 
adjustment started
Dec  9 08:31:06 paltus chronyd[1761]: System clock wrong by 0.666263 seconds, 
adjustment started
Dec  9 09:10:35 paltus chronyd[1761]: System clock wrong by 0.830534 seconds, 
adjustment started
Dec  9 09:47:56 paltus chronyd[1761]: System clock wrong by -0.632430 seconds, 
adjustment started
Dec  9 10:11:24 paltus chronyd[1761]: System clock wrong by 0.557093 seconds, 
adjustment started
Dec  9 10:30:36 paltus chronyd[1761]: System clock wrong by 0.931442 seconds, 
adjustment started
Dec  9 10:31:40 paltus chronyd[1761]: System clock wrong by 0.918518 seconds, 
adjustment started
Dec  9 10:32:44 paltus chronyd[1761]: System clock wrong by 0.919524 seconds, 
adjustment started
Dec  9 10:33:48 paltus chronyd[1761]: System clock wrong by -1.783922 seconds, 
adjustment started
Dec  9 10:50:53 paltus chronyd[1761]: System clock wrong by 0.815781 seconds, 
adjustment started
Dec  9 11:18:37 paltus chronyd[1761]: System clock wrong by -1.120279 seconds, 
adjustment started
Dec  9 11:48:30 paltus chronyd[1761]: System clock wrong by -0.576473 seconds, 
adjustment started
Dec  9 11:50:38 paltus chronyd[1761]: System clock wrong by 0.728826 seconds, 
adjustment started
Dec  9 11:52:46 paltus chronyd[1761]: System clock wrong by 0.561940 seconds, 
adjustment started
Dec  9 11:57:02 paltus chronyd[1761]: System clock wrong by -0.786041 seconds, 
adjustment started
Dec  9 12:18:22 paltus chronyd[1761]: System clock wrong by -0.559688 seconds, 
adjustment started
Dec  9 12:20:30 paltus chronyd[1761]: System clock wrong by 0.712789 seconds, 
adjustment started
Dec  9 12:26:55 paltus chronyd[1761]: System clock wrong by -0.511155 seconds, 
adjustment started
Dec  9 12:40:47 paltus chronyd[1761]: System clock wrong by 0.721966 seconds, 
adjustment started
Dec  9 12:47:11 paltus chronyd[1761]: System clock wrong by -1.053725 seconds, 
adjustment started
Dec  9 13:01:03 paltus chronyd[1761]: System clock wrong by 0.921670 seconds, 
adjustment started
Dec  9 13:21:20 paltus chronyd[1761]: System clock wrong by 0.948468 seconds, 
adjustment started
...

As far as I can guess, the problem is that the clock is
different on different CPUs (or, rather, cores), so when
the process (chronyd) gets moved from one core to another,
it loses its minds and behaves like the above, unable to
"understand" what's going on, and the result is that it
speeds up the clock on a core where it should slow the
clock down and vise versa, resulting it a mess.

The machine is an IBM xSeries 3200, single CPU dual-core
PentiumD processor:

vendor_id   : GenuineIntel
cpu family  : 15
model   : 6
model name  : Intel(R) Pentium(R) D CPU 2.80GHz
stepping: 4
cpu MHz : 2800.000
cache size  : 2048 KB

The system says that TSC clocksource is unstable and switches
to jiffies:

Clocksource tsc unstable (delta = 70021228 ns)
Time: jiffies clocksource has been installed.

There are two things I noticed so far.

First, this problem is quite strongly related to cpufreq.
Namely, without cpufreq scaling (with the default "performance"
governor), everything works correctly.  After switching to
"ondemand" governor, chronyd goes mad as shown above.  And
after switching back to "performance", after some time (needed
for the madness to slowly stop), the problem vanishes again.
By the way, I'm not exactly sure but it seems that the above
message (about TSC being unstable) is triggered right when
switching to "ondemand" governor.

And second, I've only seen the whole problem with 32bits
kernel.  x86-64 kernel (with the exact same config) does
not expose it in any way, be it cpufreq or not.

This last point is the very interesting one, because it
suggests that the bug is in kernel somewhere, more, that
it's in i386 part of it.

Sadly I've only a limited testing abilities on this machine,
as it's our main production (file) server (so I can only
test something on it during weekends and late evenings).

Similar (but at much smaller extent/scale) behavior has been
observed on several machines with AMD X2-64 processors as well,
also related to cpufreq, but this time both 64 and 32 bits
kernels behaves the sa

Re: PATCH: Hitachi disk quirk

[Michael Tokarev]

Lukas Hejtmanek wrote:
> Hello,
> 
> the following patch should be applied into 2.6.24-rc3 as the mentioned Hitachi
> disk has also problem with NCQ.

Which problems, exactly?

Note that recent massive "NCQ horkage" isn't necessary due to drives fault.
Search for "spurious completions during NCQ" for recent discussions
(many of them).

> --- a/drivers/ata/libata-core.c   2007-12-04 11:08:20.0 +0100
> +++ b/drivers/ata/libata-core.c   2007-12-04 11:09:23.0 +0100
>   { "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
> + { "HITACHI HTS541616J9SA00", "SB4IC7UP", ATA_HORKAGE_NONCQ, },
>   { "Hitachi HTS542525K9SA00", "BBFOC31P", ATA_HORKAGE_NONCQ, },

/mjt
--
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.23: does it supposed to work on an i486?

[Michael Tokarev]

H. Peter Anvin wrote:
> Michael Tokarev wrote:
[2.6.23 on an i486 machine]
>> The result is immediately machine reboot right
>> after bootloader (etherboot) passes control to
>> the kernel -- BEFORE "Uncompressing linux"
>> message.
>>
>> 2.6.22 worked just fine.
[]
> It looks like 2.6.23.9 is missing checkin
> 7ed192906a2144ebc8ca2925a85d27b9c5355668 from Linus' tree (attached),
> which is necessary to work on 386 and 486.

Well, I applied the patch (in 2.6.23 it's
 arch/i386/boot/pmjump.S,
not
 arch/x86/boot/pmjump.S,
but that's minor) - still the same behavior, it still reboots
instantly right when bootloader gave control to the kernel.
So it must be something else.. ;)

I'll try other kernels tomorrow, given some time (I already
spent almost the whole day today with this "machine").  This
whole story prompted me to just throw those machines away and
replace them with tiny devices (a small print server in this
case).  There are still several 486-class machines out there...

By the way, this very machine I'm experimenting with is a
strange beast by itself.  For example, etherboot does not
work on it properly, anything since version 5.1.0 just
freezes right after displaying the "greeting" message.
5.0.11 works.  However till now, linux worked on it just
fine, -- unlike etherboot.

Thanks!

/mjt
-
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/

2.6.23: does it supposed to work on an i486?

[Michael Tokarev]

I tried to upgrade one of our old machines
(used as print servers and similar tasks) today
from 2.6.22 to 2.6.23[.9].  The same config (with
minor tweaks for new options), i486 base arch,
X86_GENERIC=y.

The result is immediately machine reboot right
after bootloader (etherboot) passes control to
the kernel -- BEFORE "Uncompressing linux"
message.

2.6.22 worked just fine.

So I wonder if it's supposed to work in the first
place.  The thing is that this machine(s) are very
slow to boot, so trying to figure out which change
is at question will require quite some time...

Thanks.

/mjt
-
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: constant_tsc and TSC unstable

[Michael Tokarev]

H. Peter Anvin wrote:
> Paul Rolland (ポール・ロラン) wrote:
[]
>> Measured 3978592228 cycles TSC warp between CPUs, turning off TSC clock.
>> Marking TSC unstable due to: check_tsc_sync_source failed.
[]
>> but I was wondering if this is a bug or a feature ;)

> The problem you're having is that the TSCs of your two cores are
> completely different, over a second apart.  This is a bug, unrelated to
> constant_tsc.

A bug in where - in the CPU or in kernel?

The thing is that all our dual-core machines shows something like
that.

For example, dualcore PentiumD machine:
Nov  7 20:23:56 paltus kernel: Linux version 2.6.22-i686smp ([EMAIL PROTECTED]) 
(gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #2.6.22.12 SMP Wed 
Nov 7 20:02:14 MSK 2007
...
Nov  7 20:23:56 paltus kernel: checking TSC synchronization [CPU#0 -> CPU#1]:
Nov  7 20:23:56 paltus kernel: Measured 112 cycles TSC warp between CPUs, 
turning off TSC clock.
Nov  7 20:23:56 paltus kernel: Marking TSC unstable due to: 
check_tsc_sync_source failed.
Nov  7 20:23:56 paltus kernel: Brought up 2 CPUs

(not that huge difference as Paul reported, but still "unstable".
The same happens with 2.6.23)

Note that once TSC is disabled (it's using "jiffies" as far
as I can see), ntpd constantly speeds up and slows down the
clock, it jumps +/- 0.5sec every several minutes or hours -
I guess that's when ntpd process gets moved from one core
to another for whatever reason.  And an interesting thing
is that with 64bits kernel this TSC problem does not occur
on this very machine.

Something similar is reported on AMD X2 64 machines as well --
can't check right now.

Thanks.

/mjt
-
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.23.3

[Michael Tokarev]

Greg Kroah-Hartman wrote:
> We (the -stable team) are announcing the release of the 2.6.23.3 kernel.
> It contains a number of bugfixes for a number of architecture specific
> issues.
[.4, .5, .6 and .7 follows after .2 and .3]

I've seen the bunch of patches posted for review - split to several
series.  But - out of curiocity - what's the reason to roll each
series into each own stable release?  Can't all .2...7 be combined
into a single release (not counting .8 wich contains urgent security
fixes)?  (I mean, not with already rolled out stuff, but the original
reasoning for split-releasing them (as opposed to split-reviewing))

Thanks.

/mjt
-
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: [ANN] Squashfs 3.3 released

[Michael Tokarev]

Phillip Lougher wrote:
> Hi,
> 
> I'm pleased to announce another release of Squashfs.  This is the 22nd
> release in just over five years.

Thanks Phillip.

A tiny bug[fix] I always forgot to send...  In fs/squashfs/inode.c,
constants TASK_UNINTERRUPTIBLE and TASK_INTERRUPTIBLE are used, but
they aren't sometimes defined (declared in linux/sched.h):

  CC [M]  fs/squashfs/inode.o
fs/squashfs/inode.c: In function 'squashfs_get_cached_block':
fs/squashfs/inode.c:367: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in 
this function)
fs/squashfs/inode.c:367: error: (Each undeclared identifier is reported only 
once
fs/squashfs/inode.c:367: error: for each function it appears in.)
fs/squashfs/inode.c:367: warning: implicit declaration of function 'schedule'
fs/squashfs/inode.c:404: error: 'TASK_INTERRUPTIBLE' undeclared (first use in 
this function)
fs/squashfs/inode.c: In function 'release_cached_fragment':
fs/squashfs/inode.c:499: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in 
this function)
fs/squashfs/inode.c:499: error: 'TASK_INTERRUPTIBLE' undeclared (first use in 
this function)
fs/squashfs/inode.c: In function 'get_cached_fragment':
fs/squashfs/inode.c:522: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in 
this function)
fs/squashfs/inode.c:559: error: 'TASK_INTERRUPTIBLE' undeclared (first use in 
this function)

I'm not exactly sure which config option is "at blame"
(this is an i486-based UP generic-hardware config), but
I'm not interested to know, either.  The following
trivial patch fixes it once for all.

--- linux-2.6.22.orig/fs/squashfs/inode.c   2007-07-12 14:57:22.0 
+0400
+++ linux-2.6.22/fs/squashfs/inode.c2007-07-12 14:57:53.0 +0400
@@ -31,6 +31,7 @@
 #include 
 #include 
+#include 
 #include 

 #include "squashfs.h"


It was needed for v3.2 too.

Thanks.

/mjt
-
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.23.1: mdadm/raid5 hung/d-state

[Michael Tokarev]

Justin Piszcz wrote:
> On Sun, 4 Nov 2007, Michael Tokarev wrote:
[]
>> The next time you come across something like that, do a SysRq-T dump and
>> post that.  It shows a stack trace of all processes - and in particular,
>> where exactly each task is stuck.

> Yes I got it before I rebooted, ran that and then dmesg > file.
> 
> Here it is:
> 
> [1172609.665902]  80747dc0 80747dc0 80747dc0 
> 80744d80
> [1172609.668768]  80747dc0 81015c3aa918 810091c899b4 
> 810091c899a8

That's only partial list.  All the kernel threads - which are most important
in this context - aren't shown.  You ran out of dmesg buffer, and the most
interesting entries was at the beginning.  If your /var/log partition is
working, the stuff should be in /var/log/kern.log or equivalent.  If it's
not working, there is a way to capture the info still, by stopping syslogd,
cat'ing /proc/kmsg to some tmpfs file and scp'ing it elsewhere.

/mjt
-
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.23.1: mdadm/raid5 hung/d-state

[Michael Tokarev]

Justin Piszcz wrote:
> # ps auxww | grep D
> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
> root   273  0.0  0.0  0 0 ?DOct21  14:40 [pdflush]
> root   274  0.0  0.0  0 0 ?DOct21  13:00 [pdflush]
> 
> After several days/weeks, this is the second time this has happened,
> while doing regular file I/O (decompressing a file), everything on the
> device went into D-state.

The next time you come across something like that, do a SysRq-T dump and
post that.  It shows a stack trace of all processes - and in particular,
where exactly each task is stuck.

/mjt
-
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 1/2 ] Add support LZO in cramfs

[Michael Tokarev]

vince kim wrote:
> This is a kernel patch to add support LZO compression in cramfs. 
[]
> --- linux-2.6.23/fs/cramfs/inode.c  2007-10-09 13:31:38.0 -0700
> +++ linux-2.6.23_cramfs_lzo/fs/cramfs/inode.c2007-10-26 
> 14:35:59.0 -0700
> @@ -31,6 +31,8 @@
>  static const struct inode_operations cramfs_dir_inode_operations;
>  static const struct file_operations cramfs_directory_operations;
>  static const struct address_space_operations cramfs_aops; 
> +/* function pointer to uncompress block */
> +static int (* cramfs_uncompress_block) (void *dst, int dstlen, void *src, 
> int srclen);

Shouldn't this pointer be mountpoint-specific?  I mean,
if I've two cramfs images, one using zlib and another
using lzo, the two will not work at the same time.

[]
> --- linux-2.6.23/fs/Kconfig 2007-10-09 13:31:38.0 -0700
> +++ linux-2.6.23_cramfs_lzo/fs/Kconfig  2007-10-26 14:19:01.0 -0700
> @@ -1348,6 +1348,7 @@
> tristate "Compressed ROM file system support (cramfs)" 
> depends on BLOCK
> select ZLIB_INFLATE
> +   select LZO_DECOMPRESS
> help
>   Saying Y here includes support for CramFs (Compressed ROM File
>   System).  CramFs is designed to be a simple, small, and compressed 

Hmm.  How about using modular decompressor? I mean,
it isn't really necessary for a given config to handle
both lzo- and zlib-compressed cramfs images, only one
may be needed, so the other compression library becomes
a useless dependency.  This is especially important for
embedded environments where memory/disk space is limited.
Since you're using a pointer-to-function anyway, it can
be done fully dynamically, by requesting a module to de-
compress the thing at runtime.  Pretty much like it's
done f.e. in crypto/ipsec layer currently.

By the way, your patch is word-wrapped.

/mjt
-
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.23

[Michael Tokarev]

Ingo Molnar wrote:
> * René Rebe <[EMAIL PROTECTED]> wrote:
> 
>> Hi Linus et al.,
>>
>> 2.6.23 does not build with my usual .config on x86_64 and gcc-4.2.1:
[]
> your superblock build failure would be a new and so far unknown build 
> breakage variant - please send the .config you used, and double-check 
> that it's indeed a vanilla 2.6.23 tree.

It's not a vanilla 2.6.23.  In vanilla 2.6.23 there's no lines about
which it complains (struct super_block isn't mentioned in mm.h at all).
It's some external patch that used to work with 2.6.22 but needs to be
updated for 2.6.23 - in my case it was unionfs.

/mjt
-
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.23

[Michael Tokarev]

Jan Engelhardt wrote:
> On Oct 10 2007 14:36, Alexey Dobriyan wrote:
> --- linux-2.6.23/include/linux/mm.h.vanilla
> +++ linux-2.6.23/include/linux/mm.h
> +struct super_block;
>  extern void drop_pagecache_sb(struct super_block *);
>  void drop_pagecache(void);
>  void drop_slab(void);
>
> You probably end up fixing it some other way, but as I do not know this
> file inside out I just wanted to drop a note.
 You have some strange vanilla kernel. 2.6.23 doesn't have this prototype.
>>> The same happens here as well.
>>>
>>> -rw-rw-r--  1 mjt mjt 45488158 Oct  9 20:48 linux-2.6.23.tar.bz2
>>> 2cc2fd4d521dc5d7cfce0d8a9d1b3472  linux-2.6.23.tar.bz2
>>>
>>> (timestamp is in UTC) Downloaded yesterday, 3 hours after an announce,
>>> from http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.tar.bz2 .
>> Strange. Same size, same md5, no super_block in mm.h, though
> 
> Does someone still have the broken tarball?
> 
> There has not been any drop_pagecache_sb anytime between 2.6.23-rc1
> and 2.6.23. drop_pagecache_sb reminds me of reiser4, too.

ghhrm.  That's nonsense.  I found where that struct super_block come
from -- it's from unionfs patches for 2.6.22, which I forgot to
update for 2.6.23 (I just dropped new kernel tarball into my
build directory together with other patches and ran usual build
procedure).  It's a definitely false alarm - the tarball is
fine.

/mjt
-
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.23

[Michael Tokarev]

Alexey Dobriyan wrote:
> On 10/10/07, René Rebe <[EMAIL PROTECTED]> wrote:
>> 2.6.23 does not build with my usual .config on x86_64 and gcc-4.2.1:
>>
>> In file included from fs/drop_caches.c:8:
>> include/linux/mm.h:1210: warning: 'struct super_block' declared inside
>> parameter list
> 
>> --- linux-2.6.23/include/linux/mm.h.vanilla
>> +++ linux-2.6.23/include/linux/mm.h
> 
>> +struct super_block;
>>  extern void drop_pagecache_sb(struct super_block *);
>>  void drop_pagecache(void);
>>  void drop_slab(void);
>>
>> You probably end up fixing it some other way, but as I do not know this
>> file inside out I just wanted to drop a note.
> 
> You have some strange vanilla kernel. 2.6.23 doesn't have this prototype.

The same happens here as well.

-rw-rw-r--  1 mjt mjt 45488158 Oct  9 20:48 linux-2.6.23.tar.bz2
2cc2fd4d521dc5d7cfce0d8a9d1b3472  linux-2.6.23.tar.bz2

(timestamp is in UTC) Downloaded yesterday, 3 hours after an announce,
from http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.tar.bz2 .

/mjt
-
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: howto boost write(2) performance?

[Michael Tokarev]

Boaz Harrosh wrote:
[]
> If your target is a SCSI target you can gain up to 15% by using
> sg. Search on the net for the "sg utils" package. The source code
> of sg_dd and others are a grate example of how to do it.
> 
> Other wise O_DIRECT is your friend. Also look for asynchronous
> I/O so you have a few pending IO buffers to keep the pipes full.

What's the advantage of sg_io over O_DIRECT to the block device?
I think sg devices are being (slowly?) obsoleted since most stuff
which has been in sg now works over normal block device, no?
At least, I haven't seen any significant difference between
sg_dd and dd with oflag=direct.

Thanks.

/mjt
-
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: Various problems on Axis 700 Lite VIA C7

[Michael Tokarev]

Guennadi Liakhovetski wrote:
> Hi
> 
> Ok, after a day of biseting, it turns out to be a compiler problem. The 
> gcc-3.3.5 produces at least these two problems (Oops on i2c-viapro probe 
> and disabled IRQs in USB), whereas 4.1.2 has no problem so far. Up to now 
> 3.3.5 had no problem compiling 2.6.20+ kernels here, for example, for P-II 
> SMP. Does it at all look realistic that such "random" run-time problems 
> are caused by a miscompilation?...

I can't say about compilers (but it looks to me somewhat possible still),
but I can say a bit about the platform/CPU.  You can find my thread titled
"VIA C7 anyone" from several months back in archives - that was my first
expirience.  Since that, I received several emails from others with similar
problems.

The things is that at least boards I'm using, but I suspect it's CPU not
the board, -- are somewhat... flaky, so to say, and their reliability (or
even ability to work) depends on several factors, starting with production
conditions (environment at a time when it has been produced) and up to
various thermal factors.

It seems there's quite significant percentage of C7-based boards that are
flaky/unreliable, replacing one with another from the same batch usually
fixes the prob.

Next, some boards are VERY sensitive to themperature, and their thermal
sensors are WRONG - it seems - 100% of the time, showing ~20% less
themperature than it really is (say, when the sensor shows 35 degrees
celsius, the themp really is about 45..50 degrees) -- when the themperature
(on SOME samples) grows above 40 degrees, the system becomes unreliable
and may crash randomly here and there.

More, due to geometry of the CPU chip, with very small square area that
touches the headsink and relatively large headsink, it's sometimes enouth
to just touch the headsink so it positions wrongly, with bad thermo-contact
between the CPU and the headsink, resulting in high themperatures and
system instability.

And even more interesting -- it seems that some sequence of instructions
are more frequently misinterpreted (under "abnormal" conditions above)
than other sequences doing the same thing.  That is, the same program
compiled with gcc-3.4 may work almost 100% correct while the same thing
compiled with gcc-4.1 may almost alway fail (usually due to segmentation
fault), or exactly the opposite.

So umm ;)

I'm running VIA C7 on this machine where I'm typing right now - no single
glitch since the time I replaced the failing one (at a time of mentioned
thread), it's rock-solid.  I even removed the fan from the headsink - the
themp grows up to 70..80 degrees celsius (according to lm-sensors, so actual
themperature should be higher) when I run CPU-intensive apps, and nothing
breaks.  Previous motherboard which I replaced (the same model, from the
same batch) was breaking randomly, but worked relatively stable when
placed on the street and with a large "external" fan used in rooms for
ventilation... ;)  even without any load when onboard sensors showed 35
degrees.

That to say - it may be some miscompilations, but may be some probs with
hardware itself.  If you can, try to reproduce the same on another board
(I just tried to boot 2.6.23-rc5 on this machine, compiled for PIII CPU
using gcc-4.1.2 (no other version installed, sorry) - no issues so far).

And no, I'm not trying to say "don't use ViA C7" etc -- I just love this
my box, it's very good, powerful enouth and quiet.  Just be prepared for
some... issues, which happens - rarely but still.

/mjt

-
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: F_DUPFD_CLOEXEC implementation

[Michael Tokarev]

Al Viro wrote:
> On Mon, Oct 01, 2007 at 11:07:15AM +0100, Denys Vlasenko wrote:
>> Also attached is ndelaytest.c which can be used to test that
>> send(MSG_DONTWAIT) indeed is failing with EAGAIN if write would block
>> and that other processes never see O_NONBLOCK set.
>>
>> Comments?
> 
> Never send patches during or approaching hangover?
>   * it's on a bunch of cyclic lists.  Have its neighbor
> go away while you are doing all that crap => boom
>   * there's that thing call current position...  It gets buggered.
>   * overwriting it while another task might be in the middle of
> syscall involving it => boom
>   * non-cooperative tasks reading *in* *parallel* from the same
> opened file are going to have a lot more serious problems than agreeing
> on O_NONBLOCK anyway, so I really don't understand what the hell is that for.

Good summary... ;)

But for the last part of the last item - sometimes, definitely more than
once, I wondered why there's no equivalent to recv(MSG_DONTWAIT) for
non-sockets -- why for sockets it's as simple as adding an option (a
single bit), while for all the rest it requires two fcntl calls...
Sometimes it's handy. ;)

Not that I'm arguing for or against such a feature anyway..

/mjt
-
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: renaming kernel devices [was: VIA EPIA EK: strange eth dev numbering]

[Michael Tokarev]

Jan Engelhardt wrote:
> On Aug 2 2007 16:56, Michael Tokarev wrote:
>>>> I already can see comments from udev/sysfs maintainers here: "naming
>>>> is a policy which does not belong to kernel".  It's a bullshit, because
>>>> kernel too has to use SOME way to name things,
>>> (1) The kernel starts with ethX
>>> (2) udev renames it to something else
>>> (3) kernel uses new name too ("ni0: link down")
>> And now tell me please how can I connect two messages from dmesg:
>>
>> eth0: Tigon3 [partno(BCM95721) rev 4201 PHY(5750)] (PCI Express) 
>> 10/100/1000Base-T Ethernet 00:14:5e:5d:18:26
>> nic10: Link is up at 100 Mbps, full duplex.
> 
> Generally, the "link is xyz" message comes directly after loading the module,
> so it should be eth0 before udev gets a chance to rename it. Or maybe not -
> in which case, well, you're literally fubared, and your distro should put a
> "renamed A to B" into syslog.

Yes, first message is generated before udev has a chance to act.
And no, I just don't use udev, and I hope very much that it will
not become required (it is slowly becoming - for example, some
packages on Debian (like xen for example) now explicitly depends
on udev - but so far  I managed to satisfy this dependency by
other means).

>> What I wanted to say (here with network devices, and with disk names
>> and everything else) is -- as long as the device is here (plugged in
>> but not yet unplugged), I want it to have the same "primary" name in
>> kernel and in userspace, so that everything
> 
> Oh I think it already has a "primary name" today --
> 
> $ readlink /sys/class/net/eth0/device
> ../../../../../devices/pci:00/:00:04.0
> 
> there is your primary name, and your secondary name is ethZ. :)

This primary name isn't at all useful - I can't ifconfig or fdisk it,
and it's not shown in log/dmesg either.

/mjt
-
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: VIA EPIA EK: strange eth dev numbering

[Michael Tokarev]

Jan Engelhardt wrote:
> On Aug 2 2007 12:56, Herbert Rosmanith wrote:
>>> On Aug 2 2007 12:42, Herbert Rosmanith wrote:
>>> There never *were* days when eth0 remained eth0 across such changes.
>> but there *were* days when eth0 was eth0, if the kernel reports it as such.
>> now there is no eth0 at all. if I see an "eth0" from dmesg, I expect
>> it to be present.
> 
> Wait, you forget that something may change the name. That dmesg message
> from 1 second ago does not need to be valid anymore, just as anything
> else in this world.

That was my argument - there should be no way to *change* the name, but
to give an alias(es) - entirely different thing.

Yes, if a device is replugged during that one second, it's another
at least "instance" of that device - similar to 'ifindex' field in
interface description (not shown by ifconfig but shown by `ip link'),
or to usb endpoint numbers which gets incremented each time one
plug something in.

But as long as the device is connected, it should have the same
name - that's my key point.  You may change its aliases as you
wish, but not the "primary name".

[]
>> the problem with this device renaming in my case was that other software,
>> in particular dhcpcd, didnt get any lease, because (obviously?) dhcpcd
>> on the other hand _still_ seemed to look for eth0, and thus, after
>> booting, there was no network configured at all.
> 
> So blame your distro for not integrating udev correctly with dhcp-client.
> I can only speak for suse, where you define BOOTPROTO=dhcp for an
> interface. Then, on /etc/init.d/network, every interface that has a
> configuration file gets run, so you never see what ethX udev picked for
> the day, but things still work. That's good^TM.

Again, this is questionable - the integration part, right way to it,
that is.

If - recalling my "naming scheme" with kernel ethX (which may change each
boot or even at runtime, OR may not change at all if I don't replug
devices), and nicN which is based on particular device's MAC address, --
I configured dhcp to listen on eth0, I assume it's the first network
card found by the system, whatever it is.  In this case, if I replaced
the card (because previous one was faulty etc), it will continue to
work (provided no other renames was done) without renames done by
udev, and will break with current udev behaviour.  But if I configured
dhcp to listen on *this* NIC with *this* serial number and MAC address,
current udev behaviour is right - the system just assumes that this
particular card isn't here (yet?) and hence dhcp shouldn't run on it.

You see - we again have two names - "first interface found by kernel"
and "this particular card with this serial number", and both of them
are useful.

Partially this issue can be solved by - say - kudzu asking for a
name if it finds new hardware (we'll answer it with the name our
replaced card had) - but such behaviour is out of the question
because system startup scripts should not generally ask "random
questions".

/mjt
-
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: renaming kernel devices [was: VIA EPIA EK: strange eth dev numbering]

[Michael Tokarev]

Jan Engelhardt wrote:
> On Aug 2 2007 15:23, Michael Tokarev wrote:
>> Herbert Rosmanith wrote:
>>>> On Aug 2 2007 12:42, Herbert Rosmanith wrote:
>>>> There never *were* days when eth0 remained eth0 across such changes.
>> []
>>> of course, that's problem with gentoo, not with the kernel.
>> To me it'd be a problem, but I don't run udev (more, I hate udev ;)
>>
>> By the way, this very approach (renaming "new" eth0 interface to the next
>> "free" ethX) seems to be flawed.
> 
> It does not rename ethX to the "next free" one, but to a _persistent_ one.
> If it were a "next free" thing, then removing a card would shuffle all
> your eth around again (and invalidate your iptables rules at the same
> time, to note).

Note I said ``"new" eth0'' -- i.e, when udev sees new NIC (with new, yet
unknown to this system, MAC address), it assigns it a "next free" (from
it's persistent names list), now persistent, ethN.

Shuffling rest of the interfaces if eth0 is removed and no this persistent
naming present is obvious, including invalidating iptable rules and
breaking dhcp configuration and other stuff.  But I was referring to
something different -- below.

>> first of all, I'd turn this behaviour off by default, but only when the
>> user asked me to do so - say, when a new NIC is found, ask a user what's
>> the name he wants it to be known as.  *Or* choosed different "basename"
>> for the renamed devices.  So that in-kernel eth0 becomes, say, nicX
>> instead of ethX - to make things explicit.  Current way is just too
>> confusing, when eth0 quietly becomes eth2 or whatnot.
> 
> Remember that persistent names also need to provide means for
> hot-pluggable devices. Say your eth0 was a wireless, then you surely would
> _not ever_ want that on removal of eth0, all other cards step one down
> (eth1,eth2,ethN->eth0,eth1,ethN-1). Unfortuantely, I think it is hard (if
> not that, then it's a lot of code) to distinguish coldplugged vs
> hotplugged devices.

There's really no need to distinguish them (and by the way, wireless !=
hot-pluggable.  There are PCI wireless cards (non-hotplug), and there
are, say, PCMCIA or USB ethernet cards (hotplug)).

Well, I see your point here (I think) -- by assigning names to hotplug
devices from a different namespace (hpethN vs ethN for example) we will
stop shuffling *everything* (without persistent names like udev does) -
but that doesn't really help anyway because of module loading order for
example, and because non-hotplug devices (like PCI) can be missing
(and new added) too on next reboot.

What I mean is -- if I, as a user, care about interface (or other)
names when I replug my NICs (if I ever do that in the first place),
I can assign names to them explicitly (and some programs that are
running at system startup - like kudzu on redhat for example - may
just ask me when finding something new), and THOSE explicitly set
names should be persistent for sure.  Preferrable they will be in
different namespace (not named as ethX but, say, lan or isp or
segment12 - user chooses the name).  And nothing will break
(iptables or dhcp or whatnot) when using THOSE persistent names.

When I don't care, usually I don't have many interfaces to worry
about, either.  But in this case it's expectable that names of
existing interfaces after removing one may change.

Kernel uses SOME names for the interfaces anyway when it boots up
(more on this below).  If - in case I don't care or just didn't
know (which is more often I think) about renumbering, udev by
default MAY assign persistent names like it does (using nicX
scheme), but it'd be better (IMHO anyway) that those names will
be implemented as aliases, not as rename...

>> And second half, which is more important here, is to always keep kernel
>> names, and create aliases named by user (or automatic nicX scheme).  This
>> is fundamental -- applies to every device on the system.
> 
> This is easy. Edit /lib/udev/rename_netiface to always hand out "nicX"
> regardless of whether the input device was ethX, trX, raX, wlanX or
> whatever.

Again, the key point here in the "alias" thing.  Whatever basename will
be used is irrelevant, but I wanted to preserve BOTH names...

>> For example, if kernel says it has disk named "sda", it should be
>> accessible as /dev/sda (and /sys/block/sda, whatever),
> 
> Note that /dev/sda is not persistent either.

Yes it's not, but during kernel lifetime (from boot to shutdown) it
at least MAY be persistent, unless it's a removable device which gets
re-plugged.

>> and any alternative names ("boot disk", disk-serial-12345 etc

renaming kernel devices [was: VIA EPIA EK: strange eth dev numbering]

[Michael Tokarev]

Herbert Rosmanith wrote:
>> On Aug 2 2007 12:42, Herbert Rosmanith wrote:
>> There never *were* days when eth0 remained eth0 across such changes.
[]
> of course, that's problem with gentoo, not with the kernel.

Whenever it's a problem or not is questionable too.  I mean,
ethX order depends on module loading order, or on PCI slot
number, or whatnot.  So userspace (udev) tries to compensate
(sometimes its own design.. issues - module loading order
in this case).  It's worse if you'll have eth0 and eth1
swapped on every boot depending on tiny module loading
time differences.

To me it'd be a problem, but I don't run udev (more,
I hate udev ;)

By the way, this very approach (renaming "new" eth0
interface to the next "free" ethX) seems to be flawed.

If I'd were to implement this scheme, I'd do two things
instead of one currently done, and I'd do whatever is
currently done by udev a bit differently (but second
half requires (minor) kernel mods):

first of all, I'd turn this behaviour off by default,
but only when the user asked me to do so - say, when
a new NIC is found, ask a user what's the name he
wants it to be known as.  *Or* choosed different
"basename" for the renamed devices.  So that
in-kernel eth0 becomes, say, nicX instead of
ethX - to make things explicit.  Current way is just
too confusing, when eth0 quietly becomes eth2 or
whatnot.

And second half, which is more important here, is to
always keep kernel names, and create aliases named
by user (or automatic nicX scheme).  This is fundamental --
applies to every device on the system.  For example,
if kernel says it has disk named "sda", it should be
accessible as /dev/sda (and /sys/block/sda, whatever),
and any alternative names ("boot disk", disk-serial-12345
etc yadda) should be symlinks in /dev.  Ie, general rule
is to remove *ALL* "NAME" statements from udev.conf file
and use "SYMLINK" instead.

For network interfaces, ifconfig -a may omit the kernel
names from the listing (but in this case, say, ifconfig -aa
should still show them), or alternatively it may show
something like

eth0  Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX  Name nic10
  ^^
and both
  ifconfig eth0 blablabla
and
  ifconfig nic10 blablabla
will work identically.

I.e., the general rule is: kernel has some naming scheme,
because it has to name things in dmesg, in /sys, in /proc/partitions
etc *somehow*.  And those "kernel names" should always be accessible,
and stay here at least up to the next reboot.  All the rest are
"aliases", alternative names for "kernel names".

I already can see comments from udev/sysfs maintainers here: "naming
is a policy which does not belong to kernel".  It's a bullshit, because
kernel too has to use SOME way to name things, and either we should
teach it to use our names EVERYWHERE (including early-boot printk()),
or accept the fact that any userspace naming (the "policy") should
be implemented as aliases for kernel names, not as renames.

(And no, things like "I/O error on SCSI device 8:32 sector XXX" is even
worse - I don't want to care which numbers are used for the devices,
I want to see which sdX it is).

/mjt
-
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: VIA EPIA EK: strange eth dev numbering

[Michael Tokarev]

Herbert Rosmanith wrote:
> hi,

Hello.

[]
> When doing the module load, the kernel says:
> eth0: VIA Rhine III at 0x1d000, 00:40:63:ee:96:56, IRQ 17.
> eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 
> 45e1.
> eth1: VIA Rhine II at 0x1ec00, 00:40:63:ee:96:55, IRQ 18.
> eth1: MII PHY found at address 1, status 0x7849 advertising 05e1 Link 
> .
[]
> it took a while until, just out of a feeling in my stomach, I tried "ifconfig 
> -a",
> and surprise, surprise, the ethernet devices were in fact there, *but* there
> names where eth2 and eth3.
[]
> pretty strange?! I dont think this is the correct behaviour, is it?

Strange or not, correct or not - depends on the point of view.

The key word here is "udev" - check your udev rules.  Since some time
ago udev on some distros comes with rules to give persistent device
names for network interfaces.  Some time ago you had eth0 and eth1
with different hardware, and udev remembered this fact somewhere.
Now it sees new hardware, and gives it consecutive numbers, renaming
kernel devices.

/mjt
-
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: SCSI vs SATA

[Michael Tokarev]

BuraphaLinux Server wrote:
> Hello,
> 
>I have had a hard time determining if /dev/sda is SCSI or SATA
> from my boot scripts.  It matters for smartd which needs an added
> parameter -d sat in the configuration file for SATA drives.  Finally I

Just FYI:  Recent smartmontools (5.36+) can figure this out automagically.

/mjt
-
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/

[trivial] [2.6.22 patch] Remove one more leftover reference to devfs.

[Michael Tokarev]

One more reference to devfs in arch/i386/Kconfig, microcode driver description.

Signed-Off-By: Michael Tokarev <[EMAIL PROTECTED]>

--- linux-2.6.22/arch/i386/Kconfig.orig 2007-07-09 03:32:17.0 +0400
+++ linux-2.6.22/arch/i386/Kconfig  2007-07-11 23:35:45.0 +0400
@@ -452,8 +452,7 @@
tristate "/dev/cpu/microcode - Intel IA32 CPU microcode support"
select FW_LOADER
---help---
- If you say Y here and also to "/dev file system support" in the
- 'File systems' section, you will be able to update the microcode on
+ If you say Y here, you will be able to update the microcode on
  Intel processors in the IA32 family, e.g. Pentium Pro, Pentium II,
  Pentium III, Pentium 4, Xeon etc.  You will obviously need the
  actual microcode binary data itself which is not shipped with the
-
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: VIA C7 / VIA PC-1 (PC2500) anyone?

[Michael Tokarev]

Michael Tokarev wrote:
> I bought a VIA PC2500 board a few days ago - this
> new series of their mobos,
> 
[]
> It works generally - it boots, I can run my usual apps
> etc.  But on a random (yet frequent) basis it segfaults
> here and there.  For example:

Replying to my old message.  Yes the mobo crashed like
crazy and was very unstable.  I returned it back to the
store and got a replacement, exactly the same thing.
Which, unlike the previous one, works flawlessly so
far - at least I can't reproduce any crashes anymore.
More -- CPU temperature, which - according to the
lm_sensors values, was jumping somewhere between
40C and 65C, is now at 24C at idle and 35C under
high load.  CPU headsink is MUCH cooler on this
mobo, while the fan is working exactly the same.
And no more themp jumps as before.  So it turns out
I just had a bad (defected) mobo, nothing to do with
kernel  Oh well.

(But BIOS on this mobo is a bit crappy still.  Not
fatal but not nice either.)

/mjt
-
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: Some NCQ numbers...

[Michael Tokarev]

Dan Aloni wrote:
> On Thu, Jun 28, 2007 at 02:51:58PM +0400, Michael Tokarev wrote:
>> [..]
>> Test machine was using MPTSAS driver for the following card:
>>   SCSI storage controller: LSI Logic / Symbios Logic SAS1064E PCI-Express 
>> Fusion-MPT SAS (rev 02)
>>
>> Pretty similar results were obtained on an AHCI controller:
>>   SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA 
>> Storage Controller AHCI (rev 01)
>> on another machines.
> 
> Are you sure that NCQ was enabled between the controller and drive? 
> Did you verify this? I know about some versions that disable NCQ 
> support internally in their firmware (something to do with bugs in
> error handling).

The next obvious question is: how to check/verify this?

/mjt
-
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: Some NCQ numbers...

[Michael Tokarev]

Tejun Heo wrote:
> Hello,
> 
> Michael Tokarev wrote:
>> Well.  It looks like the results does not depend on the
>> elevator.  Originally I tried with deadline, and just
>> re-ran the test with noop (hence the long delay with
>> the answer) - changing linux elevator changes almost
>> nothing in the results - modulo some random "fluctuations".
> 
> I see.  Thanks for testing.

Here are actual results - the tests were still running when
I replied yesterday.

Again, this is Seagate ST3250620AS "desktop" drive, 7200RPM,
16Mb cache, 250Gb capacity.  The tests were performed with
queue depth = 64 (on mptsas), drive write cache is turned
off.

noop scheduler:

BlkSz Trd linRd rndRd linWr rndWr  rndR/W
   4k   1  12.8   0.3   0.4   0.3   0.1/ 0.1
4 0.3 0.3   0.1/ 0.1
   32 0.3 0.3   0.1/ 0.1
   8k   1  24.6   0.6   0.9   0.6   0.3/ 0.3
4 0.6 0.6   0.3/ 0.3
   32 0.6 0.6   0.3/ 0.3
  16k   1  41.3   1.2   1.8   1.1   0.6/ 0.6
4 1.2 1.1   0.6/ 0.6
   32 1.2 1.1   0.6/ 0.6
  32k   1  58.4   2.2   3.5   2.1   1.1/ 1.1
4 2.3 2.1   1.1/ 1.1
   32 2.3 2.1   1.1/ 1.1
 128k   1  80.4   8.1  12.5   7.2   3.8/ 3.8
4 8.1 7.2   3.8/ 3.8
   32 8.1 7.2   3.8/ 3.8
1024k   1  80.5  33.9  33.8  24.5  14.3/14.3
434.124.6  14.3/14.2
   3234.224.6  14.4/14.2

deadline scheduler:

BlkSz Trd linRd rndRd linWr rndWr  rndR/W
   4k   1  12.8   0.3   0.4   0.3   0.1/ 0.1
4 0.3 0.3   0.1/ 0.1
   32 0.3 0.3   0.1/ 0.1
   8k   1  24.5   0.6   0.9   0.6   0.3/ 0.3
4 0.6 0.6   0.3/ 0.3
   32 0.6 0.6   0.3/ 0.3
  16k   1  41.3   1.2   1.8   1.1   0.6/ 0.6
4 1.2 1.1   0.6/ 0.6
   32 1.2 1.1   0.6/ 0.6
  32k   1  57.7   2.3   3.4   2.1   1.1/ 1.1
4 2.3 2.1   1.1/ 1.1
   32 2.3 2.1   1.1/ 1.1
 128k   1  79.4   8.1  12.5   7.2   3.8/ 3.8
4 8.1 7.3   3.8/ 3.8
   32 8.2 7.3   3.9/ 3.8
1024k   1  79.4  33.7  33.8  24.5  14.2/14.2
433.924.6  14.3/14.2
   3233.424.4  17.0/10.5

[]
>> By the way, Seagate announced Barracuda ES 2 series
>> (in range 500..1200Gb if memory serves) - maybe with
>> those, NCQ will work better?
> 
> No one would know without testing.

Sure thing.  I guess I'll set up a web page with all
the results so far, in a hope someday it will be more
complete (we don't have many different drives to test,
but others do).

By the way.  Both SATA drives we have are single-platter
ones (with 500Gb models they've 2 platters, and 750Gb
ones are with 3 platters), while all SCSI drives I
tested have more than one platters.  Maybe this is
yet another reason for NCQ failing.

And another note.  I heard somewhere that Seagate for
one prohibits publishing of tests like this, however
I haven't signed any NDAs and somesuch when purchased
their drives in a nearest computer store... ;)

>> Or maybe it's libata which does not implement NCQ
>> "properly"?  (As I shown before, with almost all
>> ol'good SCSI drives TCQ helps alot - up to 2x the
>> difference and more - with multiple I/O threads)
> 
> Well, what the driver does is minimal.  It just passes through all the
> commands to the harddrive.  After all, NCQ/TCQ gives the harddrive more
> responsibility regarding request scheduling.

Oh well, I see :(

/mjt
-
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: Some NCQ numbers...

[Michael Tokarev]

Tejun Heo wrote:
> Michael Tokarev wrote:
[]
>> A test drive is Seagate Barracuda ST3250620AS "desktop" drive,
>> 250Gb, cache size is 16Mb, 7200RPM.
[test shows that NCQ makes no difference whatsoever]

> And which elevator?

Well.  It looks like the results does not depend on the
elevator.  Originally I tried with deadline, and just
re-ran the test with noop (hence the long delay with
the answer) - changing linux elevator changes almost
nothing in the results - modulo some random "fluctuations".

In any case, NCQ - at least in this drive - just does
not work.  Linux with its I/O elevator may help to
speed things up a bit, but the disk does nothing in
this area.  NCQ doesn't slow things down either - it
just does not work.

The same's for ST3250620NS "enterprise" drives.

By the way, Seagate announced Barracuda ES 2 series
(in range 500..1200Gb if memory serves) - maybe with
those, NCQ will work better?

Or maybe it's libata which does not implement NCQ
"properly"?  (As I shown before, with almost all
ol'good SCSI drives TCQ helps alot - up to 2x the
difference and more - with multiple I/O threads)

/mjt
-
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/