Re: [Lug-bg] test

2015-09-01 Thread Konstantin Boyanov 
Koe ? :)

2015-09-01 14:48 GMT+02:00 Иван Бъчваров :

> Нямам ядове аз с GMAIL :)
>
>
> ___
> Lug-bg mailing list
> Lug-bg@linux-bulgaria.org
> http://linux-bulgaria.org/mailman/listinfo/lug-bg
>
>
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Annual LUG meeting

2014-11-25 Thread Konstantin Boyanov 
Здравейте,

и от мен +1, даже съм сигурен че поне още +2 ще успея да навия :)
Ако има нужда от помощ/подкрепа за организацията - казвайте.

Поздрави,
Косьо Боянов

2014-11-25 9:05 GMT+01:00 Yasen Pramatarov ya...@lindeas.com:

 On Mon, 24 Nov 2014 16:41:29 +0200 Marian Marinov wrote:

 Въпросът ми е, имате ли желание да се организира подобно събитие там?

  +1

 --
 | Yasen Pramatarov
 |a.k.a. turin
 | home:  http://yasen.lindeas.com
 | photoblog:  http://ltdfocus.com
 | gnu/linux:  http://lindeas.com

 ___
 Lug-bg mailing list
 Lug-bg@linux-bulgaria.org
 http://linux-bulgaria.org/mailman/listinfo/lug-bg


___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

[Lug-bg] Invitation to connect on LinkedIn

2012-04-25 Thread Konstantin Boyanov 
LinkedIn




Linux,

I'd like to add you to my professional network on LinkedIn.

- Konstantin

Konstantin Boyanov
Studentische Hilfskraft at DESY
Berlin Area, Germany

Confirm that you know Konstantin Boyanov:
https://www.linkedin.com/e/1sozrm-h1gmoo5g-n/isd/6832512891/cFtlJXpb/?hs=falsetok=0cLcjIiNBqCBc1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/1sozrm-h1gmoo5g-n/TdeTwQHa_9FfF6MdZPshgQnZg0rxqaSuP0LCYBv/goo/lug-bg%40linux-bulgaria%2Eorg/20061/I2354265724_1/?hs=falsetok=2mSf7lEy1qCBc1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] SCSI ABORT operation пробле м

2007-10-09 Thread Konstantin Boyanov 
Привет!

Махнах го CDROM-a и свързах плоския кабел ,който отива директно в
хардовете, в контролера. Преди като бях пробвал да махна цедето го снаждах
с още един кръгъл кабел. Не знам дали има някаква функционална разлика
между двата вида кабели и дали разбрахте за какво точно говоря, знам само че
кръглите са с twisted pair, при плоските жиците са една до друга. Както и да
е, сега проблема изчезна. Предполагам, че сега ще търся по нов CDROM ако
тръгна да инсталирам нещо. Факт е обаче че трябваше да направя един
fsck.ext2* иначе се оплакваше при всеки рестарт, че моунтва непроверена
файлова система. Но това изглежда не е свързано с проблема.

Благодаря много за помоща, както и за проявения интерес и отзивите, въпреки
че темата е доста стара!

Въпреки това всякакви допълнителни коментари и предложения са добре дошли.

Приятен ден,
Константин


( * )
-/bin/sh-3.00# fsck.ext2 /dev/scsi/host0/bus0/target1/lun0/part2
e2fsck 1.37 (21-Mar-2005)
/dev/scsi/host0/bus0/target1/lun0/part2 is mounted.

WARNING!!!  Running e2fsck on a mounted filesystem may cause
SEVERE filesystem damage.

Do you really want to continue (y/n)? yes

/dev/scsi/host0/bus0/target1/lun0/part2 was not cleanly unmounted, check
forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 1017801, i_blocks is 64, should be 8.  Fixy? yes

Inode 1017802, i_blocks is 64, should be 8.  Fixy? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(2062343--2062349) -(2062351--2062357)
Fixy? yes

Free blocks count wrong for group #62 (32228, counted=32242).
Fixy? yes

Free blocks count wrong (3991891, counted=3991905).
Fixy? yes


/dev/scsi/host0/bus0/target1/lun0/part2: * FILE SYSTEM WAS MODIFIED
*
/dev/scsi/host0/bus0/target1/lun0/part2: * REBOOT LINUX *
/dev/scsi/host0/bus0/target1/lun0/part2: 6825/2052000 files
(0.1%non-contiguous), 104095/4096000 blocks
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] SCSI ABORT operation проблем

2007-10-08 Thread Konstantin Boyanov 
Привет,

Първо благодаря за отзива. Аз също малко го поизоставих този проблем, тази
или другата седмица обаче ще пробвам с 2.6.20 ядро дали и там става същото
нещо и надявам се да докладвам по-добри резултати.

Поздрави,
Константин
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] SCSI ABORT operation проблем

2007-09-11 Thread Konstantin Boyanov 
Привет,

На 10.09.07, Kamen Medarski [EMAIL PROTECTED] написа:

 А убеден ли си че шината ти е терминирана правилно,  или дали нямаш някое
 друго устройство на същата шина? А и другото странно нещо на пръв поглед, е
 че платката използва 80 IRQ, това не ми се струва да е така. За жалост има и
 друг вариант, диска да е повреден. Но по детайлно за подобен проблем може да
 се помогне ако дадеш по-пълно описание на настройки на ядро и начин на
 връзване на диска.


