Bug 8192

Подтверждаю. 

Мать: ASUS A8V-E DELUXE
Видео: Gigabyte GF 6600 GT
Монитор: Samsung SyncMaster 753DF, подключен по обычному VGA DSUB.

# pciscan -c003 -p
Recommended driver     Description
------------------     -----------
/sys/board/bus/pci/0000/02/00/0/        Card:Generic VESA compatible
/sys/board/bus/pci/0000/02/00/0/        Card:NVIDIA GeForce (proprietary)
/sys/board/bus/pci/0000/02/00/0/        bus:02
/sys/board/bus/pci/0000/02/00/0/        classname:VGA compatible controller
/sys/board/bus/pci/0000/02/00/0/        classpath:003:00:00
/sys/board/bus/pci/0000/02/00/0/        cmd:0007
/sys/board/bus/pci/0000/02/00/0/        dev:00
/sys/board/bus/pci/0000/02/00/0/        device:0140
/sys/board/bus/pci/0000/02/00/0/        driver:15:nvidia
/sys/board/bus/pci/0000/02/00/0/        driver:24:nvidiafb
/sys/board/bus/pci/0000/02/00/0/        func:0
/sys/board/bus/pci/0000/02/00/0/        hwid:E9036BBD63854E81
/sys/board/bus/pci/0000/02/00/0/        irq:24
/sys/board/bus/pci/0000/02/00/0/        name:nVidia Corporation NV43 [GeForce
6600 GT]
/sys/board/bus/pci/0000/02/00/0/        pciclass:300
/sys/board/bus/pci/0000/02/00/0/        pcisubclass:0000
/sys/board/bus/pci/0000/02/00/0/        rev:a2
/sys/board/bus/pci/0000/02/00/0/        slot:0000:02:00.0
/sys/board/bus/pci/0000/02/00/0/        status:0010
/sys/board/bus/pci/0000/02/00/0/        subdevice:3125
/sys/board/bus/pci/0000/02/00/0/        subvendor:1458
/sys/board/bus/pci/0000/02/00/0/        vendor:10de

ddcprobe и x11createconfig так же падают с сегфолтом.

Проблема, кстати, похоже, скорее в ASUSовских материнках, потому как другие GF
6600 и даже точно такой же гигабайтовский 6600 GT на других матерях у меня
работали идеально.

ASUS EN6600Silencer   
# pciscan -p -c003   
Recommended driver     Description   
------------------     -----------   
/sys/board/bus/pci/0000/01/00/0/        Card:Generic VESA compatible   
/sys/board/bus/pci/0000/01/00/0/        Card:NVIDIA GeForce (proprietary)   
/sys/board/bus/pci/0000/01/00/0/        bus:01   
/sys/board/bus/pci/0000/01/00/0/        classname:VGA compatible controller   
/sys/board/bus/pci/0000/01/00/0/        classpath:003:00:00   
/sys/board/bus/pci/0000/01/00/0/        cmd:0007   
/sys/board/bus/pci/0000/01/00/0/        dev:00   
/sys/board/bus/pci/0000/01/00/0/        device:0141   
/sys/board/bus/pci/0000/01/00/0/        driver:15:nvidia   
/sys/board/bus/pci/0000/01/00/0/        driver:24:nvidiafb   
/sys/board/bus/pci/0000/01/00/0/        func:0   
/sys/board/bus/pci/0000/01/00/0/        hwid:2A72EEC145A6FE11   
/sys/board/bus/pci/0000/01/00/0/        irq:18   
/sys/board/bus/pci/0000/01/00/0/        name:nVidia Corporation NV43 [GeForce   
6600]   
/sys/board/bus/pci/0000/01/00/0/        pciclass:300   
/sys/board/bus/pci/0000/01/00/0/        pcisubclass:0000   
/sys/board/bus/pci/0000/01/00/0/        rev:a2   
/sys/board/bus/pci/0000/01/00/0/        slot:0000:01:00.0   
/sys/board/bus/pci/0000/01/00/0/        status:0010   
/sys/board/bus/pci/0000/01/00/0/        subdevice:8199   
/sys/board/bus/pci/0000/01/00/0/        subvendor:1043   
/sys/board/bus/pci/0000/01/00/0/        vendor:10de   
   
  
нужна ли еще какая-нибудь информация по железу?  
еще смущает это:  
Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard  
хотя мама ASUS A8N-E 
подозреваю, что это просто обозначение, не более, но все же...  

