Bug 8192
| Summary: | ddcprobeSegmentation fault | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Alexander <_kaa_> | ||||||||||||||||||||
| Component: | ddcprobe | Assignee: | Kachalov Anton <mouse> | ||||||||||||||||||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||||||||||||||||||
| Severity: | blocker | ||||||||||||||||||||||
| Priority: | P5 | CC: | greycat, migor, rider, seriv, slazav | ||||||||||||||||||||
| Version: | unstable | ||||||||||||||||||||||
| Hardware: | all | ||||||||||||||||||||||
| OS: | Linux | ||||||||||||||||||||||
| URL: | http://lists.altlinux.ru/pipermail/sisyphus/2005-October/071187.html | ||||||||||||||||||||||
| Bug Depends on: | |||||||||||||||||||||||
| Bug Blocks: | 8847 | ||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||
Подтверждаю. Мать: 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) Но оригинальная проблема, как понимаю, решена. |
Description
Alexander 2005-10-11 22:25:30 MSD