За харда и терминирането съм сигурен, пробвах с различни кабели и
терминатори, даже вчера и с друг хард опитах, същата работа. Така че
предполагам проблема е софтуерен.
Ако му направя един e2fsck преди да го маунтна, проблема изчезва, но пък ако
искам да инсталирам нещо на него примерно и няма как да го чекна
предварително пак по същия начин реагира.

За по детайлното описание на свързването - контролера се намира на една PMC
(Pluggable Mezanine Card) платка, която има конектор за SCSI кабел. Кабела
първо влиза в един SCSI CDROM (SUN SN608G3091), а от SCSI OUT на CDROM-ма
тръгва друг кабел който е свързан с харда. На харда пак има един вход и един
изход, съответно на изхода има терминатор (Ultra 320М LVD/SE).

И защо това за IRQ 80 ти се вижда странно? По принцип SCSI devices какви
interrupt lines използват? 100% има начин да ги променя от firmware, сега ще
погледна документацията на контролера и къде трябва да пиша, само трябва да
разбера и какво да пиша :)

Поздрави,
Константин
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

[Lug-bg] SCSI ABORT operation пробле м

2007-09-05 Thread Konstantin Boyanov 
Здравейте,

Имам следната постановка - на един SCSI хард се опитвам да си build-на
собствена систена, малко или много като практическо упражнение към Linux
From Scratch. Форматирал съм го като ext2, mount-вам го без проблем, но
когато пусна някаква по-трудоемка опреация (копиране на много файлове
наведнъж, разархивиране, и др.) след около минута получавам следните
messages на конзолата:
-/bin/sh-3.00# bunzip2 -d linux-2.6.15.7.tar.bz2
sd 0:0:1:0: ABORT operation started.
sd 0:0:1:0: ABORT operation timed-out.
sd 0:0:1:0: ABORT operation started.
sd 0:0:1:0: ABORT operation timed-out.
.

sd 0:0:1:0: DEVICE RESET operation started.
sd 0:0:1:0: DEVICE RESET operation timed-out.
sd 0:0:1:0: BUS RESET operation started.
sym0: SCSI BUS reset detected.
sym0: SCSI BUS has been reset.
sd 0:0:1:0: BUS RESET operation complete.

Ползвам ядро 2.6.15, както казах вече не някоя определена дистрибуция, а
SCSI драйвера е следния:

-/bin/sh-3.00# more /proc/scsi/sym53c8xx/0
sym53c895a, Version 2, device id 0x12, revision id 0x1
At PCI address 0001:02:04.0, IRQ 80
Min. period factor 10, Wide SCSI BUS
Max. started commands 448, max. commands per LUN 64

Харда е SEAGATE ST336753LW.

Рових из нета и единственото което ми се струва удачно като причина е или
драйвера да е бъгав (или не конфигуриран правилно), или да има някакъв
проблем с прекъсванията (interrupts).

Ще се радвам ако можете да ми дадете някакви насоки за отстраняването на
този проблем, за което предварително благодаря.

Поздрави,
Константин Боянов
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

Re: [Lug-bg] Странен процес в Дебиан

2007-07-12 Thread Konstantin Boyanov 

Здравейте,

И аз го имам на моето ЗуЗЕ, след Х-а и преди КДЕ-то се е стартирал, така че
нищо чудно да има нещо общо с тях.

Поздрави,
Косьо
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg

[Lug-bg] /proc/iomem BAD tags??

2007-01-22 Thread Konstantin Boyanov 

Здравейте,

От доста доста време се опитвам да подкарам един драйвър за VME bus, но все
не мога да разбера какво не е наред. Използвам 1.6.12 ядро на Моторолско
PowerPC, като boot strategy  е  initial RAMdisk, т.е. не разполагам с
инсталация на хард, ами всичко е в паметта... VME драйвера засега се зарежда
като модул, но не се оплаква за нищо при компилация или при зареждането.  По
конкретно въпроса ми за procfs е следният: когато разглеждам /proc/iomem
файла получавам следното:

-sh-3.00# more iomem
-001cd753 : Kernel code
001cd754-0023d0bf : Kernel data
c000-dfff : PCI hose 0 MEM Space 0
 c000-c0ff : BAD
 c100-c11f : BAD
 c120-c13f : BAD
 c140-c15f : BAD
 c160-c17f : BAD
 c180-c19f : BAD
 c1a0-c1bf : BAD
 c1c0-c1df : BAD
 dfd0-dfdf : PCI Bus #01
 dfe0-dfef : PCI Bus #01
 d000-dfff : :00:05.0
e000-efff : PCI hose 1 MEM Space 0
 e110-e11003ff : 0001:02:04.0
   e110-e11003ff : sym53c8xx
 e1102000-e1103fff : 0001:02:04.0
   e1102000-e1103fff : sym53c8xx
f1002000-f1003fff : ethernet shared base

и не мога да разбера (нито да намеря някъде) обяснение, или описание, на
това какво значат тези BAD тагове...
Ако някой има някаква идея, нека сподели.

Благодаря,
Константин Боянов
___
Lug-bg mailing list
Lug-bg@linux-bulgaria.org
http://linux-bulgaria.org/mailman/listinfo/lug-bg