По хорошему - нужен удаленный доступ на эту машину. Если невозможно, то похоже
придется кому-то собирать libvbe с отладкой и тестировать.

(In reply to comment #4) 
> По хорошему - нужен удаленный доступ на эту машину. Если невозможно, то 
похоже 
> придется кому-то собирать libvbe с отладкой и тестировать. 
>  
 
боюсь, что с удаленным доступом на мою машимнку действительно не получится, по 
ряду причин, а вот предоставить доп.информацию согласно инструкциям - это 
возможно. 
 

(In reply to comment #2)   
> Проблема, кстати, похоже, скорее в ASUSовских материнках, 
   
может тут больше зависимость от CPU? AMD... обе эти платы под процессоры AMD на  
сокете S939...  
   

увеличил приоритет.

Начал копаться. В итоге выяснено:

1. ddcprobe-2.0 была пересобрана и слинкована статически со всеми библиотеками.
После этого запущена под gdb и получился вот такой stack trace:

#0  0x3ab3e2ed in memset () from /lib/libc.so.6
#1  0x0804a1e2 in vbe_check_vbe_info__old (info=0x0) at vbe.c:205
#2  0x0804a4cf in get_edid__old (edid=0xaf8ba0a0 "\024\205\004\b\024\213\020�\001")
    at vbe.c:294
#3  0x0804a5a6 in get_edid (edid=0xaf8ba0a0 "\024\205\004\b\024\213\020�\001")
at vbe.c:316
#4  0x0804a7f6 in get_edid_info () at vbe.c:379
#5  0x080491a6 in main (argc=1, argv=0xaf8ba2d4) at ddcprobe.c:102

Там есть 2 этапа, сначала анализиуется VBE, потом EDID - вот на тесте EDID оно и
падает. Модели, прочие имена и видеорежимы детектятся нормально - вернее, не
нормально - потому что все пустое, численно верный только размер памяти (128М),
но по крайней мере не падает. А вот из get_edid_info() - все, не возвращается. 

Любопытный факт: все упирается на самом деле, конечно, не в тот memset, о
котором идет речь, а в хитрый вызов LRMI_alloc_real(), который возвращает
указатель на абсолютно невменяемую область памяти, тогда как по идее -
декларируется, что он должен: "Allocate real mode memory.  The returned block is
paragraph (16 byte) aligned".

Совсем любопытный факт: этот вызов единожды используется до этого на этапе
детектов VBE. При этом в тот первый раз он отрабатывает вменяемо, а во второй -
получается такая вот ерунда. Видимо, где-то что-то съезжает между первым и
вторым вызовом и портит память или стек.

2. ddcprobe-1.0 была таким же образом пересобрана и запущена. Получается следующее:

# ./ddcprobe
vbe: VESA 3.0 detected.
oem:
vendor:
product:
memory: 131072kb
edidfail

Но крайней мере не падает - и это есть, видимо, искомое поведение ddcprobe на
этой платформе. Сдетектить оно ничего не сможет, видимо, потому, что там все
как-то сложнее, но по крайней мере не сегфолтится. Смотрим, что менялось с 1.0
на 2.0. Сейчас приложу почищенный дифф к письму, дальше будут мои мысли на тему,
что там такое...

Created attachment 1286 [details]
Разница между ddcprobe 1.0 и 2.0

Итого видим, что было 2 относительно независимых исправления:

1. Изменение в int10/i10_vbios.c;
2. Множетственные изменения на тему перехода от статичных буферов char[] к char*
для строчек;

Откатываем изменение номер 1 - оно начинает работать так же, как и ddcprobe-1.0.
Смотрим, от чего оно зависит - от того, вытащился ли из /dev/mem вменяемый Video
BIOS. В случае, видимо, этой комбинации материнки и видеокарточки - вменяемого
Video BIOS не получается, хотя я вот смотрю первые байты в отладчике,
относительно похоже:

00000000 55 AA 77 EB │ 4B 37 34 30 │ 30 E9 4C 19 │ 77 CC 56 49 │ 44 45 4F 20 
UªwëK7400éL.wÌVIDEO
00000014 0D 00 00 00 │ C4 00 D0 10 │ 00 00 49 42 │ 4D 20 56 47 │ 41 20 43 6F 
....Ä.Ð...IBM VGA Co
00000028 6D 70 61 74 │ 69 62 6C 65 │ 01 00 00 00 │ 80 11 52 97 │ 31 31 2F 30 
mpatible......R.11/0
0000003C 39 2F 30 34 │ 00 00 00 00 │ 00 00 00 00 │ 00 10 00 00 │ 00 00 00 00 
9/04................

Собственно, такое решение устроит?

Без изменения:
-            if(chksum((CARD8 *) V_BIOS)) ok = 1;
+            chksum((CARD8 *) V_BIOS);
+	    ok = 1;
На ноутах, где запускается 855resolution будет тот самый segfault. Собственно,
для них этот фикс и делался.

Странно. На самом деле похоже что падает где-то дальше.. ибо BIOS явно где-то
крив (может быть не проходит контрольная сумма или ещё что-то?)

В первом патче падать по идее не должен.

Итого, имеем пока вариант либо падать на одних карточках, либо на других %)

Варианты решения, как мне видится:

1. Правильный - зафиксить 855resolution на тему исправления checksum в shadow,
который он правит. Заодно разобраться в структуре Video BIOS и предложить патчи
на эту тему для OEM.
2. Тоже правильный - разобраться, что за Video BIOS находится с этими GF6600,
чем он такой "неправильный" (может быть, там эти разрешения по-другому лежат?),
или может это находится какая-то недораспакованная копия shadow, а распакованная
лежит по другим адресам дальше?..
3. Хак - сделать workaround для двух этих схем - как-то детектить предыдущий
вызов 855resolution и в случае 

Так как по сути проблема не ALT-specific, я бы рекомендовал попинать апстрим?..

upstream к сожалению в нашем случае - Mouse ;-)

Мы его конечно попинаем, но каких то результатов врятли добъемся. 

Предлагаю как вариант детектить наличие i810 карты... и считать что на них на
всех запускается i855resolution.

Ну вот не надо. Upstream - Mandriva.
Вот им и написать.

Короче это нужно срочно фиксить.. каким способом - надо думать. 

mainstream кстати отпадает - они теперь используют /proc/acpi/video
а я ещё не разу не видел что бы это работало (через ACPI)

Created attachment 1337 [details]
вывод strace

Аналогичные падения наблюдаются еще на одной машине. pciscan ее прилагается в
третьем аттаче

Created attachment 1338 [details]
pciscan проблемной машины

дело явно не в машине, а в video bios.

Дело во всем в целом. Некий Video BIOS распаковывается на конкретной материнской
плате с конкретным BIOS'ом, как-то (обычно в распакованном уже виде) попадает в
shadow. Комбинация нетрадиционного (или просто глючного?) Video BIOS и странно
(а может и нет?) работающего BIOS материнки дает в итоге такой результат. Надо
просто решить, как бы его обрабатывать.

Для начала устроил бы любой вариант, исключающий падения.

Т.е. - отуствие информации - тоже информация ;-)

Если нет EDID, то мы можем прекрасно поконфигурить ручками.. а вот если segfault... 

Интересует следующее:
# dd if=/dev/mem of=vbios skip=768 bs=1024 count=1

Потом смотрим, например, в mc в режиме hex view, на третий байт:
55 AA 68 E9 x BB 05 00 00
------^^

Домножаем его на 0x200:
0x68 * 0x200 = 0xd000 и делим на 0x400 (1024): 0xd000 / 0x400 = 0x34 (52)

Далее:
# dd if=/dev/mem of=vbios skip=768 bs=1024 count=52

Вот меня интересует файл vbios :)

Пожалуйста, запостите этот файл (vbios) в Bugzilla. Это поможет нам найти и
исправить ошибку.

То есть, проще говоря, мы берем эту длину и делим ее на 2? А вы в курсе, что там
у меня записано 0x77, то есть 119 и на два оно не поделится?

На всякий случай округлил вверх, то есть до 60 и приаттачиваю результат.

Created attachment 1357 [details]
Video BIOS dump on GF6600

Что-то я не очень втыкаю:
#define V_BIOS 0xc0000
...
read(mem_fd, (char *) V_BIOS, size);

оно прям в память по адресу 0xc0000 читает???

(In reply to comment #28)
> Что-то я не очень втыкаю:
> #define V_BIOS 0xc0000
> ...
> read(mem_fd, (char *) V_BIOS, size);
> 
> оно прям в память по адресу 0xc0000 читает???

бред какой-то... ну, выходит, что так :(

так это нормально - оно создает копию видео-биоса.

если там не делается какой-то еще черной магии до этого (очевидно, делается,
иначе выглядит совсем бредово) - то, что приведено - оно не копирует видеобиос
куда-то себе, а читает из файлового дескриптора (видимо, установленно в /dev/mem
на видеобиос) по некоему фиксированному адресу в виртуальном пространстве
_приложения_. то, что по этому адресу будут вообще выделены какие-то страницы -
или там volatile, или замэплено туда что-то - вот это и надо смотреть, как это
сделано... но сама по себе техника, конечно, зверская...

Created attachment 1367 [details]
vbios-i855GM

Это vbios, не патченный 855resolution

Created attachment 1368 [details]
vbios-82915G

vbios, не патченный 855resolution с i915G/GV/910GL

Created attachment 1369 [details]
vbios-intel855

Ещё один vbios, с:
ntel Corporation 82852/855GM Integrated Graphics Device

Created attachment 1371 [details]
ATI Radeon x600 Video BIOS

результат вывода команды dd if=/dev/mem of=vbios skip=768 bs=1024 count=1

Created attachment 1372 [details]
nvidia 6600 5.43.02.61.00

ASUS/NVIDIA NV6600/SIlencer Video BIOS Version 5.43.02.61.00

результат вывода команды dd if=/dev/mem of=vbios skip=768 bs=1024 count=1

У кого ddcprobe сегфолтится, просьба посмотреть на эту версию. Я там включил
отладочную информацию. Интересно знать, какая последняя инфа проскакивает
прежде, чем сваливается ddcprobe.
ftp://ftp.altlinux.org/pub/people/mouse/ddc/

Я попробовал вместо /dev/mem подсунуть файл с куском /dev/mem + vbios. Оно,
вроде как, начало тоже отваливаться (vbios-intel855):
vbe: BIOS chksum wrong
unknown reason for exception
  eax 002a1881, ebx ef40032a, ecx 477ae806, edx ef1a0000
  esi 00000000, edi 00000000, ebp 00000000, esp 0000002e
  ds 0000, es 0000, fs 0000, gs 0000, ss 0030
  cs:eip 873b:00010000
cannot continue
VBE: Error (0x4f00): 0x1881
Retrying with old LRMI interface
Segmentation fault

Это буду фиксить, но интересно, где оно валится на реальном железе.
Попробовал GF6600 -- получил 100% загруз проца и всё.

Some time later....
Сыпется оно, по всей видимости, где-то при выходе из функции vbe_get_vbe_info().
Т.е. кто-то внутри портит память.

(In reply to comment #37)
> У кого ddcprobe сегфолтится, просьба посмотреть на эту версию. Я там включил
> отладочную информацию. Интересно знать, какая последняя инфа проскакивает
> прежде, чем сваливается ddcprobe.


# ddcprobe
vbe: BIOS chksum wrong
VBE: Error (0x4f00): 0x4f00

Запуск с vbios от GF6600:
iopl(0x3)                               = 0
...
vm86old(0x8061a80)                      = -1 ENOSYS (Function not implemented)
vm86old(0x8061a80)                      = -1 ENOSYS (Function not implemented)
...
vm86old(0x8061a80)                      = -1 ENOSYS (Function not implemented)
vm86old(0x8061a80)                      = -1 ENOSYS (Function not implemented)
vm86old(0x8061a80)                      = -1 ENOSYS (Function not implemented)
Ctrl-C

К чему бы это?

А ещё понравилось это:
   iopl() changes the I/O privilege level of the current process, as specified
in level.
   In addition to granting unrestricted I/O  port  access,  running  at  a
higher  I/O  privilege  level also allows the process to disable inter-
rupts.  This will probably crash the system, and is not recommended.

В общем, в этом самом vbe.c есть какая-то Чёрная магия :)

Похоже, удалось выяснить, кто всё портит. Это повторный вызов InitInt10. Если
его отключить в функции get_edid, то перестаёт падать. Возможно, в
vbe_get_vbe_info тож что-то портится с этим самым InitInt10 и оно отваливается.
Дело в том, что функция FreeInt10 внутри себя делает несколько unmap'ов только в
том случае, когда последний вызов InitInt10 прошёл успешно. Но, по всей
видимости, не совсем удачный вызов InitInt10 при копировании VBIOS оставляет за
собой что-то, что не учитывается в FreeInt10. Хотя, unmap() где надо делается.

В общем, тестите статически собранный ddcprobe без использования InitInt10:
ftp://ftp.altlinux.ru/pub/people/mouse/ddc/ddcprobe

Сразу отмечу, что InitInt10 и еже с ним были задуманы для работы на
архитектурах, отличных от i386, как то x86_64, ppc и ещё кто-то. А старый
ddcprobe (ещё из kudzu) работал только, если мне память не изменяет, через LRMI.

(In reply to comment #40)
> В общем, тестите статически собранный ddcprobe без использования InitInt10:
> ftp://ftp.altlinux.ru/pub/people/mouse/ddc/ddcprobe

--(9)-(0)-( kaa@boa)-( 0} )-(  /home/kaa  )--
:{03:43:26 : Птн, 10.02.06}$  ;./ddcprobe
open /dev/mem: Permission denied
VBE: could not initialize LRMI
VESA BIOS Extensions not detected.
--(10)-(0)-( kaa@boa)-( 1} )-(  /home/kaa  )--
:{03:43:29 : Птн, 10.02.06}$  ;sudo ./ddcprobe
Password:
Segmentation fault

Ой! Забыл кое-что обратно вернуть =)
Пробуем ещё раз. Берём оттуда же.

fixed in 2.0.1

(In reply to comment #44)
> fixed in 2.0.1

ddcprobe сработало, вторая стадия инсталлятора запустилась, отработала установив
все пакеты и вывалилась в командную строку. Видимо как-то надо запустить третью
стадию, чтобы задать пароль root, установить загрузчик и т.д. ? Вопрос как...

просто выйти из командной строки!

вышел путём команды exit

получил:

Module Loader present
Markers: (--) probed, (**) from config file, (==) default settings, (++) from
command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI)
not implemented, (??) unknown.
(==) Log file /var/log/Xorg.
(EE) Unable to locate/open config file
xf86AutoConfig: Primary PCI is 2:0:0
Running "/usr/X11R6/bin/getconfig -X 60802000 -I /etc/X11, /usr/X11R6/etc/X11,
/usr/X11R6/lib/modules, /usr/X11R6/lib/X11/getconfig -v 0x1002 -d 0x3e50 -r 0x00
-s 0x1458 -b 0x2100 -c 0x300"
getconfig.pl : Version 1.0
getconfig.pl : Xorg Verison: 6.8.2.0.
getconfig.pl : 23 build-in rules
getconfig.pl : rules file '/usr/X11R6/lib/getconfig/xorg.cfg' has version 1.0.
getconfig.pl : 1 rule added from file '/usr/X11R6/lib/X11getconfig/xorg.cfg'.
getconfig.pl : Evaluated 24 rules with 0 errors.
getconfig.pl :Weight of result is 500. New driver is "ati".
(==) Using default build-in configuration (43 lines)
(EE) Failed to load module "ati" (module does not exest,0)

Но оригинальная проблема, как понимаю, решена.